云原生高可用技术体系的构建思路与难点分析-技术圈

作者 | 张军（游骥），阿里巴巴资深技术专家

原来单一的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得保障业务稳定运行的工作也越来越艰巨。本文从容灾、容量、线上防护、演练四个维度全方位讲解如何构建一个真正的高可用体系。

伴随着互联网业务的高速发展，越来越多的线下场景需要转移到线上，而线上业务的量级也在飞速增长，给互联网业务的技术架构带来了严峻的挑战，原来的“一体机+数据库”的方式已经不适用于当前的主流业务，越来越来的业务开始向分布式架构和云原生架构演进。同时，原来单一的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得保障业务稳定运行的工作也越来越艰巨。

容灾

我们可以看看航空系统的容灾是怎么做的。航空系统的容灾体系做得非常优秀，该系统从人、飞机和环境三个维度来考虑，才能构建一套优秀的容灾方案。

从人的维度，以防万分之一的紧急情况出现的可能，每年要进行多次的模拟机训练或者实景演练。一架飞机上都会配备至少两名飞行员，二者相互合作的同时也要相互监督。
从飞机的维度，每一个航段前，光是一个绕机检查可能就有几十个项目需要检查。机检查是由地面机务人员和飞行机组分别完成，同样也是为了更仔细的检查，降低错误率。每架飞机还有短期全面检查和长期全面检查，飞机上的每一个设备都是独立的双系统在工作。从环境的维度，气象雷达可以让飞行员感知到几十甚至几百海里范围内的天气情况。飞机防撞系统可以让飞行导航显示仪上显示正在接近的可能存在威胁的飞机。盲降系统是由地面发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接收设备，进行降落。从航空业的容灾体系构建中我们可以发现，容灾的核心思想是基于隔离的冗余。在系统设计中，其实也经常用到冗余的机制，比如机器经常是多台、数据是多备份等。容灾的评价指标主要有两个：

RPO（Recovery Point Objective），即数据恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求。
RTO（Recovery Time Objective），即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志着系统能够容忍的服务停止的最长时间，系统服务的紧迫性要求越高，RTO的值越小。

业界主流容灾方案

如下图所示，业内主流的容灾方案最早是异地冷备的方式，后来演进到同城双活方式，最后发展成为“两地三中心”。

业界主流容灾方案 阿里 AHAS
阿里 AHAS 容灾方案使用的是比“两地三中心”更前沿的“异地多活”方案，在所有的数据中心都能提供服务的同时，RPO 和 RTO 能做到分钟级甚至秒级。下图是阿里 AHAS 的产品形态。AHAS 在 2013 年之后就开始大规模在阿里内部使用，并且作为高可用平台的一个核心模块，开始服务外部客户。AHAS 通过异地多活，能够真正做到对于宏观架构的容灾，并抵御大规模的失败场景。比如一个城市的机房出了故障，可以很轻易地把流量实时切换到另外一个机房。

AHAS 异地多活的产品形态
容量

在互联网业务下，流量的不确定性非常明显，经常会出现流量高峰事件，比如微博的热点、阿里的双 11、12306 的火车票放购等事件。在这种场景下，如何做好容量规划就变得至关重要。

压测
传统的压力测试通常关注的是性能的好坏，这是一个相对模糊的概念，不需要很精准。但是在互联网的情况下，我们需要精准地获取到一个系统的实时吞吐量，以便更好地应对突发事件。在这种情况下，压测要尽可能地模拟一个真实的环境，而不能像以往一样，在一个特殊的环境去测试。压测时在流量规模、流量模型、系统环境上都需要一个尽可能真实的环境，这样才能精准做好容量规划。传统的压测工具虽然仍在发挥作用，但是随着互联网的发展，已经越来越不能去适应互联网技术的迭代。互联网的压测有几个明显的特点：

强调流量的真实性；
压测规模要足够大；
必须简单易用。

当下互联网压测已经变成了一个实时的产品，方便进行实时的调控。基于这样的背景，阿里构建了基于PTS的流量引擎，大家可以在阿里云上直接使用，其特点如下：
1、流量真实。流量来源于全国上百城市，覆盖各运营商（可拓展至海外），真实模拟最终用户的流量来源，相应的报表、数据更接近用户真实体感；发现端到端更多更全面的问题，压测即是模拟考。
2、压测规模强大，可支持 3kW QPS 。
3、简单易用，门槛低。复杂场景的全可视化编排，支持自定义编排能力、指令、控制、函数等相关能力，覆盖 95% 以上的 HTTP 压测场景，和 JMeter 构建能力不相伯仲，同时免去复杂的理解学习成本；除了自身丰富的客户侧监控数据，还可集成云监控和 ARMS 监控。压测过程提供日志明细查询，配套有请求瀑布模型，压测之后的报告和问题定位更方便。结合 AHAS 可额外提供流量吞吐控制能力、容量水位管理、熔断降级保护功能。除了强大的自研功能，对于开源 JMeter 的支持也很友好，支持 JMeter 脚本转化为 PTS 压测，同样支持原生 JMeter 引擎进行压测。 全链路压测
在实践中发现，单系统单应用的压测与真实场景之间的误差非常大，因为在压测的时候无法验证整个系统的方方面面，而且很多问题只有在真正的大流量场景下才会暴露，所以要进行全链路压测，其核心是希望未来的事件能够提前到在当前时间内发生，能够用最真实的场景来端对端的验证系统的能力和稳定性。为了实现更好地进行全链路压测，阿里云提出了基于PTS的全链路压测，其架构如下图所示。

基于PTS的全链路压测从压测环境、压测基础数据、压测流量（模型、数据）、流量发起和问题定位对基于PTS的全链路压测解决方案总结如下：
压测环境：对应真实的线上环境，压测结果和问题暴露都是最真实的情况，可通过压测流量全局识别、透传（影子表），或者等比隔离环境，或复用生产库（压测使用测试数据），业务挡板。压测基础数据：构造满足大促场景的核心基础相关数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤和脱敏，保持和线上一个量级。压测流量（模型、数据）：链路范围、访问量级、参数集合、基础数据的特性一起构造压测的业务模型，和真实业务情况保持一致。流量发起：模拟全国各地真实的用户请求访问，探测站点能力。问题定位：发起侧多维度的监控和报表，服务端可通过其他生态产品协助定位。

线上防护

线上防护对于容灾体系来说是一个非常重要的环节。随着分布式技术的应用，节点越来越多，技术越来越复杂，出错的机会也相对增大。同时，在互联网的条件下，业务的发布也越来越频繁，bug 也随之增多。在互联网的环境下，系统随时面临一些不确定事件、流量冲击等，不能奢望每次出现故障的时候都有人工来干预，而是需要系统自身有一定的防护能力，能够让自身在任何环境下都能有最佳的工作状态。

AHAS流量防护
阿里云将流量防护广泛应用于各种场景，比如双 11 峰值流量、秒杀活动、物流、订单处理、商品查询、付款等。同时，阿里云也成功地将流量防护能力融合到了云产品 AHAS（Application High Availability Service，应用高可用服务）中。AHAS 涵盖了阿里巴巴多年来在应用高可用服务领域的技术沉淀，包括架构感知、流量防护、故障演练和功能开关四大独立的功能模块。如下图所示， AHAS 构建了一个从入口到最后端的一个完整的防护体系。

AHAS 经典流量防护布局 AHAS针对大流量场景的保护措施 流量防护首先需要考虑的是对大流量场景的保护，比如url、服务提供方、重点业务等，突然出现超乎预期的大流量，基于AHAS可以做如下防护措施：
1、如果有性能压测，可以精准设置 QPS 阈值。有了 QPS 阈值，可以用来限流，避免出现超负载的流量。2、如果没有性能压测，也可以通过秒级监控，实时设置阈值。3、支持高阶功能：流控模式支持直接、关联、链路，流控方式支持快速失败、Warm Up、排队等待。 AHAS 针对不同场景的措施——异常隔离
在特定未知的场景下，可能出现不稳定的因素，如慢SQL，甚至死锁，导致整个应用越来越慢，甚至整个应用没有响应，这时候要对异常流量进行隔离，以免影响到正常的流量。 AHAS针对不同场景的措施——系统防护 在某些场景下，比如系统的负载 CPU 飙升，系统没有反应，无法确认具体哪个接口导致问题的出现，这时 AHAS 提供了一个终极大招：系统保护。系统保护就是当系统负载比较高的时候，会自动根据入口流量和系统的负载取得一个动态的平衡，保证系统不会恶化的同时，也能处理最大的入口请求。在这种情况下，系统对各种流量都是平等的，无法设置流量的优先级。

演练

很多故障是一个小概率事件，但是一旦发生，所造成的损失是不可估量的，比如巴黎圣母院的火灾。互联网业务也是一样，小概率的故障也可能带来不可挽回的经济损失，甚至是法律风险。因此，故障演练是一个完备的容灾体系所必需进行的一步。

企业为什么需要做故障演练？ 如果一个业务系统的流量很小且趋于稳定，就没有必要进行故障演练。但是如果一个企业处于高速发展中，业务发展快，有大量的稳定性技术债，其业务系统不断的变化，甚至今天的形态跟昨天的形态都不一致，架构也日益复杂，那么故障演练就是十分必要且必需的。因为每个环节的不确定因子都是累积的，如果不进行故障演练，最后一旦发生故障，极大可能会对系统造成严重破坏。故障演练还可以培养企业人员的故障处理经验，增强人员的应急能力。 企业引入故障演练遇到的常见问题 在企业进行故障演练的时候，经常会遇到一些问题，比如如何设计组织架构，如何选择技术方案，如何落地演练实践等。如果业务牵涉到资金，就要做一个清晰化的深层评估，不要因为演练导致出现资金上的亏损，比如在演练中用到的收费内容（例如短信等）要考虑周全。 阿里的故障演练方案 如下图所示，阿里有一套完整的故障演练方案。一开始是通过一些工具或者脚本，在2016年之后才开始将通用的故障模式沉淀为系统。2018年阿里将内部沉淀多年的实践正式在阿里云商用，2019年将沉淀多年的故障注入场景正式开源，成为国内首个混沌工程开源产品。