选择 API Gateway 工具来实现 SOA/微服务架构

Question

我确定我需要使用 API 网关，但我无法理解我的用例场景中不同工具之间的主要区别。

目前，我有多个通过 REST API 相互通信的服务（数据库、移动应用程序、Web 应用程序和一些其他系统。假设有 15 种不同的服务）。这很难管理和测试，因此我想将架构更改为更像 Netflix 使用 Zuul 所做的那样。

理想情况下，服务不知道其他服务。它们向特定端点（API 网关）发送请求。然后，API 网关与必要的服务交互并发送回响应。 这是一个实践示例：服务向自定义（端点）连接器发送请求，请求被解析，分解成更小的请求，这些请求被发送到其他服务（拥有所请求的特定内容），将内容重新放入响应，收集所有响应，使用收集的所有内容创建最终响应，将响应发送回发送请求的第一个服务。

我需要高可用性、可扩展性、容错性、在一个地方监控和测试所有服务的能力、进行金丝雀测试的能力、轻松添加新服务和管理旧服务的能力。我看重开源软件和成熟软件。应该跑出前提。

我认为可以解决我的问题的最佳解决方案是：WSO2、Apigee、Zuul 和 Amazon API Gateway。我不知道哪个更适合我的用例。我看过其他人，但我没有发现与这 4 个相比在功能或成本方面有任何优势。

感谢您就这些技术的优缺点提供反馈！也欢迎其他建议！

注意事项： 并非我的所有服务都在 AWS 上，但有些是。 系统需要处理每分钟数万个请求的峰值，这些请求经常发生，但绝不会持续发生。

Answer 1

您还可以考虑 Forum Systems 的 Forum Sentry API 安全网关（我为 Forum Systems 工作）。

根据您的示例用例，如果每个“较小的请求”服务都使用相同的协议（例如 HTTPS）、消息格式（例如 JSON）和安全特性（TLS、身份验证等），那么解决方案应该相对直截了当。

例如，如果每个服务使用不同的身份或消息格式，那么您的 API Gateway 解决方案还需要具备强大的身份和消息转换能力。例如，一个小请求可能需要 BasicAuth 标头来对服务进行身份验证，而另一个小请求可能需要 SAML 断言。

Answer 2

由于您拥有不同微服务的格局，其中每个微服务都有自己的业务上下文，并且可以通过 REST 端点访问。在这种情况下，您的客户端不需要了解每个微服务，因此 API 网关就出现了，您可以使用它为所有微服务环境提供一个入口点。

有不同的 API 网关解决方案可用，如您所说的 apigee、apiman 等。这些框架提供了 API 网关所需功能的一些基本实现，例如请求限制、请求调用的监控、身份验证句柄、集中式安全性等。

Netflix 的 Zuul 提供了您需要自己实现的过滤器。所以，如果你使用 Zuul，你必须自己实现所有你想放入 API 网关的功能。

我希望这个解释有帮助！！！