谈谈微服务设计中的 API 网关模式.docxVIP

谈谈微服务设计中的 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 是一个很好的处理方案。还应留意，更简单的设计需要简单的步骤。 GraphQL 与 BFF GraphQL 是一种 API 的查询言语。PhilCal?ado 提出 BFF 和 GraphQL 的想法是相像的，但不是互斥的概念。他补充说，BFF 与你端口的外形无关，而在于赐予客户端对应用程序的自治权，您可以在其中构建与很多 BFF 或 OSFA（one-size-fits-all）的 GraphQL API。 有名的 API 网关 Netflix API 网关：Zuul Netflix 的流媒体服务可在 1000 多种不同类型的设备（电视、机顶盒、智能手机、玩耍系统、平板电脑等）上使用，在高峰时段可以每秒处理 50,000 个恳求，这种需求是 OSFA （one-size-fits-all）的 REST API 难以满足的，因而他们为每个设备量身定制了 API 网关。 Netflix 的 Zuul 2 是全部进入 Netflix 云基础架构的恳求的第一步。Zuul 2 大大改进了架构和功能，使我们的网关能够处理、路由和爱护 Netflix 的云系统，并挂念为我们的 1.25 亿会员供应最佳体验。 亚马逊 API 网关 AWS 供应了完备的托管服务，用于创建、发布、维护、监视以及爱护 REST、HTTP 和 WebSocket，开发人员可以在其中创建用于访问 AWS 或其他 Web 服务的 API，并将数据存储在 AWS 云上面。 Kong API 网关 Kong Gateway 是一个开源的，轻量级的微服务 API 网关，可供应无与伦比的延迟功能优化和可伸缩性。假如您只需要这些基础力量，那么它就是很合适的选项。只需要添加更多节点就可以轻松横向扩展。它以格外低的延迟来支持大量可变的工作负载。 其他 API 网关 Apigee API Gateway MuleSoft Tyk.io Akana SwaggerHub Azure API Gateway Express API Gateway Karken D 选择正确的网关 评估标准里面，一些常见的目标包括简便性、开源还是专有、可伸缩性和机警性、平安性、后续功能、社区、管理（支持情况、监控和部署）、环境配置（安装、配置、能否支持托管）、定价和文档等。 API 组合与聚合 API 网关中的一些