2

我们什么时候应该针对 API AutoDiscovery 使用 API 代理。在实现两者之后，我发现 AutoDiscovery 还可以应用策略，API Gateway 所做的分析，唯一的问题是如果使用 AutoDiscovery，我不能使用不同的 url。API 代理的主要优点是如果我的网关应用程序和 Mule 实施项目位于不同的子网中，所以如果我们是我的网关服务器被入侵，没有人可以进入我的实施网络。

但是如果接口和实现都在同一个网络中，并且目的只是调用一个 REST 端点，我们应该不使用 API AutoDiscovery。

Mule API 网关代理的问题

  1. 如果我们无法访问实施服务器，则没有定义的异常处理方式。
  2. 没有定义跨环境移动代理应用程序的方法 (CI/CD)
  3. 额外的 HTTP 跃点，如果上述 2 个问题有明确的方式，则可以接受

Mule API 自动发现

  1. 由于这是在 Mule 应用程序中，因此是标准异常处理。
  2. CI/CD 被定义为 Mule 实施项目。
  3. 没有额外的 HTTP 跃点。
  4. 唯一的问题是，我们不能更改实现 URL，这只是紧密耦合的事情。

有人可以提供有关我们何时应该使用 API Gateway 与 AutoDiscovery 的见解。目前还有一种方法可以在 API Gateway 项目和 CI/CD 中进行异常处理吗？

4

1 回答 1

0

如果您计划将策略应用/取消应用到特定端点，和/或利用 API 平台上下文中的使用统计信息，则需要API 自动发现。Api Autodiscovery 是一种元数据，将 HTTP(s) 侦听器链接到 API Manager 上的对应 API 版本。

例如：

    <api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
    </api-platform-gw:api>

    <flow name="basic.path">
        <http:listener config-ref="a.http.config" />
        <set-payload value="Endpoint successfully called." />
    </flow>

自动生成的 Mule 代理确实定义了自动发现。您还可以通过使用 Studio UI 或直接处理 XML 配置来开发自己的项目并定义相应的自动发现。

如果您的实现后端不是 Mule 应用程序（例如，托管在 Tomcat 服务器中的现有基于 REST 的 API），则需要使用代理。您可以在 Mule 端通过自定义异常处理来丰富逻辑。如果您想在实现后端更好地处理异常，则必须在那里实现它。

如果您的实现后端是基于 Mule 的应用程序，则不需要使用代理。对于大多数用例，在配置文件中添加相应的自动发现元素就可以了。

于 2017-08-07T15:17:24.260 回答