共计 4051 个字符，预计需要花费 11 分钟才能阅读完成。
随同着互联网业务的高速倒退，越来越多的线下场景须要转移到线上，而线上业务的量级也在飞速增长，给互联网业务的技术架构带来了严厉的挑战，原来的“一体机 + 数据库”的形式曾经不适用于以后的支流业务，越来越来的业务开始向分布式架构和云原生架构演进。同时，原来繁多的技术环境开始走向分布式、分层的多组件技术架构，越来越多的组件使得保障业务稳固运行的工作也越来越艰巨。
一、容灾
航空零碎的容灾体系做得十分优良。航空零碎的容灾体系从人、飞机和环境三个维度来思考，能力构建一套优良的容灾计划。
从人的维度，以防万分之一的紧急情况呈现的可能，每年要进行屡次的模拟机训练或者实景演练。一架飞机上都会装备至多两名飞行员，二者相互合作的同时也要互相监督。
从飞机的维度，每一个航段前，光是一个绕机查看可能就有几十个我的项目须要查看。机查看是由高空机务人员和航行机组别离实现，同样也是为了更认真的查看，升高错误率。每架飞机还有短期全面检查和长期全面查看，飞机上的每一个设施都是独立的双系统在工作。
从环境的维度，气象雷达能够让飞行员感知到几十甚至几百海里范畴内的天气情况。飞机防撞零碎能够让航行导航显示仪上显示正在靠近的可能存在威逼的飞机。盲降零碎是由高空发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接管设施，进行起飞。
从航空业的容灾体系构建中咱们能够发现，容灾的核心思想是基于隔离的冗余。在零碎设计中，其实也常常用到冗余的机制，比方机器常常是多台、数据是多备份等。容灾的评估指标次要有两个：
一是 RPO（Recovery Point Objective），即数据恢复点指标，以工夫为单位，即在劫难产生时，零碎和数据必须复原的工夫点要求。
二是 RTO（Recovery Time Objective），即复原工夫指标，以工夫为单位，即在劫难产生后，信息系统或业务性能从进行到必须复原的工夫要求。RTO 标记着零碎可能容忍的服务进行的最长工夫，零碎服务的紧迫性要求越高，RTO 的值越小。
1. 业界支流容灾计划
如下图所示，业内支流的容灾计划最早是异地冷备的形式，起初演进到同城双活形式，最初倒退成为“两地三核心”。
业界支流容灾计划
2. 阿里 AHAS
阿里 AHAS 容灾计划应用的是比“两地三核心”更前沿的“异地多活”计划，在所有的数据中心都能提供服务的同时，RPO 和 RTO 能做到分钟级甚至秒级。下图是阿里 AHAS 的产品状态。AHAS 在 2013 年之后就开始大规模在阿里外部应用，并且作为高可用平台的一个外围模块，开始服务内部客户。AHAS 通过异地多活，可能真正做到对于宏观架构的容灾，并抵挡大规模的失败场景。比方一个城市的机房出了故障，能够很轻易地把流量实时切换到另外一个机房。
AHAS 异地多活的产品状态
二、容量
在互联网业务下，流量的不确定性非常明显，常常会呈现流量顶峰事件，比方微博的热点、阿里的双 11、12306 的火车票放购等事件。在这种场景下，如何做好容量布局就变得至关重要。
1. 压测
传统的压力测试通常关注的是性能的好坏，这是一个绝对含糊的概念，不须要很精准。然而在互联网的状况下，咱们须要精准地获取到一个零碎的实时吞吐量，以便更好地应答突发事件。在这种状况下，压测要尽可能地模仿一个实在的环境，而不能像以往一样，在一个额定的环境去测试。压测时在流量规模、流量模型、零碎环境上都须要一个尽可能实在的环境，这样能力精准做好容量布局。
传统的压测工具尽管仍在发挥作用，然而随着互联网的倒退，曾经越来越不能去适应互联网技术的迭代。互联网的压测有几个显著的特点：
强调流量的真实性；
压测规模要足够大；
必须简略易用，交互式压测。
当下互联网压测曾经变成了一个实时的产品，不便进行实时的调控。基于这样的背景，阿里构建了基于 PTS 的流量引擎，大家能够在阿里云上间接应用，其特点如下：
流量实在。流量来源于全国上百城市，笼罩各运营商（可拓展至海内），实在模仿最终用户的流量起源，相应的报表、数据更靠近用户实在体感；发现端到端更多更全面的问题，压测即是模拟考。
压测规模弱小，可反对 3kW QPS。
简略易用，门槛低。简单场景的全可视化编排，反对自定义编排能力、指令、管制、函数等相干能力，笼罩 95% 以上的 HTTP 压测场景，和 JMeter 构建能力不相伯仲，同时免去简单的了解学习老本；除了本身丰盛的客户侧监控数据，还可集成云监控和 ARMS 监控。压测过程提供日志明细查问，配套有申请瀑布模型，压测之后的报告和问题定位更不便。联合 AHAS 可额定提供流量吞吐控制能力、容量水位治理、熔断降级爱护性能。除了弱小的自研性能，对于开源 JMeter 的反对也很敌对，反对 JMeter 脚本转化为 PTS 压测，同样反对原生 JMeter 引擎进行压测。
2. 全链路压测
在实践中发现，单零碎单利用的压测与实在场景之间的误差十分大，因为在压测的时候无奈验证整个零碎的方方面面，而且很多问题只有在真正的大流量场景下才会裸露，所以要进行全链路压测，其外围是心愿将来的事件可能提前到在以后工夫内产生，可能用最实在的场景来端对端的验证零碎的能力和稳定性。
为了实现更好地进行全链路压测，阿里云提出了基于 PTS 的全链路压测解决方案，其架构如下图所示。
基于 PTS 的全链路压测
从压测环境、压测根底数据、压测流量（模型、数据）、流量发动和问题定位对基于 PTS 的全链路压测解决方案总结如下：
压测环境：对应实在的线上环境，压测后果和问题裸露都是最实在的状况，可通过压测流量全局辨认、透传（影子表），或者等比隔离环境，或复用生产库（压测应用测试数据），业务挡板。
压测根底数据：结构满足大促场景的外围根底相干数据（如买家、卖家、商品信息），以线上数据为数据源，进行采样、过滤和脱敏，放弃和线上一个量级。
压测流量（模型、数据）：链路范畴、拜访量级、参数汇合、根底数据的个性一起结构压测的业务模型，和实在业务状况保持一致。
流量发动：模仿全国各地实在的用户申请拜访，探测站点能力。
问题定位：发动侧多维度的监控和报表，服务端可通过其余生态产品帮助定位。
三、线上防护
线上防护对于零碎高可用来说是一个十分重要的环节。随着分布式技术的利用，节点越来越多，技术越来越简单，出错的机会也绝对增大。同时，在互联网的条件下，业务的公布也越来越频繁。在互联网的环境下，零碎随时面临一些不确定事件、流量冲击等，不能奢望每次呈现故障的时候都有人工来干涉，而是须要零碎本身有肯定的防护能力，可能让本身在任何环境下都能有最佳的工作状态。
1. AHAS 流量防护
阿里云将流量防护广泛应用于各种场景，比方双 11 峰值流量、秒杀流动、物流、订单解决、商品查问、付款等。同时，阿里云也胜利地将流量防护能力交融到了云产品 AHAS（Application High Availability Service，利用高可用服务）中。AHAS 涵盖了阿里巴巴多年来在利用高可用服务畛域的技术积淀，包含架构感知、流量防护、故障演练和性能开关四大独立的功能模块。如下图所示，AHAS 构建了一个从入口到最初端的一个残缺的防护体系。
AHAS 经典流量防护布局
2. AHAS 针对大流量场景的保护措施
流量防护首先须要思考的是对大流量场景的爱护，比方 url、服务提供方、重点业务等，忽然呈现超乎预期的大流量，基于 AHAS 能够做如下防护措施：
（1）如果有性能压测，能够精准设置 QPS 阈值。有了 QPS 阈值，能够用来限流，避免出现超负载的流量。
（2）如果没有性能压测，也能够通过秒级监控，实时设置阈值。
（3）反对高阶性能：流控模式反对间接、关联、链路，流控形式反对疾速失败、Warm UP、排队期待。
3. AHAS 针对不同场景的措施——异样隔离
在特定未知的场景下，可能呈现不稳固的因素，如慢 SQL，甚至死锁，导致整个利用越来越慢，甚至整个利用没有响应，这时候要对异样流量进行隔离，免得影响到失常的流量。
4. AHAS 针对不同场景的措施——零碎防护
在某些场景下，比方零碎的负载 CPU 飙升，零碎没有反馈，无奈确认具体哪个接口导致问题的呈现，这时 AHAS 提供了一个终极大招：零碎爱护。零碎爱护就是当零碎负载比拟高的时候，会主动依据入口流量和零碎的负载获得一个动静的均衡，保证系统不会好转的同时，也能解决最大的入口申请。在这种状况下，系统对各种流量都是平等的，无奈设置流量的优先级。
四、演练
很多故障是一个小概率事件，然而一旦产生，所造成的损失是不可估量的，比方巴黎圣母院的火灾。互联网业务也是一样，小概率的故障也可能带来不可挽回的经济损失，甚至是法律危险。因而，故障演练是一个齐备的容灾体系所必须进行的一步。
1. 企业为什么须要做故障演练？
如果一个业务零碎的流量很小且趋于稳定，就没有必要进行故障演练。然而如果一个企业处于高速倒退中，业务倒退快，有大量的稳定性技术债，其业务零碎一直的变动，甚至明天的状态跟昨天的状态都不统一，架构也日益简单，那么故障演练就是十分必要且必须的。因为每个环节的不确定因子都是累积的，如果不进行故障演练，最初一旦产生故障，极大可能会对系统造成严重破坏。故障演练还能够造就企业人员的故障解决教训，加强人员的应急能力。
2. 企业引入故障演练遇到的常见问题
在企业进行故障演练的时候，常常会遇到一些问题，比方如何设计组织架构，如何抉择技术计划，如何落地演练实际等。如果业务牵涉到资金，就要做一个清晰化的深层评估，不要因为演练导致呈现资金上的亏损，比方在演练中用到的免费内容（例如短信等）要思考周全。
3. 阿里的故障演练计划
如下图所示，阿里有一套残缺的故障演练计划。一开始是通过一些工具或者脚本，在 2016 年之后才开始将通用的故障模式积淀为零碎。2018 年阿里将外部积淀多年的实际正式在阿里云商用，2019 年将积淀多年的故障注入场景正式开源，成为国内首个混沌工程开源产品。
阿里故障演练历程
4. AHAS 故障演练
AHAS 故障演练的产品架构如下图所示，其定位是一款简略、平安、低成本的故障演练工具，可能帮忙用户疾速施行演练并发现问题。
