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