分布式服务架构下的混沌工程实践

本文来自阿里巴巴高可用架构团队高级开发工程师肖长军（花名穹谷）在 GIAC（全球互联网架构大会）上的分享，包含三部分内容：（阿里巴巴中间件公众号对话框发送“混沌工程”，获取分享PPT）

混沌工程的定义、价值、原则和流程；
混沌工程如何在企业中落地，以及 ChaosBlade 和混沌实验平台 AHAS Chaos 架构设计；
结合两个具体案例介绍了分布式服务下的混沌工程实践；

大家好，我是来自阿里的肖长军，今天给大家分享混沌工程在分布式服务架构下的具体实践。

先做个自我介绍，我来自于阿里高可用架构团队，花名穹谷，做过分布式系统设计和 APM 研发相关工作，现在专注于高可用架构和混沌工程领域，是阿里云产品 AHAS 底层技术负责人和开源项目 ChaosBlade 负责人，并且承担集团内故障演练、突袭演练、攻防演练相关的研发工作。今天分享的内容包含以下三个方面。

先从混沌工程的定义、价值、原则和实施步骤介绍混沌工程，然后分享混沌工程如何在企业中落地，最后介绍分布式服务下混沌工程实践案例。我们先来看一下什么是混沌工程。

混沌工程理论一文中提到，其是在分布式系统上进行实验的学科，核心目的是提高生产环境中系统的容错性和可恢复性。尼采的这句话: "打不倒我的必使我强大"，也很好的诠释了混沌工程反脆弱的思想。除了这里提到的目的，实施混沌工程还有哪些价值呢？

这里我从四个角色来说明，对于架构师来说，可以验证系统架构的容错能力，比如验证现在提倡的面向失败设计的系统；对于开发和运维，可以提高故障的应急效率，实现故障告警、定位、恢复的有效和高效性。对于测试来说，可以弥补传统测试方法留下的空白，之前的测试方法基本上是从用户的角度去做，而混沌工程是从系统的角度进行测试，降低故障复发率。对于产品和设计，通过混沌事件查看产品的表现，提升客户使用体验。所以说混沌工程面向的不仅仅是开发、测试，拥有最好的客户体验是每个人的目标。我们知道，系统发生故障的那一刻不是由你来选择的，而是那一刻选择你，你所能做，只能是为之做好准备。了解了混沌工程的价值，我们再来看一下实施混沌工程的一些原则。

前面 Vilas 老师也提到了，我这里重点来介绍一下这五项原则。第一条：”建立一个围绕稳定状态行为的假说“，其包含两个含义，一个是定义能直接反应业务服务的监控指标，需要注意的是这里的监控指标并不是系统资源指标，比如CPU、内存等，这里的监控指标是能直接衡量系统服务质量的业务监控。举个例子，一个调用延迟故障，请求的 RT 会变长，对上层交易量造成下跌的影响，那么这里交易量就可以作为一个监控指标。这条原则的另一个含义是故障触发时，对系统行为作出假设以及监控指标的预期变化。第二个指模拟生产环境中真实的或有理论依据的故障，第三个建议在生产环境中运行实验，但也不是说必须在生产环境中执行，只是实验环境越真实，混沌工程越有价值。持续的执行才能持续的降低故障复发率和提前发现故障，所以需要持续的自动化运行试验，最后一个，混沌工程很重要的一点是控制爆炸半径，也就是试验影响面，防止预期外的资损发生，后面会介绍控制爆炸半径的方式。依据这些指导原则可以更有效实施混沌工程，那么混沌工程的实施步骤是什么？

主要细分为这 8 步，指定试验计划，定义稳态指标，做出系统容错假设，执行实验，检查稳态指标，记录、恢复实验，修复发现的问题，然后做持续验证。以上是对混沌工程理论相关的介绍，那么如何在企业中落地混沌工程呢?

我这里分为三个阶段，首先要坚定价值，因为你会受到来自多方面的挑战，其次引入混沌工程技术，最后在企业中推广混沌工程文化。在实施混沌工程之前，必须能说清楚混沌工程的价值，而且当受到挑战时，意志要坚定。

比如来自老板的挑战，”如何衡量混沌工程的价值？“，可以向老板表达出，”从故障的应急效率、故障复发率、线上故障发现数来衡量“等等。所以这些问题自己要想清楚。有了坚定的意志，就要开始落地，首先要先了解自己的系统。

这里系统成熟度分 5 个等级，也可以说是业务系统所处的阶段，列出了每个阶段适合什么故障场景。刚才也有听众问，”我的服务就是单点的，还有没有实施混沌工程的必要？“，有必要，可以实施简单的实验场景，比如 CPU 满载等，来验证监控告警，如果发现没有监控告警，就要去推动完善它，然后再推动服务多实例部署，通过混沌工程一级一级的去推动系统的演进，最终实现具有韧性的系统。根据系统成熟度了解自己系统所适合的场景，接下来就要选择一款合适的混沌实验工具。

这里列举了五个维度：场景丰富度、工具类型、易用性等。可以从 awesome-chaos-engineering github 项目查找或者从 CNCF Landscpage 中查看混沌实验工具。阿里今年开源的 ChaosBlade 也已经加入到 CNCF Landscape 中，后面会对此项目做重点介绍，先来看阿里混沌工程技术的演进。

2012 年阿里内部就上线了 EOS 项目，用于梳理分布式服务强弱依赖问题，同年进行了同城容灾的断网演练。 15 年实现异地多活，16 年内部推出故障演练平台 MonkeyKing，开始在线上环境实施混沌实验，然后 18 年输出了 ACP 专有云产品和 AHAS 公有云产品，其中 AHAS 旨在将阿里的高可用架构经验以产品的形式对外输出，服务于外部。19 年推出 ChaosBlade 项目，将底层的故障注入能力对外开源，同年也推出混沌实验平台专有云版本 AHAS Chaos，接下来重点介绍一下 ChaosBlade 项目。

_14

ChaosBlade 中文名混沌之刃，是一款混沌实验实施工具，支持丰富的实验场景，比如应用、容器、基础资源等。工具使用简单，扩展方便，其遵循社区提出的混沌实验模型。

该模型分四次，层层递进，很清晰的表达出对什么组件做实验，实验范围是什么，实验触发的匹配规则有哪些，执行什么实验。该模型简洁、通用，语言领域无关、易于实现。阿里集团内的 C++、NodeJS、Dart 应用以及容器平台的实验场景都基于此模型实现。此模型具有很重要的意义，依据此模型可以更精准的描述、更好的理解、更方便沉淀实验场景以及发掘更多的场景。依据此模型实现的工具更加规范、简洁，我们具体看下 ChaosBlade 基于此模型的架构设计。

我将 ChaosBlade 的设计总结为这六点。使用 Golang 构建，实现跨平台，并且解压即用；工具使用采用 CLI 的方式，使用简单，具备完善的命令提示；遵循混沌实验模型定义场景接口，所有场景基于此接口实现，将模型转换为 cobra 框架所支持的命令参数，实现变量参数化、参数规范化，并且通过实验模型 Yaml 描述，可以很方便的实现多语言、多领域的场景扩展。而且将整个实验对象化，每个实验对象都会有个 UID，方便管理。左下角是 chaosblade 工具的使用事例，可以看出使用简洁、清晰。介绍完工具设计，我们再来谈实施混沌工程很重要的一点，如何控制爆炸半径，减小实施风险。

环境越往下，实施风险越高，实验越真实，越具有价值。我们通过两种方式来控制爆炸半径，一是实验场景粒度，从 IDC 到用户，影响范围越来越低，另一个是从生产环境隔离出一部分机器，通过录制流量，对线上流量重放，进行请求打标，实现流量路由到隔离出的环境，对这些机器和请求做实验，这样可控制的爆炸半径更大。

具备了控制爆炸半径的能力，我们可以通过平台，标准化实验流程，实现自动化执行。中间部分的图片是阿里云产品 AHAS Chaos 混沌实验平台的截图，该平台将实施混沌工程分为四个阶段。首先是准备阶段，此阶段可以定义监控指标，准备实验环境等，比如 ChaosBlade 执行 Java 应用实验，必须先执行 Prepare 操作挂载 Agent，则可放到此阶段执行。第二个阶段是执行阶段，此阶段用于执行混沌实验。第三个检查阶段，用于检查监控指标，记录问题等，第四阶段是还原阶段。此四个阶段囊括了前面提到的混沌工程实施的八个步骤，大家看到每个阶段下的每项都是一个小程序，大家可以基于规范开发自己的小程序来扩展自身实验所需要的能力，比如对接自己的业务监控，做实验前通知等。接下来看一下该平台的架构设计。

这是集团和云上混沌实验平台的架构图，通过流程引擎规范混沌工程实施步骤，对外开放平台 OpenAPI，便于上层业务建设，并且提供小程序的机制，可以对接监控平台或做一些实验前的准备操作等，将故障注入能力收敛到 ChaosBlade。基于此混沌实验平台承载了集团突袭演练、攻防演练、新零售演练等业务。此平台已经对外输出，包含公有云和专有云版本，阿里云网站搜索 AHAS 即可。具备了完善的混沌实验平台，可以在企业中推广混沌工程文化

比如建立门户网站，宣传好的架构，并且推送演练红黑榜。制订攻防制度，如故障分、演练分来推动并量化演练。可以设定固定的攻防日，全企业参与，以战养战，培养混沌文化。介绍完混沌工程在企业落地的流程，我们最后分享下分布式服务下的混沌工程实践，先来看一下分布式服务所面临的问题。

系统日益庞大，服务间的依赖错综复杂，很难评估单个服务故障对整个系统的影响，并且请求链路长，监控告警不完善，导致发现问题、定位问题难度增大，同时业务和技术迭代快，如何持续保障系统的稳定性受到很大的挑战。那么一个高可用的分布式服务应该具备哪些能力呢？

这里列举了分布式系统的高可用原则，前面的讲师伍道长提到系统的好模式和坏模式，我这里列举出的都是好模式。比如入口请求负载均衡，对异常的节点进行流量调度，通过请求限流来控制访问量，防止打垮系统，提供超时重试，当单个服务实例访问超时时，可以将请求路由到其他服务实例进行重试，梳理强弱依赖，对占用资源高的弱依赖服务进行降级，对下游出问题的服务进行熔断等等。还有系统运维方面，系统要做到可监控、可灰度、可回滚，具备弹性伸缩的能力，能快速扩容或者线下有问题的节点。这些高可用原则都可以作为混沌实验场景，从中挑选两个来讲下具体的混沌工程实践。先来看一下 Demo 拓扑图。

此拓扑图来自于阿里云 AHAS 产品架构感知功能，可自动感知架构拓扑，并且可以展示进程、网络、节点等数据。这个分布式服务 Demo 分三级调用，consumer 调用 provider，provider 调用 base，同时 provider 还调用 mk-demo 数据库，provider 和 base 服务具有两个实例，在 AHAS 架构拓扑图上，我们点击一个实例节点，可以到非常清晰的调用关系。我们后面结合这个 Demo 去讲解案例。

案例一，我们验证系统的监控告警性有效性。按照前面提到的混沌工程实施步骤，那么这个案例执行的实验场景是数据库调用延迟，我们先定义监控指标：慢 SQL 数和告警信息，做出期望假设：慢 SQL 数增加，钉钉群收到慢 SQL 告警。接下来执行实验。我们直接使用 ChaosBlade 工具执行，可以看下左下角，我们对 demo-provider 注入调用 mysql 查询时，若数据库是 demo 且表名是 d_discount，则对 50% 的查询操作延迟 600 毫秒。我们使用阿里云产品 ARMS 做监控告警。大家可以看到，当执行完混沌实验后，很快钉钉群里就收到了报警。所以我们对比下之前定义的监控指标，是符合预期的。但需要注意的是这次符合预期并不代表以后也符合，所以需要通过混沌工程持续性的验证。出现慢 SQL，可通过 ARMS 的链路根据来排查定位，可以很清楚的看出哪条语句执行慢。

前面讲了一个符合预期的案例，我们再来看一个不符合预期的。此案例是验证系统异常实例隔离的能力，我们的 Demo 中 consumer 调用 provider 服务，provider 服务具有两个实例，我们对其中一个注入延迟故障，监控指标是 consumer 的 QPS，稳态在 510 左右。我们做的容错假设是系统会自动隔离或下线出问题的服务实例，防止请求路由的此实例，所有 QPS 会有短暂的下跌，但很快会恢复。这个案例，我们使用阿里云 AHAS 混沌实验平台来执行，我们对 demo-provider-1 注入延迟故障，基于此平台可以很方便的执行混沌实验。执行混沌实验后，QPS 下跌到 40 左右，很长时间没有自动恢复，所以不符合预期，我们通过人工的方式对该异常的实例做下线处理，很快就看到，consumer 的 QPS 恢复正常。所以我们通过混沌工程发现了系统问题，我们后面需要做就是记录此问题，并且推动修复，后续做持续性的验证。

我这次分享从介绍混沌工程到如何在企业中落地，并且通过具体的分布式服务的例子介绍混沌工程的实践。我们做一下回顾总结。一是混沌工程是一种主动防御的稳定性手段，体现了反脆弱的思想；二，落地混沌工程会遇到很多挑战，坚持原则不能退让；很重要的一点是实施混沌工程不能只是把故障制造出来，需要有明确的驱动目标；最后选择合适的工具和平台，控制演练风险，实现常态化演练。