[SEO 副标题]
本指南可帮助客户设计具有弹性的三层 Web 应用程序,该应用程序具有 React 前端、API/AWS Lambda 中间层和 Amazon Aurora Global Database 后端。应用程序部署在两个 AWS 区域,以便从一个区域自动失效转移和失效自动恢复到另一个区域,从而实现主动和热备用灾难恢复模式。此外,Amazon CloudWatch 还通过从应用程序堆栈中获取见解并将其与相关的基础设施指标汇总,支持对这种多区域架构进行可观测性检测,这可以帮助客户决定何时将应用程序失效转移到另一个区域。Amazon Route53 应用程序恢复控制器会在多个区域之间路由流量,并通过与 AWS Systems Manager 文档集成来自动进行失效转移。
架构图
-
应用程序在主区域运行
-
跨区域失效转移
-
应用程序在主区域运行
-
第 1 步
用户打开浏览器并进入 Amazon Route 53 上托管的用户界面域名系统(DNS)端点。
第 2 步
请求路由到 Amazon CloudFront 实例。CloudFront 数据面板已面向全球推出。
第 3 步
CloudFront 提供存储在主区域(如果不可用,则在失效转移模式下的次要区域)的 Amazon Simple Storage Service(Amazon S3)存储桶中的静态内容。
第 4 步
CloudFront 受 AWS WAF 保护,AWS WAF 使用标准规则进行配置,用以防范常见的 Web 漏洞。
第 5 步
用户界面通过在主区域配置的 Amazon Cognito 用户池进行身份验证。Amazon Cognito 是一项区域性服务。如果主区域的 Amazon Cognito 服务出现降级或中断,这可能会影响应用程序失效转移。
第 6 步
Route 53 DNS 托管区由 Route 53 应用程序恢复控制器(ARC)提供支持,该控制器包含主要和次要区域的 ARC 控件。ARC 控制相应的运行状况检查,这些检查为 Route 53 托管区中的相应 DNS 记录提供支持。最初,主区域的 ARC 控件处于开启状态,而次要区域的 ARC 控件则处于关闭状态。
第 7 步
主区域运行状况检查变为正常,而次要区域运行状况检查变为不正常。因此,Route 53 API DNS 端点解析为主区域中的 API 端点。
第 8 步
主区域中的 API 端点将调用委托给在主区域运行的相应 AWS Lambda 函数。
第 9 步
应用程序使用 Amazon Aurora Global Database 来存储应用程序事务数据。最初,Aurora 主数据库集群配置为写入器集群,而 Aurora 次要数据库集群则配置为读取器集群。
Aurora 主数据库集群会自动将数据复制到 Aurora 次要数据库集群,这使应用程序能够在次要区域运行(使用从主数据库集群复制到次要数据库集群的数据)。
-
跨区域失效转移
-
第 1 步
用户单击用户界面中的“失效转移”按钮,这将调用托管在 Route 53 上的失效转移 API 端点。
第 2 步
Route 53 DNS 托管区根据 Route 53 ARC 控件的状态路由到主区域中的 API 端点。
第 3 步
系统调用主 API 端点。
第 4 步
主 API 端点将调用委派给在主区域运行的相应 Lambda 函数。第 5 步
Lambda 函数会调用失效转移运行手册,并自动将其作为 AWS Systems Manager 文档。该运行手册会自动执行失效转移过程所涉及的三个步骤。
第 6 步
该运行手册首先将 Aurora 全球数据库从主区域失效转移到次要区域,使次要区域中的数据库集群成为写入器集群,而将主区域中的数据库集群设置为读取器集群。
第 7 步
失效转移后,Aurora 全局集群会配置为自动将数据从次要区域(写入器)的数据库集群复制到主区域的数据库集群(读取器)。
第 8 步
该运行手册使用次要区域中 Aurora 数据库集群的数据库端点更新 AWS Secrets Manager 中的数据库密钥,以便 Lambda 函数使用新的数据库端点与数据库进行交互。
第 9 步
该运行手册翻转了 Route 53 ARC 控件,关闭了主区域的 ARC 控件,并开启了次要区域的 ARC 控件。结果,次要区域运行状况检查变为正常,而主区域运行状况检查变为不正常。Route 53 API DNS 端点解析为次要区域中的 API 端点。这就完成了失效转移。
应用程序将在次要区域上线,并将 API 流量路由到次要区域。它将在次要区域调用 Lambda 函数,并与次要区域中的 Aurora 数据库集群交互。
开始使用
Well-Architected 支柱
当您在云中构建系统时,AWS Well-Architected Framework 可以帮助您了解所做决策的利弊。框架的六大支柱使您能够学习设计和操作可靠、安全、高效、经济高效且可持续的系统的架构最佳实践。使用 AWS 管理控制台中免费提供的 AWS Well-Architected Tool,您可以通过回答每个支柱的一组问题,根据这些最佳实践来检查您的工作负载。
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构,您应该遵循尽可能多的 Well-Architected 最佳实践。
-
卓越运营
本指南通过确保企业能够通过失效转移到次要区域来继续运行业务服务,实现对卓越运营的支持。
-
安全性
将 WAF 与 CloudFront 结合使用可保护应用程序免受常见漏洞的侵害,而使用 Amazon Cognito 可对用户界面和 API 访问进行身份验证。
-
可靠性
对工作负载的关键性能指标(KPI)进行自动故障监控,并在超出阈值时触发自动失效转移。
-
成本优化
使用 Amazon API Gateway 和 Lambda 处理事务,以避免预置计算资源。
-
可持续性
本指南是无服务器的,可最大限度地减少您的碳足迹。
相关内容
免责声明
示例代码;软件库;命令行工具;概念验证;模板;或其他相关技术(包括由我方人员提供的任何前述项)作为 AWS 内容按照《AWS 客户协议》或您与 AWS 之间的相关书面协议(以适用者为准)向您提供。您不应将这些 AWS 内容用在您的生产账户中,或用于生产或其他关键数据。您负责根据特定质量控制规程和标准测试、保护和优化 AWS 内容,例如示例代码,以使其适合生产级应用。部署 AWS 内容可能会因创建或使用 AWS 可收费资源(例如,运行 Amazon EC2 实例或使用 Amazon S3 存储)而产生 AWS 费用。
本指南中提及第三方服务或组织并不意味着 Amazon 或 AWS 与第三方之间存在认可、赞助或从属关系。AWS 的指导是一个技术起点,您可以在部署架构时自定义与第三方服务的集成。