以下是视频内容的精华整理。

伴随着互联网业务的高速发展，越来越多的线下场景需要转移到线上，而线上业务的量级飞速增长，也给互联网业务的技术架构带来了严峻挑战，原来的“一体机+数据库”的方式已经不适用于当前的主流业务，越来越来的业务开始向分布式架构和云原生架构演进。同时，原来单一的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得我们保障业务稳定运行的工作也越来越艰巨。
依据阿里云的实践经验，将以下四个维度做好了才能真正构建一个高可用体系，下文从这四个维度介绍如何构建一个云原生高可用技术体系。
容灾：切流，同城双活，异地多活；
容量：全链路压测，瓶颈探测，容量规划；
线上防护：流量防护，开关预案，流量调度；
演练：故障演练，容灾演练，预案演练。

一、容灾

航空系统的容灾体系做的是非常优秀的。如下图所示，航空系统的容灾体系从人、机和环境三个维度来考虑，才能构建一套优秀的容灾方案。

从航空业的容灾体系构建中我们可以发现容灾的核心思想——冗余。在系统设计中，其实我们也经常用到冗余的机制，比如机器经常是多台的、数据是多备份的等等。
容灾的评价指标主要有两个：
RPO：Recovery Point Objective，即数据恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求；
RTO：Recovery Time Objective，即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求；RTO标志系统能够容忍的服务停止的最长时间，系统服务的紧迫性要求越高，RTO的值越小。

（一）业界主流容灾方案

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

（二）阿里AHAS

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

二、容量

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

（一）压测

传统的压力测试，我们通常关注的是性能的好坏，是一个相对模糊的概念，不需要很精准。但是在互联网的情况下， 我们需要精准的获取到一个系统的实时吞吐量，以便能更好的应对突发事件。在这种情况下，压测必须要尽可能的模拟一个真实的环境，而不能像以往一样，在一个特殊的环境去测试，压测时在流量规模、流量模型、系统环境上都需要一个尽可能真实的环境，这样子才能在故障发生时从容应对。

传统的压测工具虽然仍在发挥着作用，但是随着互联网的发展，却越来越不能去适应互联网技术的迭代。互联网的压测有着几个特点：
强调流量的真实性；
压测规模要足够大；
必须简单易用；
如今的互联网压测已经变成了一个实时的产品，方便进行实时的调控。基于以上，阿里构建了基于PTS的流量引擎，大家可以在阿里云上直接使用，其特点如下图所示。

（二）全链路压测

在实践中，我们发现单系统单应用的压测与真实场景之间的误差非常大，因为在压测的时候无法验证整个系统的方方面面，而且很多问题只有在真正的大流量场景下才会暴露，所以要进行全链路压测，其核心是希望未来的事件能够提前的在当前时间内发生，能够用最真实的场景来端对端的验证系统的能力和稳定性。

为了实现更好的全链路压测，阿里提出了基于PTS的全链路压测，其架构如下图所示。

从压测环境、压测基础数据、压测流量（模型、数据）、流量发起和问题定为对基于TPS的全链路压测解决方案总结如下：

三、线上防护

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

（一）AHAS流量防护

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

（二）AHAS针对大流量场景的保护措施

流量防护最首先需要考虑的就是对大流量场景的保护，比如url，服务提供方，重点业务等，突然出现超乎预期的大流量，基于AHAS可以做如下防护措施：
（1）如果有性能压测，可以精准设置QPS阈值，有了QPS阈值，可以用来限流，避免出现超负载的流量；
（2）如果没有性能压测，也可以通过秒级监控，实时设置阈值；
（3）支持高阶功能：流控模式支持直接、关联、链路，流控方式支持快速失败、Warm UP、排队等待。

（三）AHAS针对不同场景的措施——异常隔离

在特定未可知的场景，可能出现不稳定因素，例如慢SQL，甚至死锁，导致整个应用越来越慢，甚至整个应用没有响应，这时候要对异常流量进行隔离，以免影响到正常的流量。

（三）AHAS针对不同场景的措施之系统防护

在某些场景下，比如系统的负载CPU飙升，系统没有反应，来不及定为具体哪个接口导致这个原因，这时候AHAS提供了一个终极大招：系统保护。系统保护就是当系统负载比较高的时候，会自动根据入口流量和系统的负载取得一个动态的平衡，保证系统不会恶化的同时，同时处理最大的入口请求。但是这种情况下，系统对各种流量都是平等的，无法设置流量的优先级。

四、演练

很多故障是一个小概率事件，但是一旦发生，所造成的损失是不可估量的，比如巴黎圣母院的火灾。同样的，互联网业务也是一样，小概率的故障也可能带来不可挽回的经济损失，甚至是法律风险，系统崩溃了，痛的可能不仅是股价，更重要的是信任和用户流失。因此，故障演练是一个完备的容灾体系所必须进行的一步。

（一）企业为什么需要做故障演练

如果一个业务系统的流量很小且趋于稳定，那么是没有必要进行故障演练的，但是如果一个企业处于高速发展中，业务发展快，有大量的稳定性技术债，其业务系统不断的变化，甚至今天的形态跟昨天的形态都不一致，架构也日益复杂，那么故障演练就是十分必要且必需的。因为每个环节的不确定因子都是累积的，如果不进行故障演练，最后一旦发生故障，极大可能会对系统造成严重破坏。进行故障演练，还可以培养企业的人员故障处理经验，增强人员的应急能力。

（二）企业引入故障演练遇到的常见问题

在企业进行故障演练的时候，经常会遇到一些问题，比如如何设计组织架构？如何选择技术方案？如何落地演练实践？更多的问题见下图。在解决这些问题的时候，我们需要注意一个问题就是如果业务牵涉到资金，就要做一个清晰化的深层评估，不要因为演练导致出现资金上的亏损，比如在演练中用到的收费内容（例如短信等）我们要考虑周全。

（三）阿里的故障演练方案

如下图所示，阿里自己有着一套完整的故障演练方案，一开始也是通过一些工具或者脚本来进行，在2016年之后才开始将通用的故障模式沉淀为系统，之后在2018年将内部沉淀多年的实践正式在阿里云商用，2019年时将沉淀多年的故障注入场景正式开源，成为国内首个混沌工程开源产品。

（四）AHAS故障演练

AHAS故障演练的产品架构如下图所示，其定位是一款简单、安全、低成本的故障演练工具，能够帮助用户快速实施演练并发现问题。

从产品角度来讲，AHAS故障演练产品有两个特色：可视化和安全。通过可视化功能我们可以将演练过程中的系统指标直观展示，可以“边演练，边观察”；另外，AHAS还可以指定保护策略，自动触发并终止演练，避免系统因演练而引发的预期外故障。

AHAS和PTS都可以在阿里云的平台上直接使用，大家感兴趣的话可以到阿里云官网进行更详细的了解。

关键词：高可用技术体系，容灾，容量，全链路压测，线上防护，故障演练，AHAS，PTS