使用 Amazon API Gateway 私有集成进行规模架构 计算博客

使用 Amazon API Gateway 私有整合架构扩展规模

重点摘要

本文探讨如何利用 Amazon API Gateway 提升微服务的可扩展性并保持安全性。随著环境演变为多个微服务，组织需要确保 API 层能够灵活应对扩展需求。API Gateway 提供多种 API 类型和整合选项，本文重点与架构选择有关，帮助开发人员安全高效地构建 API 层。

概述

这里展示了一个典型的 API Gateway 实施，后端整合了各种微服务：

API Gateway 负责 API 层，并整合运行在 Amazon EC2、Amazon Elastic Container Service (ECS) 或 Amazon Elastic Kubernetes Service (EKS) 的后端微服务。这篇文章专注于容器化微服务，这些微服务暴露内部端点，API 层则将其外部的公开。

为了确保微服务安全且不受外部流量影响，它们通常在 Amazon 虚拟私有云 (VPC) 的私有子网内实施，这样就无法直接从互联网访问。API Gateway 提供了一种方法，可以通过使用 VPC 连接 安全地将这些资源暴露超出 VPC。私有整合允许将发送到 API 的外部流量转发至私有资源，而不必将服务暴露于互联网之外或离开 AWS 网络。更多信息可以参考 Amazon API Gateway 私有 API 和私有整合的设计最佳实践。

示例场景中，四个微服务可以托管在一个或多个 VPC 中。它展示了将微服务与前端负载均衡器及 API Gateway 通过 VPC 连接进行整合的模式。

客户可能会有额外需求：增强扩展性：支持更多微服务与 API Gateway 的连接。独立部署：每个微服务拥有专用负载均衡器，使团队能够独立进行蓝绿部署，而不影响其他团队。减少复杂性：能够使用现有的微服务负载均衡器，而不必引入额外的组件来实现与 API Gateway 的整合。低延迟：确保 API 请求/响应流的延迟最小化。

API Gateway 提供的 HTTP APIs 和 REST APIs详见 选择 REST API 和 HTTP API用于构建 RESTful API。在大型微服务架构中，API 类型会影响整合考量：

支援 VPC 连接的整合每帐户每区域的 VPC 连接配额REST API网络负载平衡器 (NLB)HTTP API网络负载平衡器 (NLB)、应用负载平衡器 (ALB)、AWS Cloud Map

本文介绍四种私有整合选项，考虑到 REST API 和 HTTP API 的不同能力与配额：

选项 1：使用 VPC 连接的 HTTP API，连接多个 NLB 或 ALB。选项 2：使用多个 VPC 连接的 REST API。选项 3：使用 VPC 连接的 REST API，并使用 NLB。选项 4：使用 VPC 连接的 REST API，并结合 NLB 及 ALB 目标。

选项 1：使用 VPC 连接的 HTTP API，连接多个 NLB 或 ALB

HTTP API 允许将单个 VPC 连接连接到多个 ALB 或 NLB，或注册于 AWS Cloud Map 的资源。这提供了一种将多个后端微服务连接起来的扇出方法。然而，与特定 VPC 连接整合的负载均衡器应位于相同的 VPC 中。

免费加速器永久免费版

两个微服务位于同一个 VPC 中，每个微服务都有各自专用的 ALB。ALB 的接收器将 HTTPS 流量引导到相应的后端微服务目标组。单一 VPC 连接连接到该 VPC 的两个 ALB。API Gateway 使用基于路径的路由规则来将请求转发到适当的负载均衡器和相关微服务。这一做法在 设计 Amazon API Gateway 私有 API 和私有整合的最佳实践 HTTP API 中有详细说明。可在 GitHub 获取部署此解决方案的 CloudFormation 模板。

在 VPC IP 空间的限制内，您可以添加额外的 ALB 和微服务。使用 网络地址使用情况 设计微服务在 VPC 之间的分布。如果希望扩展超过一个 VPC，可以添加 VPC 连接来连接更多 VPC，在 VPC 连接配额范围内。您还可以借由使用 ALB 的基于路径的路由规则将更多服务连接到单个 ALB 下来进一步扩展见 应用负载平衡器的配额。该架构也可使用 NLB 构建。

好处：

高度可扩展性。使用单个 VPC 连接及/或 ALB/NLB 的多路复用功能，可向多个微服务进行扇出。与现有微服务负载均衡器的直接整合，消除了引入新组件的需求，减轻了运营负担。由于直接整合，API 请求/响应的延迟更低。每个微服务的专用负载均衡器支持微服务团队的独立部署。

选项 2：使用多个 VPC 连接的 REST API

对于 REST API，支持多个微服务的架构可能因以下考量而有所不同：

NLB 是 REST API 唯一支援的私有整合。REST API 的 VPC 连接只能有一个目标 NLB。

对于每个 NLB 都需要一个 VPC 连接，即使这些 NLB 在同一个 VPC 中。每个 NLB 服务一个微服务，并有一个接收器将 API Gateway 流量路由到目标组。API Gateway 基于路径的路由将请求发送至适当的 NLB 及相应的微服务。此私有整合所需的设置与 教程：使用 API Gateway 私有整合构建 REST API 中的示例类似。

要进一步扩展，为每个微服务添加额外的 VPC 连接和 NLB 整合，无论是在相同或不同的 VPC 中，根据您的需求和隔离要求。这一方法受到每账户每区域的 VPC 连接配额的限制。

好处：

请求路径中只有单一 NLB，降低了操作复杂性。每个微服务都有专用 NLB，支持独立部署。API 请求路径中的跳转减少，导致延迟更低。

考量：

因 VPC 连接与 NLB 之间的一对一映射而限制可扩展性，配额也受到每账户每区域的 VPC 连接数量的限制。

选项 3：使用 VPC 连接的 REST API，并使用 NLB

选项 2 中 VPC 连接与 NLB 和微服务之间的一对一映射会由于 VPC 连接配额的限制而影响可扩展性。另一种方案是每个 NLB 支持多个微服务。

通过为每个微服务在单一 NLB 上使用多个接收器，来支持同一 VPC 中的多个微服务。这里，NLB1 在一个 VPC 上前端两个微服务，而 NLB2 在第二个 VPC 上前端另外两个微服务。NLB 上支持多个微服务时，当选择方法的整合点时，需要为 REST API 定义路由。您可以通过选择与特定 NLB 整合的 VPC 连接 和分配给每个微服务的 NLB 接收器的具体端口来定义每个服务。

要进一步扩展，为现有的 NLB 添加额外的接收器，受限于 网络负载平衡器的配额。如果每个微服务有各自专用的负载均衡器或访问点，则这些作为目标配置到 NLB。另外，通过添加额外的 VPC 连接来整合额外的微服务。

好处：

更大的可扩展性由 NLB 接收器和 VPC 连接的配额限制。支持多个微服务的少量 NLB 管理，降低了操作复杂性。请求路径中的单一 NLB 减少了延迟。

考量：

共享的 NLB 配置限制了各微服务团队的独立部署。

选项 4：使用 VPC 连接的 REST API，并结合 NLB 和 ALB 目标

客户通常建构微服务时，使用 ALB 作为访问点。要通过 API Gateway REST API 曝露这些服务，可以借助 将 ALB 作为 NLB 的目标 的方案。这种模式在支持的微服务数量上也比选项 3 的架构有所增加。

在 VPC1 中创建 VPC 连接VPCLink1与 NLB1。ALB1 和 ALB2 前端微服务 mS1 和 mS2，并在单独的接收器上添加为 NLB 目标。VPC2 具有类似的配置。您的隔离需求和 IP 空间决定了微服务是集中于一个 VPC 还是分散于多个 VPC。

要进一步扩展：

创建额外的 VPC 连接来整合新的 NLB。添加 NLB 接收器以支持更多 ALB 目标。配置 ALB 使用基于路径的规则来路由请求到多个微服务。

好处：

透过整合 NLB 和 ALB，实现高可扩展性。当每个 ALB 专门分配给单个微服务时，支持团队独立部署的能力。

考量：

请求路径中多个负载均衡器可能会增加延迟。

考量事项与最佳实践

除了本文所述基于 VPC 连接整合的可扩展性考量，还有其他需要考虑的方面：

评估 REST API 和 HTTP API 的能力来满足需求。选择最适合应用需求的 负载均衡器类型。对于多帐户架构的参考，请访问 使用 Amazon API Gateway 和 AWS PrivateLink 构建私有跨帐户 APIs。避免快速超过预设的配额，并根据需要 请求配额增加。监控服务配额，积极计划并减轻架构演变时的风险。可以考虑使用 配额监控解决方案 进行监控。参考 设计 Amazon API Gateway 私有 API 和私有整合的最佳实践 REST API。

结论

本文探讨了使用 VPC 连接为微服务构建可扩展 API Gateway 整合的方案。VPC 连接允许将外部流量转发至后端微服务，而不必将它们暴露于互联网上或离开 AWS 网络。文章涵盖了基于使用 REST API 与 HTTP API 以及如何与 NLB 或 ALB 在 VPC 之间整合的可扩展性考量。

在设计 API 层架构时，API 类型和负载均衡器的选择是其他设计因素，但在构建架构时，考虑本文中讨论的可扩展性考量同样重要。通过针对性能、延迟和操作需求优化 API Gateway 实施，您可以构建一个稳健且安全的 API，从而在更大范围内公开微服务。

如需更多无伺服器学习资源，请访问 Serverless Land。

TAG 贡献，无伺服器