InfoQ|谈谈微服务设计中的 API 网关模式

【InfoQ|谈谈微服务设计中的 API 网关模式】 作者 | Bibek Shah 译者 | 姜雨生策划 | 田晓旭
根据 Gartner 对微服务的定义：“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。 ”
与将模块高度耦合并部署为一个大的应用程序相比，微服务的目标是将应用程序充分分解或者解耦为松散耦合的许多微服务或者模块，这样做对下面几点有很大帮助：

每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。
通过自治的跨职能团队进行敏捷开发和敏捷部署。
运用技术时具备灵活性和可扩展性

在微服务架构中，我们根据各自的特定需求部署不同的松耦合服务，其中每个服务都有其更细粒度的 API 模型，用以服务于不同的客户端（Web ，移动和第三方 API）。
客户端到微服务的连接

本文插图
在考虑客户端与每个已部署的微服务直接通信的问题时，应考虑以下挑战：

如果微服务向客户端公开了细粒度的 API ，则客户端应向每个微服务发出请求。在典型的单页中，可能需要进行多次服务器往返，才能满足请求。对于较差的网络条件下运行的设备（例如移动设备），这可能会更糟。
微服务中存在的多种通信协议（例如 gRpc、thrift、REST、AMQP 等）使客户端很难轻松采用所有这些协议。
必须在每个微服务中实现通用网关功能（例如身份验证、授权、日志记录）。
在不中断客户端连接的情况下，很难在微服务中进行更改。例如，在合并或划分微服务时，可能需要重新编写客户端部分代码。

API 网关为了解决上述挑战，人们引入了一个附加层，该附加层位于客户端和服务器之间，充当从客户端到服务器的反向代理路由请求。与面向对象设计的模式相似，它为封装底层系统架构的 API 提供了一个单一的入口，称为 API 网关。
简而言之，它的行为就像 API 管理员一样，但重要的是不要将 API 管理与 API Gateway 混为一谈。

本文插图
API 网关的功能路由网关封装了底层系统并与客户端分离，为客户端提供了与微服务系统进行通信的单个入口点。
整合 API 网关整合了一些边缘的重复功能，无需让每个微服务都实现它们。它包括如下功能：

认证和授权
服务发现集成
缓存响应结果
重试策略、熔断器、QoS
限速和节流
负载均衡
log 日志、链路追踪、关联
Header、query 字符串以及 claims 转义
IP 白名单
IAM
集中式日志管理（服务之间的 transaction ID、错误日志等）
身份的提供方，验证与授权

后端服务前端模式（BFF Backend for Frontend）它是 API 网关模式的一种变体。它提供了基于客户端的多个网关，而不是提供给客户端一个单一的入口点。目的是根据客户端的需求提供量身定制的 API ，从而消除了为所有客户端制作通用 API 造成的大量的浪费。

本文插图
到底需要多少 BFF BFF 的基本概念是为每种用户体验开发利基后端。菲尔·卡尔萨多（PhilCal?ado）的指导建议是“一种体验，一种 BFF” 。如果跨客户端（IOS 客户端、Android 客户端、Web 浏览器等）的要求有很大差异，并且单个代理或 API 的发布时间有严格要求，则 BFF 是一个很好的解决方案。还应注意，更复杂的设计需要复杂的步骤。