阿里为啥值4万亿？看它如何应对亿级高并发大流量？如何保障高可用和稳定性，就知道了！...

作者：丁浪，目前在创业公司担任高级技术架构师。曾就职于阿里巴巴大文娱和蚂蚁金服。具有丰富的稳定性保障，全链路性能优化的经验。架构师社区特邀嘉宾！

阅读本文，你将会收获： 

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

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

前言

我从业之初便开始扮演“救火队员”角色，经常去线上执行“救火”、止损、攻关等应急工作，再通过分析、推理、验证…“抽丝剥茧”的找出背后的根本原因，仿佛自己是个“经验丰富、从容冷静、思维缜密”的侦探。

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

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

稳定性治理的常见场景

突发大流量

 

相信大家对上图并不陌生，尤其在刚刚过去的双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架构（三地五中心的异地多活架构）的演进。

异地多活架构

1. 突破单机房容量限制

2. 防机房单点，高可用