阿里是如何抗住双11的？看完这篇你就明白了!

我从业之初便开始扮演“救火队员”角色，经常去线上执行“救火”、止损、攻关等应急工作，再通过分析、推理、验证…

“抽丝剥茧”的找出背后的根本原因，仿佛自己是个“经验丰富、从容冷静、思维缜密”的侦探。

以前我一直认为线上问题定位、分析处理能力是架构师的“看家功底”并常引以为傲。

但最近这两年我开始思考，其实“防火”比“救火”更重要，正如一句古话“上医治未病，中医治欲病，下医治已病”。下面我将为大家分享稳定性治理经验和阿里的稳定性保障体系。

阅读本文，你将会收获：

高并发、大流量场景的常见问题和应对手段

知名互联网公司的高可用架构和稳定性保障体系

稳定性治理的常见场景

突发大流量

相信大家对上图并不陌生，尤其在刚刚过去的双 11、双 12 中。这是电商大促场景中执行了最常用的自动预案 - “限流保护”，并非很多朋友说的“宕机”、“崩溃”。

“限流”是应对高并发或者突发大流量场景下的“三板斧”之一，不管是在电商大促、社交媒体突发热点事件(例如：遇到“知名女星出轨”)，还是在常态下都是非常有必要的保护手段。

本质上就是检查到当前请求量即将超出自身处理能力时，自动执行拒绝(或者执行“请求排队”)，从而防止系统被彻底压垮。

不稳定服务

讲到“限流”，那就不得不提另外一板斧“降级”。除了我们之前所提到的 “开关降级”(关闭次要功能或服务)、兜底、降低一致性等之外，在技术层面最常用就是“自动熔断降级”。

“限流”是为了防止大流量压垮系统，而“熔断”是为了防止不稳定的服务引发超时或等待，从而级联传递并最终导致整个系统雪崩。

如图所示，假设服务 D 此时发生了故障或者 FullGC 等，则会导致上游的服务 G、F 中产生大量等待和异常，并级联传递给最上游的服务 A、B。

即便在服务 G、F 中设置了“超时”(如果没有设置“超时”那情况就更糟糕了)，那么也会导致线程池中的大量线程资源被占用。

如果服务 H、I 和服务 G、F 在同一个应用中且默认共用同一个线程池，那么也会因为资源耗尽变得不可用，并最终导致最上游的服务 A 和服务 B 整体不可用，全部链路都将异常，线上核心系统发生这种事故那就是灾难。

假如我们在检查到服务 G 和服务 F 中 RT 明显变长或者异常比例增加时，能够让其自动关闭并快速失败，这样 H 和 I 将不会受影响，最上游的服务 A 和服务 B 还能保证“部分可用”。

举个现实生活中更通俗的例子，当你们家的电器发生短路时空气开关会自动跳闸(保险丝会自动 “熔断”)。

这就是通过牺牲你们家的用电而换回小区的正常供电，否则整个线路都会烧毁，后果会不堪设想。

所以，你得结合实际业务场景先找出哪些接口、服务是可以被“降级”的。

架构单点

这个事件大概发生在 2015 年，被载入了支付宝的“史册”，也推动了蚂蚁金服整体 LDC 架构(三地五中心的异地多活架构)的演进。

异地多活架构：

突破单机房容量限制

防机房单点，高可用

内建质量

根据以往的经验，60% 以上的故障都是由变更引起的，请牢记变更“三板斧”：

可回滚/可应急

可灰度

可监控

预防质量事故的常用手段：

做好分析、设计、评审，容量评估，规避风险

制定规范，控制流程，加入代码扫描和检查等

阉割做好 Code Review

测试用例覆盖(通过率、行覆盖率、分支覆盖率)，变更全量回归

尽可能的自动化，避免人肉(易出错)，关键时刻执行 Double Check

高可用架构的基石：稳定性保障体系

从故障视角来看稳定性保障，如下图：

（编辑：ASP站长网）