混沌工程：分布式系统稳定性的“疫苗”

作者：李康建 中原银行信息技术部

一、容灾了，但没完全容灾

2021年7月14日夜晚，B站突发宕机事故，导致服务不可用长达40分钟，B站“难民”们纷纷涌入其他竞品平台，导致了连锁性的服务雪崩事件。事故原因众说纷纭，据传可能有机房失火，停电，云设施故障，程序猿手滑等等。

且不论有多少可怜的程序猿会因为此次事故而面临祭天的命运，拨开围绕在此事件上的热点讨论，它的本质无非就是未能对生产环境突发故障做出合理的预警和未雨绸缪的预防，或者说没有对各种可能影响服务高可用性的因素做出充分考虑和应对；以至于千里之堤，溃于蚁穴。

比较戏剧性的是，那篇《B站高可用架构实践》还在各大技术博客上优哉游哉地挂着，里面充斥着我们耳熟能详的名词：负载均衡、分布式限流、超时控制、优雅降级、故障演练等等，听上去给服务可用性叠上了一层层可靠的护甲，如同马奇诺防线一样坚不可摧，如同泰坦尼克号一样永不沉没，如同苏维埃联盟一样牢不可破。然而实践是检验真理的唯一标准，残酷的现实告诉我们，这些名词并不一定像它们看上去那样可靠。有人在文章评论区留下了这样的调侃：容灾了，但没完全容灾。

随着微服务化、云原生、敏捷开发的快速普及，我们在快速迭代相应业务需求即时变化的同时，也面临着分布式架构复杂程度急剧上升，故障频发，强弱依赖关系难以厘清，系统变化过快稳定性难以保证等问题，这使得架构的容错性和高可用性都受到了前所未有的挑战。为此我们引入了混沌工程的概念，它是提升分布式系统架构稳定性的“疫苗”。

“一只南美洲亚马逊河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可以在两周以后引起美国得克萨斯州的一场龙卷风”。这就是我们耳熟能详的蝴蝶效应。无独有偶，英国有这样一段著名的民谣描述国王查理三世的悲剧命运：“少了一枚铁钉，掉了一只马掌。掉了一只马掌，失去一匹战马。失去一匹战马，失去一场战役。败了一场战役，毁了一个王朝。”它们背后的原理是一致的，即初始条件的微小差异经过复杂系统的层层放大后，引起了影响深远的连锁反应。我们用混沌一词来描述这种状态，混沌是一个非线性科学概念，指确定性动力学系统因对初值敏感而表现出的不可预测的、类似随机性的运动。

应用的分布式架构体系同样可以视为一个混沌体系，浩如繁星的微服务数目，错综复杂的调用链路，海量的交易数据，这一切使得生产环境遍布着难以预测的湍流，即使是一个看似不起眼的波动，都有可能造成整个系统的雪崩。混沌工程正是为了探究与应对生产环境的混沌状态而诞生的实验学科。

二、NetFlix、猴子与疫苗

2008年8月， Netflix主要数据库的故障导致了三天的停机，之后Netflix工程师着手寻找替代架构，并在2011年起，逐步将系统迁移到AWS上，运行基于微服务的新型分布式架构。这种架构消除了单点故障，但也引入了新的复杂性类型，需要更加可靠和容错的系统。为此，Netflix 工程师创建了 Chaos Monkey࿰