本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
API Gateway 模式
如果您想设计并构建有多个客户端应用程序的基于微服务的复杂或大型应用程序，则建议 API Gateway 模式。该模式类似于来自面向对象设计的外观模式
该模式提供一个将请求重定向或路由到内部微服务端点的反向代理。API Gateway 为客户端应用程序提供单个端点或 URL，并在内部将请求映射到内部微服务。通过隐藏某些实现细节（例如 Lambda 函数名称和版本）来提供抽象层，还可以在后端服务之上添加其他功能，例如响应和请求转换、端点访问授权或跟踪。
若为以下情况，您应考虑使用 API Gateway 模式：
-
微服务的依赖项数量是可管理的，并且不会随着时间的推移而增长。
-
调用系统需要来自微服务的同步响应。
-
您有低延迟要求。
-
您需要公开一个 API 以便从多个微服务收集数据。
用例
在这个用例中，客户在保险系统中按月定期付款，该保险系统由四项作为 Lambda 函数部署的微服务（“客户”、“通信”、“付款”和“销售”）组成。“客户”微服务用每月付款详细信息更新客户数据库。“销售”微服务用帮助销售团队跟进客户以寻找交叉销售机会的相关信息更新销售数据库。成功处理付款后，“通信”微服务会向客户发送一封确认电子邮件。最后，“付款”微服务是客户用来按月付款的整体系统。该模式使用网络服务将“客户”、“销售”和“通信”子系统与“付款”微服务集成。
在此用例中使用此模式有三个挑战：
对下游系统进行同步调用，这意味着这些子系统造成的任何延迟都会影响整体响应时间。
运行成本更高，因为“付款”系统在响应呼叫系统之前正在等待来自其他微服务的响应。因此，与异步系统相比，总运行时间相对较高。
错误处理和重试针对“付款”系统内的每个微服务单独处理，而不是由单个微服务处理。
以下两个示例概述了如何使用 API Gateway 模式通过使用多个 API Gateway 或一个 API Gateway 来集成微服务。
多个 API Gateway
在下图中，每个微服务有自己的 API Gateway。“支付”微服务调用各个系统并实现 API Gateway 模式。
单一 API Gateway
在下图中，每个微服务都作为 Lambda 函数部署，但所有微服务都由同一 API Gateway 连接。
