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