在 Amazon API Gateway 中实现多区域故障转移

主要重点

在本文中，您将学习如何将单区域 API Gateway 架构演进为多区域架构，并使用可靠的故障转移机制，而无需依赖 AWS 控制平面操作。文章将提供架构部署和测试的详细步骤，以及开源代码链接。

本帖由 Marcos Ortiz首席 AWS 解决方案架构师和 Khubyar Behramsha资深 AWS 解决方案架构师撰写。

在本文中，您将学习如何将单区域架构的 API Gateway 演进为多区域架构，并使用稳定的故障转移机制而不依赖 AWS 控制平面操作。根据 AWS 最佳实践，恢复过程应该依赖于数据平面而不是控制平面。故障转移控制应运作于与主区域无依赖的模式下。本文展示了如何独立地为部署在共享公共 API 后的不同服务进行故障转移。此外，还提供了如何部署和测试所提议架构的步骤，所有相关代码都可以在我们的 GitHub 开源代码库 中找到。

对于许多组织而言，根据 AWS WellArchitected 最佳实践，在区域 Amazon API Gateway 端点后运行服务提供了弹性、简单性和经济性的良好平衡。但是，根据业务关键性、合规性要求或灾难恢复目标，一些组织必须使用多区域架构来部署其 API。

对于业务关键应用程序，组织通常想完全控制何时以及如何触发故障转移。手动触发的故障转移允许依赖项按特定顺序失效，并遵循批准链，帮助防止转移到未准备的副本或其他由间歇性故障引起的 震荡 问题。虽然故障转移触发器需要人员介入，但建议在后续过程中尽可能自动化，这样可以降低业务不连续性所带来的潜在风险。

总览

客户的一种常见做法是部署具有 自定义域名 的公共区域 API，以为用户提供更直观的 URL。后端使用 API 映射 将多个 API 阶段与自定义域名连接。这种方法允许服务拥有者独立于共享相同顶级 API 域名来部署其服务。以下是一个遵循此模式的典型架构：

然而，在尝试将此架构演进为多区域架构时，组织往往难以独立失效每个服务。如果将上述架构原样部署到两个区域，则会出现全有或全无的情况，组织必须决定是否要失效 API Gateway 后面的所有服务。

演进到多区域架构

为了让每个团队独立管理和失效其服务，您可以为多区域架构实施这一新方法。每个服务都有自己的子域，使用 API Gateway HTTP 集成 来将请求路由到特定服务。这样可让服务 API 获得独立故障转移的灵活性，或与共享公共 API 一起同时失效。

请求流程如下：

用户通过公共共享 API 域名访问特定服务，URL 后缀用于指定服务。例如，访问 service1，最终用户会向 http//examplecom/service1 发送请求。Amazon Route 53 注册了主域名 examplecom 并设置了主要和次要 故障转移记录，将请求路由到主区域 (useast1) 的 API Gateway 外部 API 端点。API Gateway 使用 HTTP 集成 将请求转发到位于 https//service1examplecom 的 service1。Amazon Route 53 注册了域名 service1examplecom 并设置了主要和次要故障转移记录，当健康时将请求路由到主区域 (useast1) 的 API Gateway service1 API 区域端点，当不健康时则路由到次要区域 (uswest2) 的 API 区域端点。显示 Amazon Route 53 中配置的 service1 的主要路径。显示 Amazon Route 53 中配置的 service1 的次要路径。

该解决方案需要在主 (useast1) 和次要 (uswest2) 区域中部署每个服务 API。这两个区域使用相同的自定义域名配置。对于主区域，每个服务的主要 DNS 记录指向区域 API Gateway 发布端点。在次要区域，次要 DNS 记录指向次要区域的区域 API Gateway 发布端点。

主动被动手动故障转移

此处提供的示例实现了一个可靠的故障转移机制，不依赖于 Amazon Route 53 控制平面。它使用 Amazon Route 53 应用程序恢复控制器 Route 53 ARC，该控制器提供五个跨五个不同 AWS 区域的区域端点集群。故障转移过程使用这些端点，而无需手动编辑 Amazon Route 53 DNS 记录，这是一项控制平面操作。Route 53 ARC 中的 路由控制 将流量从主区域转移到次要区域。

路由控制作为开关，允许您将客户流量从一个工作负载实例重新定向到另一个，流量重新路由的结果来自于根据 DNS 健康检查的状态设置为健康或不健康。

部署示例应用

前置条件

使用 Amazon Route 53 注册的公共域名examplecom。请参考这里的指导了解 如何注册域名 和这里的指导 配置 Amazon Route 53 作为您的 DNS 服务。在您计划部署示例 API 的主区域和次要区域中获取 AWS 证书管理器 证书 (examplecom)。

部署 Amazon Route 53 ARC 堆栈

首先部署 Amazon Route 53 ARC 堆栈，这会创建一个集群及路由控制，使您能够故障转移 API。

请参考这里的详细指导 部署 Amazon Route 53 应用程序恢复控制器 (ARC) 堆栈。

在主区域和次要区域中部署 Service1 API

这将在每个区域中部署 API Gateway 区域端点，该端点调用一个 AWS Lambda 函数以返回服务名称和当前 AWS 区域：

json{service service1 region useast1}

以下是 Lambda 函数的代码：

pythonimport jsonimport os

def lambdahandler(event context) return { statusCode 200 body jsondumps({ service service1 region osenviron[AWSREGION]}) }

请参考这里的详细指导 部署 service1 堆栈。

在主区域和次要区域中部署 Service2 API

该堆栈类似于 service1，但有不同的域名并返回 service2 作为服务名称：

json{service service2 region useast1}

请参考这里的详细指导 部署 service2 堆栈。

在主区域和次要区域中部署共享公共 API

这一步配置 HTTP 端点，以便在调用 examplecom/service1 或 examplecom/service2 时，将请求路由到您为 service1 和 service2 设置的相应公共 DNS 记录。

请参考这里的详细指导 部署外部 API 堆栈。

故障转移测试

要测试已部署的示例，请修改并运行提供的测试脚本：

更新 testsh 文件中的第 3 至第 5 行以引用您为 API 配置的域名。提供执行权限并运行脚本：

bashchmod x /testsh/testsh

轻蜂加速app下载

该脚本每 5 秒向您的三个端点发送 HTTP 请求。然后，您可以使用 Amazon Route 53 ARC 独立故障转移服务，并查看来自不同区域的响应。

最初，所有服务都将流量路由到 useast1 区域：

使用以下命令，您可以 更新两个路由控制，将 service1 的主区域 (useast1) 健康检查状态设置为 off，并将次要区域 (uswest2) 健康检查状态设置为 on：

bashaws route53recoverycluster updateroutingcontrolstates updateroutingcontrolstateentries [{RoutingControlArnarnawsroute53recoverycontrol111122223333controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567RoutingControlStateOn}{RoutingControlArnarnawsroute53recoverycontrol111122223333controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321RoutingControlStateOff}] region apsoutheast2 endpointurl https//abcd1234route53recoveryclusterapsoutheast2amazonawscom/v1

几秒钟后，脚本终端显示 service1 现在已将流量路由到 uswest2，而其他服务则仍然将流量路由到 useast1 区域。

要将 service1 故障转移回 useast1 区域，运行以下命令，将 service1 主区域 (useast1) 健康检查状态设置为 on，并将次要区域 (uswest2) 健康检查状态设置为 off：

bashaws route53recoverycluster updateroutingcontrolstates updateroutingcontrolstateentries [{RoutingControlArnarnawsroute53recoverycontrol111122223333controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567RoutingControlStateOff}{RoutingControlArnarnawsroute53recoverycontrol111122223333controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321RoutingControlStateOn}] region apsoutheast2 endpointurl https//abcd1234route53recoveryclusterapsoutheast2amazonawscom/v1

几秒后，脚本终端显示 service1 现在再次将流量路由到 useast1 区域，如同其他服务一样。

清理工作

完成后，请遵循 GitHub 上的清理指导。

结论

这一解决方案使管理关键工作负载的团队能够掌握控制权。通过解耦前端和后端，该方案为组织提供了利用 Amazon Route 53 ARC 在服务级别进行故障转移的细粒度控制，并减少了对控制平面操作的依赖。

所述模式也减少了对服务消费者的影响，因为其允许在从单区域架构过渡到多区域架构时使用相同的公共 API 和顶级域名。

欲了解更多恢复学习，请访问 AWS 架构博客 恢复性。

欲了解更多无伺服器学习，请访问 无伺服器土地。