API302-R | 构建全局事件驱动的应用程序

API302-R | 构建全局事件驱动的应用程序

关键字: [Amazon Web Services re:Invent 2023, Amazon Web Services, Multi Region, Event Driven, Applications, Serverless, Architecture]

本文字数: 2800, 阅读完需: 14 分钟

视频

导读

为事件驱动的应用程序制定多区域策略可以帮助您在服务中断期间故障转移到另一个区域，从而提高应用程序的可用性和可靠性。在本专题讲座中，您将了解如何使用 Amazon EventBridge、Amazon DynamoDB 、Amazon S3 等 serverless 服务实施多区域战略。此外，发现一些最佳实践，可以帮助您的应用程序在出现故障时变得更有弹性。

演讲精华

以下是小编为您整理的本次演讲的精华，共2500字，阅读时间大约是12分钟。如果您想进一步了解演讲内容或者观看演讲全文，请观看演讲完整视频或者下面的演讲原文。

马克西·维拉巴尔，自2016年以来在亚马逊云科技（与原文保持一致）拥有丰富经验的开发者倡导者，首先探讨了针对所有应用程序是否有必要采用多区域架构的问题。尽管亚马逊云科技（与原文保持一致）使得在不同区域间利用服务变得轻松，但她强调，需要考虑诸多挑战，如在美东和欧洲之间传输数据时，由于物理定律和必须传输的距离，可能会导致50-80毫秒的复制延迟。这是简单的物理定律和必须传输的数据距离所导致的。此外，多区域的复杂性还会使分布式系统的测试负担翻倍。因此，她建议仔细评估特定应用程序是否真的需要多区域，而非默认假设其需求。

维拉巴尔总结了企业在考虑多区域架构时常忽略的两个主要缺点：全球范围内相反地区的复制延迟可能达到50-80毫秒，甚至在地区之间可能达到900-9000公里的距离。这种延迟可能会对应用程序的一致性和性能产生负面影响。此外，分布式系统的固有测试复杂性会使测试更加困难。如果没有全面的测试覆盖，企业可能会在追求多区域的好处上付出成本和代价，而实际上并未获得任何收益。

据维拉巴尔介绍，客户实施多区域的一些常见原因是：弹性、高可用性、数据恢复力和灾难恢复。然而，她表示，这些原因并非天生与多区域分布相关。

总之，她建议在实施多区域功能时要谨慎并深思熟虑，只有在好处明显超过复杂性时才能进行。

维拉巴尔简要介绍了一些常见的多区域策略，从相对简单到非常复杂：

数据备份与恢复：将数据复制到另一个区域，但该区域内的基础设施并不运行。故障切换可能需要更多的时间。

引导光：在备用区域中维持最少的基础设施，在故障切换时进行扩展。

热备用：备用区域中的完整环境，数据同步复制。

主动-主动：多个区域的完整环境，根据健康状况检查路由流量。

她注意到，由于无服务器技术，引导光、热备和主动-主动之间的界限变得有些模糊，因为自动缩放可以自动处理容量管理。

数据库模式

为了转换为特定的实现模式，Villalba首先介绍了跨地区数据库复制的不同方法：

• 读本地，写全球：单个主数据库，具有分布全球的读取副本。但是，如果复制滞后，副本可能不完全一致。

• 读本地，写分区：按地区分区的数据库，各地区全球复制。缺点是用户在地区之间旅行时可能出现问题。

• 读本地，写本地：多主完全复制数据库。风险是与并发写入冲突。

就服务而言，选项包括：

• S3跨区域复制：异步地在跨区域S3存储桶之间复制。

• DynamoDB全球表：多主模型，“最后写入者获胜”的冲突解决。

事件模式

对于事件驱动的架构，常见模式包括：

• 主动-被动：事件复制到备用区域，但在该区域不处理。

• 主动-主动：事件复制并在多个区域处理。风险是可能处理重复的事件。

相关的服务包括：

• EventBridge全球终点：处理事件复制和故障自动切换，在DNS级别自动处理。

Villalba提供了一个使用EventBridge全球终点的演示，以展示如何在两个区域之间复制事件。她展示了如何使用CloudWatch警报创建健康检查来监控健康状态，并在需要时触发自动化故障切换。最初，两个区域冗余地处理事件，所以她添加了基于源地区的去除重复的逻辑。

数据和秘密

跨地区管理数据和秘密也带来了挑战：

• 使用S3跨区域复制来实现跨地区的对象存储的韧性。

• 使用KMS对秘密进行加密，因为S3和KMS都支持多地区。

对于Cognito这样的用户数据，通过DynamoDB进行复制，并在故障切换期间需要重新创建密码。

在使用任何第三方服务时，请务必谨慎评估其多区域功能，并对故障切换进行充分测试。

流量路由

Route53提供了基于DNS的跨区域流量路由选项：

• 基于延迟的 - 将用户路由到最近的区域。
• 基于地理的 - 根据用户的地理位置进行路由。
• 基于健康检查 - 根据资源的健康检查进行故障切换。 Villalba展示了一个使用Route53根据用户位置在不同区域之间进行路由的示例，该示例是基于延迟的路由应用。

开发人员的考虑因素

从架构师的角度转向开发人员，Villalba概述了应用程序团队在使用多区域架构时需要考虑的关键因素：

• 利用基础设施即代码进行跨区域的一致部署。
• 一次部署一个区域，并进行充分测试。
• 安排部署窗口以最小化对用户的影响。
• 使用蓝色/绿色部署以便在出现问题时轻松回滚。
• 在所有区域中集中日志以实现统一的可观察性。
• 针对恢复能力和性能进行严格的测试。
• 进行模拟故障或降级情况的“游戏日”活动。
• 使用故障注入服务来测试各种失败情况。 总的来说，虽然多区域架构带来了好处，但它们也大大增加了复杂性。组织应仔细评估其特定需求，并实施使用全球端点和Route53等模式和服务的针对性解决方案。特别是要进行全面的测试，包括故障注入,以确保恢复能力。关注点是部署策略和故障切换准备。 Villalba在她的博客和Serverless Land网站上提供了详细的演示视频、示例代码和更多关于实施全球无服务器应用的参考资料。她鼓励与会者有任何其他问题都可以联系她。

下面是一些演讲现场的精彩瞬间：

艾莉莎解释道，对于高可用性而言，多区域架构往往是多余的，客户应关注多可用区部署、备份和快照。

亚马逊云科技提供了自动扩展功能以应对流量增长以及有效的主动灾难恢复能力。

基于CAP定理，演讲者探讨了在多区域架构中实现一致性和可用性的挑战。

领导者们详细解释了红本地白全球模式，该模式通过在全球范围内复制数据以提供低延迟读取，同时维持一个单主写数据库。

建议在使用亚马逊云科技构建全球分布式应用程序时，使用Amazon Route 53进行自动故障切换和健康检查。

领导者们讨论了亚马逊云科技网站上提供的用于实施全局终结点和API网关故障切换的模式。

总结

1. 在实现多区域覆盖时，并非所有组件都需要进行复制。我们需要评估灾难恢复需求和延迟优化目标，以确定在不同区域之间复制哪些内容。例如，数据库可以采用单一可写主读副本或分布式多主写的读取副本等模式。

2. 对于事件驱动的架构，Amazon EventBridge的全球端点可以实现跨区域间的自动流量重定向和事件复制。在处理复制的事件时应注意避免重复处理。

3. 使用如亚马逊云科技密钥管理器等服务在不同区域间复制机密和敏感数据。对于用户数据，Cognito目前并不支持多区域支持，但存在一些替代方案，如将用户数据复制到DynamoDB。

4. 使用Route 53提供的基于延迟的路由、地理目标和健康检查功能，可以在不同区域间路由流量。结合全球端点，可实现灾难恢复并将用户引导到最佳区域。

总之，实现多区域可用性需要进行复杂的架构设计。在设计过程中，我们需要将架构决策与灾难恢复、延迟优化或数据位置特定的目标保持一致。在选择区域服务、复制关键数据库、正确处理事件以及全面测试故障转移场景方面，我们需要谨慎行事。虽然亚马逊云科技提供了许多简化全球部署的托管服务，但全面的规划和测试仍然是必不可少的。

演讲原文

https://blog.youkuaiyun.com/weixin_46812959/article/details/134588378

想了解更多精彩完整内容吗？立即访问re:Invent 官网中文网站！

2023亚马逊云科技re:Invent全球大会 - 官方网站

点击此处，一键获取亚马逊云科技全球最新产品/服务资讯！

点击此处，一键获取亚马逊云科技中国区最新产品/服务资讯！

即刻注册亚马逊云科技账户，开启云端之旅！

【免费】亚马逊云科技“100 余种核心云服务产品免费试用”

【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用”

亚马逊云科技是谁？

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者，自 2006 年以来一直以不断创新、技术领先、服务丰富、应用广泛而享誉业界。亚马逊云科技可以支持几乎云上任意工作负载。亚马逊云科技目前提供超过 200 项全功能的服务，涵盖计算、存储、网络、数据库、数据分析、机器人、机器学习与人工智能、物联网、移动、安全、混合云、虚拟现实与增强现实、媒体，以及应用开发、部署与管理等方面；基础设施遍及 31 个地理区域的 99 个可用区，并计划新建 4 个区域和 12 个可用区。全球数百万客户，从初创公司、中小企业，到大型企业和政府机构都信赖亚马逊云科技，通过亚马逊云科技的服务强化其基础设施，提高敏捷性，降低成本，加快创新，提升竞争力，实现业务成长和成功。