如何构建可靠云服务：亚马逊云科技的云端韧性之道

“控制面和数据面的隔离，类似于叫车软件和打车，两者其实是相对独立的。当你坐上车以后，如果一段时间叫车软件没有信号无法响应了，也不影响司机将你送到预定的目的地。很多故障失效的情况，关键在于没有把数据面和控制面做到很好的隔离。”谈到云服务的故障问题时，亚马逊云科技大中华区解决方案架构总经理代闻给出了这样的比喻。

为什么云服务需要韧性

从云计算技术诞生至今，云服务对于广大企业来说，已经成为了像水、电、煤气一样不可或缺的基础服务。然而也正是因为如此，每当云服务出现故障时，也动辄会给企业带来难以估量的重大损失。回顾近年来多家云服务商的宕机事件，类似的惨痛教训可谓不胜枚举。

作为全球云计算技术的开创者和领军者，亚马逊云科技在2006年开创性地发布了第一款云服务。在过去的18年中，亚马逊云科技通过持续不断的研发与创新，迄今为止已经提供了超过240种功能全面的服务，在全球拥有数百万家客户，并且已经连续13年蝉联Gartner云基础设施和平台服务魔力象限领导者。

“亚马逊云科技去年每天稳定启动的Amazon EC2实例超过1亿，每秒API请求数高达100万亿。正是因为做对了很多事情，才有今天全球数百万客户的选择和信任。”代闻介绍道。

从云计算技术的原理来说，云服务本身就是根据客户实际需求提供的弹性基础设施服务，那为什么还会出现如此诸多的宕机故障？

在代闻看来，云服务系统故障的原因主要可以分为三类：一是基础设施层，包括数据中心、主机、机架、网络故障或是自然灾害导致的损坏；二是架构设计层，包括数据状态、应用程序状态异常、依赖项失效等；三是运营机制层，包括由运维操作、代码部署、配置错误等引起的故障。因此在云计算的韧性技术实现中，亚马逊云科技最关注的就是基础设施、架构设计和运营机制等三个方面。

如何构建可靠的云服务

既然云服务对于企业用户如此重要，那么应该如何构建可靠的云服务？亚马逊云科技对此又有着怎样的心得体会？

代闻给出的回答是，亚马逊云科技的云端韧性之道，就在于基础设施韧性、韧性技术架构和卓越的运营机制。

一、基础设施韧性

亚马逊云科技在全球范围内构建了强大的基础设施，确保其云服务的高度可靠性和低延迟。其在世界各地聚集数据中心的物理位置称之为区域，区域下面的每个逻辑数据中心组称为可用区，每个区域由三个或更多可用区组成，每个可用区又由多个或单个超大数据中心连接组成，具备独立的电力、制冷和物理安全设施。为了防止单一故障点的影响，同一区域内的可用区相距约100公里，确保在一个可用区发生电力中断或自然灾害时，其他可用区不受影响。这种设计还能实现毫秒级延迟的同步复制，提高数据的可用性和一致性。

在基础设施网络设计方面，亚马逊云科技还采用了高可用、低延迟的架构。在可用区内部，数据中心之间通过冗余链路互联；在可用区之间，则通过传输中心实现多条冗余链路的连接；而在区域与区域之间，通过冗余的连接中心站点和分布的冗余链路实现互联。这些设计共同构成了坚实的基建骨干网络。截至目前为止，亚马逊云科技在全球34个地理区域运营者108个可用区，能够帮助中国出海企业以更低延迟构建和运行应用程序，从而更加接近最终用户。

二、韧性技术架构

为了提升云服务的可靠性和稳定性，亚马逊云科技提出了云服务韧性的四大要素：区域隔离与多可用区、控制面与数据面独立、单元架构以及随机分片。

1、区域隔离与多可用区：根据故障隔离边界，亚马逊云科技将服务划分为可用区级、区域级、全球级三种不同类别，以控制故障发生时对客户的影响范围。譬如Amazon IAM通过分布式计算和存储单元，即使全球控制平面故障，各区域的数据平面仍可独立提供认证授权服务。

2、控制面与数据面独立：亚马逊云科技将服务拆分为控制平面和数据平面，确保数据平面在控制平面故障时仍能正常运行。同时两者还可独立扩展，满足不同需求。譬如对客户来说，Amazon EC2实例在启动后的持续正常运行，要比启动新实例的能力更为关键。

3、单元架构：系统被分解成更小的独立单元，当某一单元发生故障时，影响只局限在该单元内，而不会导致整个系统瘫痪。譬如亚马逊云科技为常规数据库添加分片分区层，在故障发生时就能将影响降到最低。

4、随机分片：进一步提升系统可用性，通过随机分配数据到不同节点，即使部分节点失效，系统整体仍能正常运作。

三、卓越的运营机制

为了提高云服务的韧性，亚马逊云科技将运营机制总结为4个模块，这也成为了其在市场上的差异化优势。

1、服务责任模型：采用服务所有权模型，激励团队不断改进运营。由小型多学科团队负责工程和产品管理工作，从设计、启动服务到生产运营各个环节都确保高质量服务。

2、运营就绪性审查（ORR）：所有新服务发布前需通过ORR流程审查，涵盖韧性及其他最佳实践。服务部署后每周举行运营会议，检查系统运营性能及待解决问题。

3、安全、持续部署：使用自动化管道进行服务更新，通过生产前测试、自动回滚及交错生产部署，逐步验证确保部署安全。譬如更新先在单一服务器上测试验证，再逐步推广和部署至整个可用区乃至其他区域。

4、纠错流程：通过纠错（CoE）流程分析根本原因，并组织推动全公司工程冲刺，确保类似问题不再发生。这些经验会被记录和纳入ORR流程，持续改进服务质量。

助力企业构建端到端的韧性

在多年来与客户和内部团队合作的基础上，亚马逊云科技为韧性构建工程总结归纳了4大经验：

1、系统韧性的提高是持续的过程，而不是一次性的努力；

2、在业务需求、可靠性、成本、系统复杂度之间取得均衡；

3、以标准软件开发生命周期为蓝本，可轻松整合到企业现有流程中；

4、从业务、技术与持续运营等多个维度来帮助企业提高系统韧性。

基于多年积累的尽管，亚马逊云科技开发了韧性系统建设生命周期框架, 共包含5个关键阶段：

1、设定目标：明确定义韧性的目标和要求，评估现有系统的韧性水平，并制定改进计划，重点环节包括系统风险识别和业务指标识别等。

2、设计及实施：基于韧性最佳实践，构建具有适当韧性控制措施的工作负载和系统，重点环节包括备用、高可用方案，容灾方案等。

3、验证和测试：提高通常的测试以及混沌工程，验证已知风险，探索未知风险，重点环节包括可观测性建设、混沌工程等。

4、持续运营：实施自动化、监控、变更管理等各种运营最佳实践，持续提高系统的可观测性和自动化性。

5、响应和改进：定期回顾韧性策略和措施的有效性，不断进行调整改进，总结发生事故根因，避免问题再次发生。

亚马逊云科技希望客户也能够采用同样的单元架构方法论，来最小化自身应用的爆炸半径，提高可用性。目前其90%以上的服务源自用户需求，并在韧性系统建设生命周期框架的5个阶段都提供了多种服务和工具。

譬如，在设定目标阶段，Amazon Resilience Analysis Framework可提供指导方案；在设计和实施阶段，Amazon Aurora和Amazon DynamoDB支持多可用区同步，Amazon Aurora Global Database可实现跨区域快速本地读取和灾难恢复；在验证和测试阶段，Amazon Fault Injection Simulator（FIS）可帮助模拟现实干扰，发现潜在弱点并提供改善建议；此外还有覆盖多个阶段的Amazon Resilience Hub韧性监测中心，Amazon DevOps Guru使用机器学习检测异常运维模式，Amazon Application Recovery Controller（ARC）简化应用程序恢复，Amazon Route 53集成ARC功能简化恢复流程，以及贯穿全生命周期的Well-Architected Framework可帮助用户评估系统韧性和健康程度，Amazon Health Dashboard可实时评估和监测用户目前应用状态的健康程度。

来自企业客户的实践案例

2022年，奇瑞捷豹路虎选择了亚马逊云科技，将关键的SAP系统迁移至云端，大幅提升了业务敏捷性和人员工作效率。通过利用亚马逊云科技独有的一个区域三个可用区特性，奇瑞捷豹路虎构建了自适应跨可用区高可用集群，创新性地提出了高可用和同城灾备融合方案。使用云上的三个可用区及仲裁方案，增强了集群的可靠性和稳定性，将故障切换时间从半小时缩短至3分钟，最大限度地减少了停机时间和数据丢失。

从事跨境电商的紫讯科技，在亚马逊云科技的帮助下构建了多区域容灾架构，对核心组件Amazon Aurora数据库进行了高可用改造，实现了主备设置与故障转移。旗下的紫鸟浏览器采用了双Region设计，利用Amazon Route 53、Amazon API Gateway和Amazon Lambda承载核心业务，Amazon Aurora全球数据库功能实现跨区域复制和写转发。业务系统可根据故障率自动启用异地只读或读写模式。通过亚马逊云科技企业支持计划的Trusted Advisor，紫讯持续评估并修复安全隐患，实现了核心产品SLA提升至99.995%，RTO在10分钟内、RPO小于1分钟，并利用Lambda按使用付费，降低了容灾成本。

FreeWheel广告平台为90%以上的美国主流电视媒体和运营商提供服务，其全球性业务特性对系统韧性有着严苛要求，需要在全球多个地区部署服务，并确保跨区域数据同步和低延迟访问。亚马逊云科技帮助FreeWheel完成了多区域多活应用构建，可轻松应对2秒内激增百倍的超大流量。通过采用Amazon Aurora和Amazon DynamoDB替换MySQL数据库集群，使用Amazon S3搭建可扩展存储，FreeWheel不仅提升了基础架构的资源利用率，还利用Serverless技术实现了按需可扩展的基础架构资源，满足了严苛的韧性目标。