混沌鸿蒙，新基建下的分布式消息 Chaos 框架

OpenMessaging是云原生、厂商中立的分布式消息开放规范的集合。Benchmark作为OpenMessaging中一套性能基准测试框架，已经被国内外各大评测机构和开发人员广泛接受。但跑得快不一定意味着跑的稳，跑的远，跑的happy。换言之，可靠性，可用性与可扩展性也是设计分布式系统，尤其是云原生应用需要重点考虑的。如何去设计这些度量点、如何去验证设计是否符合预期，如何能够持续快速的演进架构而不破坏这些不变的设计准则，俨然成为了分布式基础设施新的挑战。

通常来说，分布式系统可靠性的验证可以采用形式化规范来进行，比如TLA+，但是这样的验证需要大量的特定理论知识。另一个方式是通过测试来验证，但普通的单元测试和集成测试无法覆盖到一些只有在高并发或者故障发生时才会出现的边缘情况。人们在合理的架构，高质量的代码，完善的测试等方面做了很多努力，然而仍旧无法让自己的系统高可靠、高可用与弹性化，混沌工程为解决这些问题带来新的思路，其基本原则可以概括为：

• 建立一个围绕稳定状态行为的假说

• 多样化真实世界的事件

• 在生产环境中运行实验

• 持续自动化运行实验

• 最小化爆炸半径

通过蓄意制造”破坏“来确保容错机制不断运行并接受考验，从而验证系统的可靠性、可用性与弹性伸缩，提高故障自然发生时系统能正确处理的信心。

当前，业界已经存在一些基于混沌工程的框架，但却存在一些问题，比如ChaosMonkey提供了故障注入的手段，但无法给出针对于特定分布式基础设施的正确性、可靠性、可用性校验结果。Jepsen能在特定故障下验证分布式系统是否满足一致性，但是Jepsen并未针对领域特有顺序性、故障恢复时间等检测。此外，Jepsen测试需要用clojure语言编写，而clojure作为一种小众语言给分布式系统的适配带来了不小困难。

在这样的背景下，OpenMessaging Chaos框架应运而生。作为分布式消息领域的先行者，它借鉴了混沌工程的理念，内置了丰富的、扩展良好的检测模型，通过标准化API，暴露衡量分布式消息队列的可靠性、可用性、顺序性与可伸缩性的observable entrypoint，非常利于各个messaging 厂商的接入。另外，作为消息领域的Chaos框架，它操作简单，适配容易，可以被集成到CI/CD框架（如Jenkins）中，持续帮助系统进行演进与迭代，提高云原生消息架构的可靠性。

03

—

Chaos框架介绍

  核心 指标

伴随着云计算的发展，云计算技术、容灾应急响应机制都日趋成熟和完善。业界对于系统如何达到高可用、高可靠是有一些基本共识的，比如：服务拆分；并发控制，服务隔离；灰度发布；限流降级；链路追踪，全方位监控报警等。即便有这些最佳实践的指导，我们仍不能忽略一些”突如其来“的灾难，容灾体系的建设依旧是严峻且富有挑战的。近几年世界最好的几家云计算公司频发”故障“，如何面对这些突发而来的故障，是每一个基础设施设计者需要深刻思考的。通常来说，容灾系统设计中，往往会主要关注两个指标：

• RPO（Recovery Point Objective）：即数据恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求。RPO标志系统能够容忍的最大数据丢失量。

• RTO（Recovery Time Objective）：即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。

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为随机挑选多数节点进行故障模拟）

04

—

快速上手

由上述架构可知，框架的运行需要一个控制节点以及由若干个测试节点组成的待测试集群，控制节点必须能SSH到测试节点上。因此通常来说测试需要多台机器，但是框架也提供了 docker 启动方式，能在一台机器上完成整个测试。下面介绍如何利用Chaos框架（docker模式）测试Apache RocketMQ消息队列。

首先利用doc ker-compose启动控制节点容器和测试节点容器

cd openmessaging-chaos/docker./up.sh --dev

然后再开一个shell，进入控制节点容器内部，并调用maven命令完成测试框架的安装

<span><span>docker</span> <span>exec -it chaos-control bash</span></span>

<span><span>mvn</span> <span>clean install</span></span>

框架安装完成后，就可以进行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），但没有消息丢失（lostMess ageCount=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 框架已经发布了首个版本，按照规划，接下来陆续发布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