使用亚马逊 API Gateway 私有集成进行扩展架构

作者： 詹姆斯·贝斯威克 | 202 日

这篇文章由高级解决方案架构师利尔·萨丹和高级解决方案架构师阿南德普拉桑娜·盖通德撰写。

组织使用 Amazon API Gateway 来构建安全、强大的 API，向其他应用程序和外部用户提供内部服务。当环境发展到许多微服务时，客户必须确保 API 层能够在不影响安全性和性能的情况下处理规模。API Gateway 提供各种 API 类型和集成选项，构建者必须考虑随着微服务环境的发展，每个选项如何影响安全、高性能地扩展 API 层的能力。

这篇博文比较了用于构建可扩展的私有集成的架构选项与适用于微服务的 API Gateway。它涵盖了 REST 和 HTTP API 及其对私有集成的使用，并展示了如何开发安全、可扩展的微服务架构。

概述

以下是典型的 API Gateway 实现，它与各种微服务进行了后端集成：

A typical API Gateway implementation with backend integrations to various microservices

API Gateway 处理 API 层，同时与在 亚马逊 EC2 、亚马逊弹性容器服务 (EC S) 或 亚马逊弹性 Kubernetes 服务 (EKS) 上运行的后端微服务 集成。本博客重点介绍容器化微服务，这些服务暴露内部端点，然后由API层向外部公开。

为了保护微服务安全并防止外部流量，它们通常在私有子网中的 亚马逊虚拟私有云 (VPC) 中实现，该子网无法从互联网访问。API Gateway 提供了一种通过使用 VPC 链接 进行私有集成，在 VPC 之外安全地暴露这些资源的方法。私有集成将发送到 API 的外部流量转发到私有资源，而无需将服务暴露给互联网，也不会离开 亚马逊云科技 网络。如需更多信息，请阅读 设计亚马逊 API Gateway 私有 API 和私有集成 的最佳实践 。

示例场景有四个可以托管在一个或多个 VPC 中的微服务。它显示了通过 VPC 链接将微服务与前端负载均衡器和 API 网关集成在一起的模式。

虽然 VPC 链接支持与微服务的私有连接，但客户可能还有其他需求：

  • 扩大规模：支持 API Gateway 背后的更多微服务。
  • 独立部署：每个微服务的专用负载均衡器使团队能够独立执行蓝/绿部署，而不会影响其他团队。
  • 降低复杂性：能够使用现有的微服务负载均衡器而不是引入其他负载均衡器来实现 API Gateway 集成
  • 低延迟：确保 API 请求/响应流中的延迟降至最低。

API Gateway 提供 HTTP API 和 REST API（请参阅 在 REST API 和 HTTP API 之间 选择 ）来构建 RESTful API 。对于大型微服务架构，API 类型会影响集成注意事项：

VPC link supported integrations Quota on VPC links per account per Region
REST API

网络负载均衡器 (NLB)

20

HTTP API

网络负载均衡器 (NLB)、 应用程序负载均衡器 (ALB) 和 亚马逊云科技 Cloud Map

10

考虑到适用于 REST 和 HTTP API 的 VPC 链接的不同功能和配额，本文介绍了四个私有集成选项：

  • 选项 1： 使用 VPC 链接到多个 NLB 或 ALB 的 HTTP API。
  • 选项 2 ：使用多个 VPC 链接的 REST API。
  • 选项 3 ：使用 VPC 链接与 NLB 连接的 REST API。
  • 选项 4： 使用 VPC 链接连接到 NLB 和 ALB 目标的 R EST API。

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

HTTP API 允许将单个 VPC 链接连接到多个 ALB、NLB 或在 亚马逊云科技 Cloud Map 服务中注册的资源。这提供了一种连接多个后端微服务的扇出方法。但是，与特定 VPC 链接集成的负载均衡器应位于同一 VPC 中。

Option 1: HTTP API using VPC link to multiple NLB or ALBs

两个微服务位于一个 VPC 中，每个微服务都有自己的专用 ALB。ALB 侦听器将 HTTPS 流量定向到相应的后端微服务目标组。一个 VPC 链接连接到该 VPC 中的两个 ALB。API Gateway 使用基于路径的路由规则将请求转发到相应的负载均衡器和相关的微服务。 设计亚马逊 API Gateway 私有 API 和私有集成 的最佳实践 — HTTP API 中介绍了这种方法 。 用于部署此解决方案的 CloudFormation 示例模板可在 GitHub 上找到。

您可以在 VPC IP 空间限制内添加其他 ALB 和微服务。使用 网络地址使用率 (NAU) 设计微服务在 VPC 上的分布。在 VPC 链接配额内，通过添加 VPC 链接来连接更多 VPC，扩展到一个 VPC 以外。您可以通过使用路由规则（例如在ALB中使用基于路径的路由）在单个ALB后面连接更多服务（请参阅 应用程序负载均衡器的 配额 ）来进一步扩展此范围。 也可以使用 NLB 构建此架构。

好处：

  • 高度的可扩展性。使用 ALB/NLB 的单个 VPC 链路和/或多路复用功能分散到多个微服务。
  • 与现有微服务负载均衡器直接集成，无需引入新组件并减轻运营负担。
  • 由于直接集成，可以降低 API 请求/响应的延迟。
  • 每个微服务都有专用的负载均衡器，可以实现微服务团队的独立部署。

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

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

  • NLB 是 REST API 唯一支持的私有集成。
  • REST API 的 VPC 链接只能有一个目标 NLB。

Option 2: REST API using multiple VPC links

每个 NLB 都需要 VPC 链接，即使 NLB 位于同一 VPC 中。每个 NLB 都为一个微服务提供服务，其侦听器将 API 网关流量路由到目标组。基于 API Gateway 路径的路由向相应的 NLB 和相应的微服务发送请求。此私有集成所需的设置与 教程：使用 API Gateway 私有集成构建 REST API 中描述的示例类似 。

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

好处：

  • 请求路径中的单个 NLB 可降低操作复杂性。
  • 每个专用 NLB 支持独立的微服务部署。
  • API 请求路径中没有额外的跳数可以降低延迟。

注意事项：

  • 由于 VPC 链接与 NLB 和微服务进行一对一映射，因此限制了可扩展性，受每个区域每个账户的 VPC 链接配额的限制。

选项 3：使用带有 NLB 的 VPC 链接的 REST API

由于 VPC 链路配额，选项 2 中的 VPC 链接到 NLB 和微服务的一对一映射存在可扩展性限制。另一种选择是每个 NLB 使用多个微服务。

Option 3: REST API using VPC link with NLB

单个 NLB 通过使用多个侦听器在 VPC 中管理多个微服务，每个侦听器位于每个微服务的单独端口上。在这里，NLB1 在一个 VPC 中前置两个微服务。NLB2 在第二个 VPC 中前置另外两个微服务。由于每个 NLB 有多个微服务，因此在为方法选择集成点时会为 REST API 定义路由。 您可以结合选择 VPC 链接 （与特定 NLB 集成）和在 NLB 侦听器中为每个微服务分配并通过终端节点 URL 寻址的特定端口，来定义每项 服务。

要进一步扩展，请向现有 NLB 添加更多侦听器，但受 网络负载均衡器 配额的 限制。 如果每个微服务都有其专用的负载均衡器或接入点，则将其配置为 NLB 的目标。或者，通过添加其他 VPC 链接来集成其他微服务。

好处：

  • 更大的可扩展性——受到 NLB 侦听器配额和 VPC 链路配额的限制。
  • 管理支持多个微服务的更少的 NLB 可以降低操作复杂性。
  • 低延迟，请求路径中只有一个 NLB。

注意事项：

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

选项 4：使用 VPC 链接连接到 NLB 和 ALB 目标的 REST API

客户通常使用 ALB 作为接入点来构建微服务。要通过 API Gateway REST API 公开这些信息，你可以利用 ALB 作为 NL B 的目标 。与选项 3 架构相比，这种模式还增加了支持的微服务数量。

Option 4: REST API using VPC link with NLB and ALB targets

VPC 链接 (vpClink1) 是使用 VPC1 中的 NLB1 创建的。ALB1 和 ALB2 将微服务 mS1 和 mS2 作为前端添加为单独的侦听器上的 NLB 目标。VPC2 也有类似的配置。您的隔离需求和 IP 空间决定了微服务是否可以驻留在一个或多个 VPC 中。

要进一步扩展，请执行以下操作：

  • 创建其他 VPC 链接以集成新的 NLB。
  • 添加 NLB 监听器以支持更多 ALB 目标。
  • 使用基于路径的规则配置 ALB，将请求路由到多个微服务。

好处：

  • 使用 NLB 和 ALB 集成服务的高可扩展性。
  • 当每个 ALB 都专用于单个微服务时，每个团队可以进行独立部署。

注意事项：

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

注意事项和最佳实践

除了本博客中讨论的通过 VPC 链接集成进行扩展的注意事项外，还有其他注意事项：

  • 评估 REST API 和 HTTP API 的 功能以满足您的要求。
  • 为您的应用程序需求选择 最佳的负载均衡器类型 。
  • 有关多账户架构，请参阅 使用亚马逊 API Gateway 和 亚马逊云科技 PrivateLink 构建私有跨账户 API 。
  • 避免快速超过默认配额，并 要求增加配额 以满足更高的限额要求。
  • 监控服务配额，随着架构的发展，主动规划并降低风险。考虑使用 配额监控解决方案 进行监控。
  • 请参阅 设计亚马逊 API Gateway 私有 API 和私有集成 的最佳实践 — Rest API 。

结论

本博客探讨了使用 VPC 链接为微服务构建可扩展的 API 网关集成。VPC 链接允许将外部流量转发到后端微服务，而无需将其暴露到互联网或离开 亚马逊云科技 网络。这篇文章介绍了基于使用 REST API 与 HTTP API 相比的扩展注意事项，以及它们如何在 VPC 之间与 NLB 或 ALB 集成。

虽然 API 类型和负载均衡器的选择还有其他设计因素，但在设计 API 层架构时，请务必记住本博客中讨论的扩展注意事项。通过针对性能、延迟和运营需求优化 API Gateway 的实现，您可以构建一个强大、安全的 API 来大规模公开微服务。

如需更多无服务器学习资源，请访问 无服务器世界 。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。