性能保障的那些事

初识大促保障，常会有这样的疑问：保障保的到底是什么，确保没有问题或者不出问题吗？这似乎是个伪命题。而作为保障这件事本身，不仅要坚信所为有意义，更要有所为，这就需要把不可能的伪命题转化为可以不断深入的可行任务。谈及保障的根本，其实我们要面对的是对抗不确定性，这个不确定性来自四面八方。比如大地震，会导致整个机房中断，如何应对？比如负责核心系统的工程师离职了，如何应对？再比如下游接口挂了，如何应对？系统磁盘坏了，数据面临丢失风险，如何应对？我想关于上述问题的应对方式，大家在工作中或多或少都有所了解，而这个不确定性的处理过程，就是容灾，其不同的‘灾难’，对应不同的容灾级别。

为了对抗这些不同级别的不确定性，就要付出不同级别的成本，因此可用性也应是有标准的。这标准就是大家常说的N个9。随着N的增加，成本也相应增加，那如何在达到业务需要的可用性的基础上，尽量节省成本？这也是一个值得思考的话题。除此之外，100%减去这N个9就说所谓的平均故障时间（MTBF），很多人只关心那些9，而忽略了故障处理时间，这是不该的：你的故障处理速度越快，系统的可用性才有可能越高。

上面扯了一些可用性概念上的东西，下面尝试使用‘事情’来分个类。这里的‘事’就是故障，分为：事前（故障发生以前）、事发（故障发生到系统或人感知到故障）、事中（故障发生到故障处理这段时间）、事后（故障结束之后）。

按照上述分类，不同的阶段应有着不同的技巧：

1. 事前：副本、隔离、配额、预案、探知

2. 事发：监控、报警

3. 事中：降级、回滚、应急预案

4. 事后：复盘、思考、技改

部分技术概念解释如下：

副本：无状态服务集群便是副本的一个应用，因为没有状态，便可水平伸缩，而这些无状态服务器之间需要一层代理来统一调度管理，这便有了反向代理。当代理通过心跳检测机制检测到有一台机器出现问题时，就将其下线，其他‘副本’机器继续提供服务；存储领域也是经常使用副本技术的，比如mysql主备切换，rabbitMQ的镜像队列，磁盘的RAID技术，各种nosql中的分区副本，等等数不胜数，几乎所有保证高可用的系统都有冗余副本存在。

隔离：线程隔离、进程隔离、集群隔离、机房隔离、读写隔离、动静隔离、爬虫隔离、热点隔离、硬件资源隔离。这些隔离其实就是一种，即资源隔离，无论线程、进程、硬件、机房、集群都是一种资源；动态资源和静态资源也不过是资源的一种分类；热点隔离也即是热点资源和非热点资源的隔离；读写隔离不过仅仅是资源的使用方式而已，相同的两份资源，一份用来写，一份用来读。因此，隔离的本质，其实就是对资源的独立保护。因为每个资源都得到了独立的保护，其中一个资源出了问题，不会影响到其他资源，这就提高了整体服务的可用性。

配额：配额技术通过限制资源供给来保护系统，从而提高整体可用性。限流是配额技术的一种，它通过调节入口流量水位上线，来避免供给不足所导致的服务宕机。限流分为集群限流和单机限流，集群限流需要分布式基础设施配合，单机限流则不需要。除此之外，限流这里我们还需要考虑几点：

1. 如何设置合理的限流值？限流值的设定是需要经过全链路压测、妥善评估CPU容量、磁盘、内存、IO等指标与流量之间的变化关系（不一定线性关系）、结合业务预估和运维经验后，才能确定。

2. 对于被限流的流量如何处理？有几种处理方式，其一直接丢弃，用温和的文案提醒用户；其二，静默，俗称的无损降级，用缓存内容刷新页面；其三，蓄洪，异步回血，这一般用于事务型场景。

3.  会不会导致误杀？单机限流会导致误杀，尤其当负载不均衡的情况下，很容易出现误杀；单机限流值设定过小也容易出现误杀的情况。 

预案：一般分为提前预案（事前）和应急预案（事中）。提前预案提前执行，比如将系统临时从高峰模式切换成节能模式；应急预案关键时刻才执行，主要用于止血，比如一键容灾切换等。预案技术一般要配合开关使用，推预案一般也就是推开关了。除此之外，预案也可和限流、回滚、降级等相结合，预案的制定也可通过对历史故障的分析寻找思路。

探知：探知当前系统的可用性能力，其实无法提高系统可用性，做不好甚至还会降低系统可用性。压测和演练是最常见的探知技术 。压测分为全链路压测和单链路压测，全链路压测用于像双十一大促活动等，需要各上下游系统整体配合，单链路压测一般验证功能或做简单的场景压测提取性能指标。全链路压测的一般过程是：压测目标设定和评估，压测构造，压测脚本编写部署，压测数据准备，小流量链路验证，通知上下游系统owner，压测预热，压测，压测结果评估报告，性能优化。以上过程反复迭代，直到达到压测目标为止；演练一般按规模划分：比如城市级别的容灾演练，机房级别的容灾演练，集群规模的容灾演练（DB集群，缓存集群，应用集群等），单机级别的故障注入，预案演练等。

监控和报警：一般出现故障的时候，老板大多会有三问：为什么才发现？为什么才解决？影响有多大？即使故障影响面较大，如果能迅速止血，在做复盘的时候多少能挽回一些面子，相反如果处理不及时，即使小小的故障，都可能让你丢了饭碗。越早识别故障，就能越早解决问题，而这眼睛便是监控和报警了。

降级：降级的内涵丰富，我们只从链路角度去思考。降级的本质是弃车保帅，通过临时舍弃部分功能，保证系统整体可用性。降级虽然从整体上看系统仍然可用，但由于取舍的关系，那么可知所有的降级一定是有损的。不可能有真正的无损降级，而常说的无损降级指的是用户体验无损。降级一定发生在层与层之间（上下游），要么a层临时性不调用b层，这叫做熔断，要么a层临时调用c层（c层合理性一定<b层），这叫备用链路。无论是哪一种方式，都会面临一个问题：如何确定什么时候降级，什么时候恢复？一般有两种方式，其一是人工确认，通过监控报警等反馈机制，人工识别故障，推送降级，待故障恢复后在手动回滚；其二是自适应识别，最常用的指标有超时时间、错误次数、限值流等等，当达到阈值时自动执行降级，恢复时自动回滚。这两种方式无需对比，它们都是经常采用的高可用技巧。除此之外，我们还要注意降级和强弱依赖的关系。强弱依赖表示的是链路上下游之间的依赖关系，是’是否可降级‘的一种专业表述。一些降级的例子：

• 读写降级，实际上是存储层和应用层之间的降级，采用备用链路切换方式，损失了一致性；

• 功能降级，将部分功能关闭，实际上是应用层和功能模块层之间的降级，采用熔断方式，损失了部分功能。

• 爬虫降级，实际上是搜索引擎爬虫和应用系统之间的降级，采用备用链路切换方式，将爬虫引导到静态页面，损失是引擎索引的建立和页面收录。

回滚：当执行某种变更出现故障时，最为稳妥和有效的办法就是回滚。虽然回滚行之有效，但并不简单，因为回滚有一个大前提：变更必须具有可回滚性。而让某一种变更具有可回滚的特性，是要耗费很大力气的。索性的是，大部分基础服务已经帮我们封装好了这一特性，比如DB的事务回滚（DB事务机制），代码库回滚（GIT的文件版本控制），发布回滚（发布系统支持）等等。我们在日常变更操作的时候，必须要确定你的操作是否可回滚，并尽力保证所有变更均可回滚。如果不能回滚，是否可以进行热更新（比如发布应用到app store）或最终一致性补偿等额外手段保证系统高可用。