模式:API网关/前端的后端

3 月,跳不动了?>>> hot3.png

语境

假设您正在建立一个使用微服务架构模式的在线商店,并且正在实现产品详细信息页面。您需要开发产品详细信息用户界面的多个版本:

  • 用于桌面和移动浏览器的基于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。

例子

结果上下文

使用API​​网关具有以下好处:

  • 使客户端与如何将应用程序划分为微服务隔离
  • 使客户端免受确定服务实例位置的问题的影响
  • 为每个客户提供最佳的API
  • 减少请求/往返次数。例如,API网关使客户端能够通过一次往返从多个服务中检索数据。更少的请求还意味着更少的开销并改善了用户体验。API网关对于移动应用程序至关重要。
  • 通过将用于从客户端调用多个服务的逻辑转移到API网关来简化客户端
  • 从“标准”的公共Web友好API协议转换为内部使用的任何协议

API网关模式有一些缺点:

  • 复杂性增加-API网关是另一个必须开发,部署和管理的移动部分
  • 由于通过API网关进行了额外的网络跳转,因此增加了响应时间-但是,对于大多数应用程序而言,额外往返的成本微不足道。

问题:

  • 如何实现API网关?如果事件驱动/响应方法必须按比例缩放以应对高负载,则它是最佳选择。在JVM上,诸如Netty,Spring Reactor等基于NIO的库很有意义。NodeJS是另一种选择。

相关模式

已知用途

应用范例

请参阅API网关,这是我的微服务模式示例应用程序的一部分。它是使用Spring Cloud Gateway实施的。

发布了132 篇原创文章 · 获赞 2 · 访问量 544

猜你喜欢

转载自blog.csdn.net/weixin_45839894/article/details/105198827
今日推荐