![]()
混沌鸿蒙，先行五太
“天地浑沌如鸡子，盘古生其中。万八千岁，天地开辟。阳清为天，阴浊为地，盘古在其中。一日九变，神于天，圣于地。天日高一丈，地日厚一丈，盘古日长一丈。如此万八千岁，天数极高，地数极深，盘古极长。故天去地九万里，后乃有三皇。”《山海经》中这样形容混沌鸿蒙到天地初开的情形。据一些古籍记载，天地诞生前经历了五个状态，叫做先天五太。而所谓的先天五太，即太易、太初、太始、太素和太极。这些都是中国的道家哲学，对宇宙、世界起源的一种哲学解释。哲学的智慧产生于人类的实践活动，源自于人们对实践的追问和对世界的思考。近些年来，开源数字基础设施迭代不断加快，加速了企业在云上部署其数据中心、业务中心的脚步。多云、混合云架构已经越来越多的成为企业数字办公的首选方案。在这样的背景下，为了让基础设施更好地适合复杂多变的运行环境，提供大规模、超高稳定的运行效率，一种“新”的软件思潮，即“混沌工程学（Chaos Engineering）”被提升到一个很重要的高度。不过略感遗憾，这一理念的出现并非来自中国。2008年，Netflix决定把它的业务迁移到AWS上，而为了解决该阶段暴露的问题，它们端到端的提出一套稳定性测试理念与工具框架，从2012年以来，Netflix陆续开源了猴子军团系列（Chaos Monkey, Latency Monkey, Conformity Monkey, Docker Monkey, Security Monkey, 10-18 Monkey, Chaos Gorilla, Chaos Kong），催生了这一领域的蓬勃发展。随着国家新基建，上云等政策的大力倡导，国内接下来势必将会迎来新一轮爆发期。而这一轮爆发、变革核心在于稳定的底盘，在于不可变的基础设施。基础设施本身是否能够适应复杂的运行环境，以及迭代加速的数字升级战场，这需要混沌工程的指导。在此基础上，我们同样需要某种手段验证上层应用是否可以在这个过程中不受影响并保持一致，混沌工程的引入可以让问题提前暴露、提前解决，从而在工程设计与实现上规避风险，不断提高系统弹性，持续交付高质量产品。Chaos框架应运而生
OpenMessaging是云原生、厂商中立的分布式消息开放规范的集合。Benchmark作为OpenMessaging中一套性能基准测试框架，已经被国内外各大评测机构和开发人员广泛接受。但跑得快不一定意味着跑的稳，跑的远，跑的happy。换言之，可靠性，可用性与可扩展性也是设计分布式系统，尤其是云原生应用需要重点考虑的。如何去设计这些度量点、如何去验证设计是否符合预期，如何能够持续快速的演进架构而不破坏这些不变的设计准则，俨然成为了分布式基础设施新的挑战。通常来说，分布式系统可靠性的验证可以采用形式化规范来进行，比如TLA+，但是这样的验证需要大量的特定理论知识。另一个方式是通过测试来验证，但普通的单元测试和集成测试无法覆盖到一些只有在高并发或者故障发生时才会出现的边缘情况。人们在合理的架构，高质量的代码，完善的测试等方面做了很多努力，然而仍旧无法让自己的系统高可靠、高可用与弹性化，混沌工程为解决这些问题带来新的思路，其基本原则可以概括为：通过蓄意制造”破坏“来确保容错机制不断运行并接受考验，从而验证系统的可靠性、可用性与弹性伸缩，提高故障自然发生时系统能正确处理的信心。当前，业界已经存在一些基于混沌工程的框架，但却存在一些问题，比如ChaosMonkey提供了故障注入的手段，但无法给出针对于特定分布式基础设施的正确性、可靠性、可用性校验结果。Jepsen能在特定故障下验证分布式系统是否满足一致性，但是Jepsen并未针对领域特有顺序性、故障恢复时间等检测。此外，Jepsen测试需要用clojure语言编写，而clojure作为一种小众语言给分布式系统的适配带来了不小困难。在这样的背景下，OpenMessaging Chaos框架应运而生。作为分布式消息领域的先行者，它借鉴了混沌工程的理念，内置了丰富的、扩展良好的检测模型，通过标准化API，暴露衡量分布式消息队列的可靠性、可用性、顺序性与可伸缩性的observable entrypoint，非常利于各个messaging 厂商的接入。另外，作为消息领域的Chaos框架，它操作简单，适配容易，可以被集成到CI/CD框架（如Jenkins）中，持续帮助系统进行演进与迭代，提高云原生消息架构的可靠性。
Chaos框架介绍
Chaos框架总体架构如上图所示，主要由控制节点和若干个集群节点组成。控制节点由Driver（驱动）、Model（模型）、Fault（故障）和Checker（检测器）组件组成。框架启动后，控制节点会以SSH方式远程登陆到集群节点，通过自动化部署或手动部署方式，使集群节点组成一个待测试的分布式集群，并会根据需要测试的分布式基础设施找到对应的Driver组件并载入，根据设置的并发数建立相应个数的客户端。测试开始后，控制节点根据Model组件定义的执行流程控制客户端对集群进行操作，比如对于队列模型来说，客户端会并发地向待测试的分布式消息队列集群调用入队和出队操作。测试过程中，Fault组件会对集群节点进行故障模拟，包括网络分区、网络包延迟、随机杀死进程等。测试结束，Checker组件对历史日志文件的自动化分析得出测试结果和可视化图表。此外，框架提供了开放API，方便厂商对Driver、Model、Fault、Checker等组件进行自行扩展。
伴随着云计算的发展，云计算技术、容灾应急响应机制都日趋成熟和完善。业界对于系统如何达到高可用、高可靠是有一些基本共识的，比如：服务拆分；并发控制，服务隔离；灰度发布；限流降级；链路追踪，全方位监控报警等。即便有这些最佳实践的指导，我们仍不能忽略一些”突如其来“的灾难，容灾体系的建设依旧是严峻且富有挑战的。近几年世界最好的几家云计算公司频发”故障“，如何面对这些突发而来的故障，是每一个基础设施设计者需要深刻思考的。通常来说，容灾系统设计中，往往会主要关注两个指标：RPO关注数据丢失，即系统可靠性，RTO关注服务丢失，即系统可用性。Chaos框架有内置的检测模型，天然支持针对于消息领域的可靠性和可用性检测。除此之外，框架还支持检测消息领域特有的一些核心指标：投递语义。检测消息数据是否丢失或重复， 判断消息系统在故障下是否满足预期At least once、At most once 、Exactly Once投递语义，验证系统的可靠性。
故障恢复时间。检测集群故障时间段是否发生不可用，以及不可用的后故障恢复时间，即检测系统是否达到预期的RTO，验证系统的可用性。
顺序性。检测消息系统的顺序性，比如在故障下消息是否满足预期的分区顺序性。
另外，框架还提供了可视化的时延图，可以帮助开发人员和测试人员进一步了解被测试的消息平台在Chaos框架运行过程中的表现情况，发现可能存在的问题。Chaos框架借鉴了混沌工程的理念，提供了各种类型的故障模拟，通过模拟各种极端环境，检测分布式基础设施在故障下是否仍然符合预期的检测指标，建立分布式基础设施承受生产环境中湍流条件能力的信心。如下图所示，当前支持的故障类型主要包括：- random-partition（fixed-partition）：挑选节点进行网络隔离，模拟常见的对称网络分区。
- random-loss：挑选节点并对这些节点接收和发送的网络包进行按比例丢弃，模拟一些节点网络较差的情况。
- random-kill（fixed-kill、minor-kill、major-kill）：挑选节点并对节点上服务进程进行杀死和重启，故障模拟常见的进程崩溃情况。
- random-suspend（fixed-suspend、minor-suspend、major-suspend）：挑选节点并利用SIGSTOP/SIGCONT信号量对节点上服务进程进行暂停，模拟一些慢节点的情况，比如发生Full GC、OOM等。
- bridge和partition-majorities-ring：模拟比较极端的非对称网络分区。
（注：fixed-xxx故障为用户指定固定的节点进行故障模拟，minor-xxx为随机挑选少数节点进行故障模拟，major-xxx为随机挑选多数节点进行故障模拟）
快速上手
由上述架构可知，框架的运行需要一个控制节点以及由若干个测试节点组成的待测试集群，控制节点必须能SSH到测试节点上。因此通常来说测试需要多台机器，但是框架也提供了docker启动方式，能在一台机器上完成整个测试。下面介绍如何利用Chaos框架（docker模式）测试Apache RocketMQ消息队列。首先利用docker-compose启动控制节点容器和测试节点容器cd openmessaging-chaos/docker./up.sh --dev
然后再开一个shell，进入控制节点容器内部，并调用maven命令完成测试框架的安装docker exec -it chaos-control bashmvn clean install
框架安装完成后，就可以进行RocketMQ故障下的可靠性和可用性验证。编辑`driver-rocketmq/rocketmq.yaml`，利用5个节点组成一个RocketMQ DLedger的broker组作为待测试的集群。以minor-kill故障模拟为例进行Chaos测试，minor-kill故障模拟会随机挑选集群中少数节点进程杀死，由于杀死少数节点，即使集群故障后不可用也能在一段时间内恢复，方便测试集群的故障恢复时间。测试过程中我们设置4个客户端并发向待RocketMQ DLedger集群发送和接收消息，故障模拟时间间隔为60s，即60s正常运行，60s故障模拟，一直循环，整个阶段一共持续1200s。如果是第一次测试，需要在测试节点上安装RocketMQ，因此还需添加--install参数（安装完成后续测试可以不添加该参数）。最后我们开启rto参数和order-test参数，测试集群故障恢复时间和消息的分区顺序性。bin/chaos.sh --drivers driver-rocketmq/rocketmq.yaml --fault minor-kill --fault-interval 60 --limit-time 1200 --rate 1000 --install --rto --order-test
测试结束后，框架会给出测试结果和时延图。下图展示了整个测试过程中入队操作的时延情况。下图是测试结束后Chaos框架给出的统计结果，可以看到一共成功发送了50W个数据，虽然故障导致8个消息重复（duplicateMessageCount=8），但没有消息丢失（lostMessageCount=0），这表明，RocketMQ DLedger模式即使在故障下仍旧满足At Least Once的投递语义（atLeastOnce=true），RPO为0符合预期。RTOTestResult结果表明10次故障时间段一共发生了5次集群不可用的情况（与上述时延图一致），但每次集群都能在30秒以内恢复，平均故障恢复时间在29秒左右（available failure recovery time = 29211ms，主要取决于客户端更新路由的时间）。此外，OrderTestResult结果表明，消息平台在故障发生后仍然保持了分区顺序性（partition order = true）。利用Chaos框架，我们检测了基于 DLedger构建的Apache RocketMQ高可用顺序消息集群在少数节点崩溃故障下的表现情况，除了minor-kill故障之外，我们还可以注入其他类型的故障，进一步验证RocketMQ集群在故障下的可靠性、可用性和顺序性，发现潜在的问题。
后续展望
Chaos框架提供了扩展点方便Messaging厂商适配框架。Driver组件中的提供了2个适配接口：客户端接口MQChaosClient和集群节点接口MQChaosNode。MQChaosClient定义消息客户端需要实现的两个方法enqueue和dequeue，由于每一个消息平台都会包含入队和出队两个方法的实现，因此适配难度很低。MQChaosNode定义集群节点的生命周期，包括setup、teardown、start、stop等方法来完成集群节点的远程安装、卸载、启动和停止等，框架提供了实现这些方法的基础API，可以方便地实现这些操作。除此之外，厂商还可以利用Chaos框架提供的基础API去自行扩展Model、Fault、Checker等组件，根据每个分布式基础设施的不同制定特定场景进行测试。
目前，Chaos 框架已经发布了首个版本，按照规划，接下来陆续发布2个大版本，包括实现其它消息队列的适配等重要特性。为了更好的帮助开源、云厂商接入这套规范，OpenMessaging 技术委员会TSC成立了相关的workgroup，欢迎大家参与进来（留言加入），加速推进这个领域的不断成熟。另外，我们也在积极地和CNCF Chaos WorkGroup进行交流，期望继续推进整个领域的标准化与生态化。[1] 项目地址：https://github.com/openmessaging/openmessaging-chaos[2] Chaos Eng WG Proposal in CNCF : https://docs.google.com/document/d/1BeeJZIyReCFNLJQrZjwA4KMlUJelxFFEv3IwED16lHE/edit?ts=5ace0eab#heading=h.ephtflhfpd1d[3] PRINCIPLES OF CHAOS ENGINEERING: http://principlesofchaos.org/?lang=ENcontent