在单个位置聚合调用微服务：API网关。用户只需调用API网关，然后API网关就会调用每个相关的微服务。API网关模式为您的微服务调用提供单点聚合.
让我们假设您正在构建一个使用Microservice架构模式的在线商店，并且您正在实现产品详细信息页面。您需要开发产品详细信息用户界面的多个版本：
- 用于桌面和移动浏览器的基于HTML5 / JavaScript的UI - HTML由服务器端Web应用程序生成
- 原生Android和iPhone客户端 - 这些客户端通过REST API与服务器交互
在线商店必须通过REST API公开产品详细信息，以供第三方应用程序使用。
产品详细信息UI可以显示有关产品的大量信息：
- 有关该书的基本信息，如标题，作者，价格等。
- 您购买图书的历史记录
- 可用性
- 购买选项
- 本书经常购买的其他物品
- 购买此书的顾客购买的其他商品
- 顾客评论
- 卖家排名
由于在线商店使用微服务架构模式，因此产品详细信息数据分布在多个服务上。例如，
- 产品信息服务 - 产品的基本信息，如标题，作者
- 定价服务 - 产品价格
- 订购服务 - 产品的购买历史
- 库存服务 - 产品可用性
- 审核服务 - 客户评论......
因此，显示产品详细信息的代码需要从所有这些服务中获取信息。
基于微服务的应用程序的客户端如何访问各个服务？
- 微服务提供的API的粒度通常与客户端所需的不同。微服务通常提供细粒度的API，这意味着客户端需要与多个服务进行交互。例如，如上所述，需要产品细节的客户端需要从众多服务中获取数据。
- 不同客户需要不同的数据。例如，产品详细信息页面桌面的桌面浏览器版本通常比移动版本更精细。
- 不同类型的客户端的网络性能不同。例如，移动网络通常比非移动网络慢得多且具有更高的延迟。当然，任何WAN都比LAN快得多。这意味着本机移动客户端使用的网络与服务器端Web应用程序使用的LAN具有非常不同的性能特征。服务器端Web应用程序可以对后端服务发出多个请求，而不会影响用户体验，因为移动客户端只能做一些。
- 服务实例的数量及其位置（主机+端口）动态变化
- 对服务的分区可能会随着时间的推移而发生变化，应该从客户端隐藏
- 服务可能使用各种协议，其中一些协议可能不适合Web
实现API网关，它是所有客户端的单一入口点。API网关以两种方式之一处理请求。有些请求只是代理/路由到适当的服务。它通过扇出多个服务来处理其他请求。
API网关可以为每个客户端公开不同的API，而不是提供一个通用的样式API。例如，Netflix API网关运行特定于客户端的适配器代码，该代码为每个客户端提供最适合其要求的API。
API网关还可以实现安全性，例如验证客户端是否有权执行请求
前后端分离模式
如果有三种客户端：Web应用程序，移动应用程序和外部第三方应用程序，那么就有三种不同的API网关。每个都为其客户提供API。
- 将客户端与应用程序分区为微服务的方式隔离开来
- 将客户端与确定服务实例的位置的问题隔离开来
- 为每个客户提供最佳API
- 减少请求/往返次数。例如，API网关使客户端能够通过单次往返从多个服务中检索数据。更少的请求也意味着更少的开销并改善用户体验。API网关对于移动应用程序至关重要。
- 通过将用于调用多个服务的逻辑从客户端移动到API网关来简化客户端
- 从“标准”公共Web友好API协议转换为内部使用的任何协议
API网关模式有一些缺点：
- 复杂性增加 - API网关是另一个必须开发，部署和管理的移动部分
- 由于通过API网关额外的网络跳跃而增加了响应时间 - 但是，对于大多数应用程序而言，额外往返的成本是微不足道的。
问题：
- 如何实现API网关？事件驱动/被动方法最好是必须按比例扩展以处理高负载。在JVM上，基于NIO的库（如Netty，Spring Reactor等）是有意义的。NodeJS是另一种选择。
相关：
到底什么是API网关？它正经历身份认同危机
Spring Cloud Gateway或Zuul实现了API网关模式：
https://www.jdon.com/springcloud.html