我敢肯定我需要使用API网关，但是我无法理解用例场景中不同工具之间的主要区别。
当前，我有多个服务（DBS，移动应用程序，Web应用程序和一些其他系统。考虑15种不同的服务），可以通过REST API相互通信。这很难管理和测试，因此我想将体系结构更改为Netflix对Zuul所做的事情。
理想情况下，服务不知道其他服务。他们将请求发送到特定端点（API网关）。然后，API网关与必要的服务进行交互，并将响应发送回。这是实践中的一个示例：服务将请求发送到自定义（端点）连接器，请求进行解析，分解为较小的请求，这些请求已发送到其他服务（拥有所请求的特定内容），将内容重新放入响应，收集所有响应，在收集的所有内容中创建最终响应，将响应发送回第一个发送请求的服务。
我需要高可用性，可扩展性，容错性，一个地方监视和测试所有服务的能力，进行金丝雀测试的能力，易于添加新服务并管理旧服务。我重视开源软件和成熟软件。应该跑出前提。
我认为可以解决我的问题的最佳解决方案是：WSO2，Apigee，Zuul和Amazon API Gateway。我不知道哪种更适合我的用例。我看过别人，但是我没有发现与这4的功能或成本上的任何优势。
感谢您对这些技术的优势和缺点的反馈！也欢迎其他建议！
注意：并非我所有的服务都在AWS上，但是有些是在AWS上。该系统需要以每分钟的数万个要求进行浮动，但永远不会继续进行处理。
您还可以考虑论坛系统的论坛哨兵API安全网关（我在论坛系统工作）。
基于您的示例用例，如果每个"较小的请求"服务都使用相同的协议（例如HTTPS），消息格式（例如JSON）和安全特性（TLS，身份验证等），则该解决方案应应相对直截了当。
如果每个服务都使用不同的身份或消息格式，则您的API网关解决方案也将需要在身份和消息转换方面具有强大的功能。例如，一个小请求可能需要一个基本的标题来验证该服务，而另一个小请求可能需要SAML主张。
由于您具有不同的微服务的景观，其中每个微服务都有自己的业务环境，并且可以通过REST ENDPONIT访问。在这种情况下，您的客户不必意识到每个微服务，因此可以使用API网关，您可以使用所有微服务景观的入口点。
您所说的Apigee，Apiman等都有不同的API网关解决方案。这些框架为API网关中所需的功能提供了一些基本实现，例如请求节流，对请求呼叫进行监测，身份验证句柄，集中安全性等。
。 。 。Netflix的Zuul提供了您需要实施的过滤器。因此，如果您使用的是Zuul，则必须自己实现所有要放入API网关的功能。
我希望这种解释有帮助！