在微服务体系结构中，客户端可能与多个前端服务进行交互。 鉴于此事实，客户端如何知道要调用哪些终结点？ 引入新服务或重构现有服务时会发生什么情况？ 服务如何处理 SSL 终止、相互 TLS、身份验证和其他问题？ API 网关 可帮助解决这些难题。
API 网关关系图
下载此体系结构的 Visio 文件。
什么是 API 网关？
API 网关提供一个集中式入口点，用于管理客户端与应用程序服务之间的交互。 它充当反向代理并将客户端请求路由到相应的服务。 它还可以执行各种交叉任务，例如身份验证、SSL 终止、相互 TLS 和速率限制。
为何使用 API 网关？
API 网关简化了通信，增强了客户端交互，并集中管理常见的服务级别职责。 它充当中介，可防止直接向客户端公开应用程序服务。 如果没有 API 网关，客户端必须直接与单个应用程序服务通信，这可能会带来以下挑战：
复杂客户端代码：可能会导致复杂的客户端代码。 客户端必须跟踪多个终结点并弹性处理故障。
紧密耦合：它创建客户端与后端之间的耦合。 客户端需要了解各个服务的分解，使服务维护和重构复杂化。
延迟增加：单个作可能需要调用多个服务。 结果可能是客户端和服务器之间的多个网络往返，从而增加了显著的延迟。
关注点的冗余处理：每个面向公众的服务必须处理身份验证、SSL 和客户端速率限制等问题。
协议限制：服务必须公开客户端友好的协议，例如 HTTP 或 WebSocket。 此公开限制 通信协议 选项。
扩展攻击面：公共终结点会增加潜在的攻击面，并且需要强化。
如何使用 API 网关
可以使用特定的设计模式根据应用程序的要求定制 API 网关。 这些设计模式解决了路由、请求聚合和交叉问题等关键功能：
网关路由。 可以使用 API 网关作为反向代理将客户端请求路由到不同的应用程序服务。 API 网关使用第 7 层路由，并提供一个终结点供客户端使用。 如果要将客户端与应用程序服务分离，请使用 API 网关路由。
网关聚合。 可以使用 API 网关将多个客户端请求聚合到单个请求中。 当单个作需要调用多个应用程序服务时，请使用此模式。 在 API 聚合中，客户端向 API 网关发送一个请求。 然后，API 网关会将请求路由到作所需的各种服务。 最后，API 网关聚合结果并将其发送回客户端。 聚合有助于减少客户端与应用程序服务之间的聊天。
网关卸载。 可以使用 API 网关提供交叉功能，因此各个服务无需提供。 将跨切功能合并到一个位置，而不是让每个服务都负责，这很有用。 下面是可以卸载到 API 网关的功能示例：
- SSL 终止
- 相互 TLS
- 认证
- IP 允许列表或阻止列表
- 客户端速率限制（限制）
- 日志记录和监视
- 响应缓存
- Web 应用程序防火墙
- GZIP 压缩
- 维护静态内容
API 网关选项
下面是在应用程序中实现 API 网关的一些选项。
反向代理服务器。 Nginx 和 HAProxy 是开源反向代理产品/服务。 它们支持负载均衡、SSL 终止和第 7 层路由等功能。 他们具有免费版本和付费版本，可提供额外的功能和支持选项。 这些产品已成熟，具有丰富的功能集、高性能和可扩展功能。
服务网格入口控制器。 如果使用服务网格，请评估特定于该服务网格的入口控制器的功能。 检查 Istio 和 Open Service Mesh 等支持 AKS 的加载项。 查找第三方开源项目，如 Linkerd 或 Consul Connect。 例如，Istio 入口控制器支持第 7 层路由、HTTP 重定向、重试和其他功能。
Azure 应用程序网关。 应用程序网关是托管的负载均衡服务。 它提供第 7 层路由、SSL 终止和 Web 应用程序防火墙（WAF）。
Azure Front Door。 Azure Front Door 是内容分发网络（CDN）。 它使用全局和本地接入点（PoP）全局提供对应用程序的静态和动态 Web 内容的快速、可靠且安全的访问。
Azure API 管理。 API 管理是一种托管解决方案，用于将 API 发布到外部客户和内部客户。 它提供用于管理面向公众的 API 的功能，包括使用 Microsoft Entra ID 或其他标识提供者进行速率限制、IP 限制和身份验证。 API 管理不执行任何负载均衡，因此应将其与负载均衡器（例如 Azure 应用程序网关或反向代理）配合使用。 有关信息，请参阅使用 Azure 应用程序网关 API 管理。
选择 API 网关技术
选择 API 网关时，请考虑以下因素：
支持所有要求。 选择支持所需功能的 API 网关。 上述所有 API 网关选项 都支持第 7 层路由。 但是，他们对其他功能（例如身份验证、速率限制和 SSL 终止）的支持可能会有所不同。 评估单个网关是否符合需求，或者是否需要多个网关。
首选内置产品/服务。 只要满足安全性和控制要求，即可使用平台提供的内置 API 网关和入口解决方案，例如 Azure 容器应用和 AKS。 仅当内置选项缺乏必要的灵活性时，才使用自定义网关。 自定义解决方案需要治理模型（如 GitOps）才能有效地管理其生命周期。
选择正确的部署模型。 使用 Azure 应用程序网关和 Azure API 管理等托管服务减少作开销。 如果使用常规用途反向代理或负载均衡器，请以符合体系结构的方式部署它们。 可以将常规用途 API 网关部署到专用虚拟机，也可以在其入口控制器产品/服务中的 AKS 群集内部署。 若要将 API 网关与工作负荷隔离，可以在群集外部部署它们，但此部署会增加管理复杂性。
管理更改。 更新服务或添加新服务时，可能需要更新网关路由规则。 实现流程或工作流，以便在添加或修改服务、SSL 证书、IP 允许列表和安全配置时管理路由规则。 使用基础结构即代码和自动化工具简化 API 网关管理。
后续步骤
前面的文章探讨了 微服务与微服务和客户端应用程序之间的接口。 这些接口将每个服务视为自包含的不透明单元。 微服务体系结构的一个关键原则是，服务不应公开有关它们如何管理数据的内部详细信息。 此方法对维护数据完整性和一致性具有重大影响，这是下一篇文章的主题。