Mule API AutoDiscovery 与 Mule API GatewayProxy答案

【问题标题】：Mule API AutoDiscovery vs Mule API GatewayProxyMule API AutoDiscovery 与 Mule API GatewayProxy
【发布时间】：2017-06-20 15:00:39
【问题描述】：

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

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

Mule API 网关代理的问题

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

Mule API 自动发现

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

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

【问题讨论】：

标签： mule mule-studio mule-component mule-el mule-cluster

【解决方案1】：

如果您计划将策略应用/取消应用到特定端点，和/或利用 API 平台上下文中的使用统计信息，则需要API Autodiscovery。 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 的应用程序，则不需要使用代理。对于大多数用例，在配置文件中添加相应的自动发现元素就可以解决问题。

【讨论】：