阿里开源混沌工程工具，搭建故障演练平台

原标题：去哪儿系统高可用之法：搭建故障演练平台

澳门新萄京官方网站，作者介绍

阿里妹导读：减少故障的最好方法就是让故障经常性的发生。通过不断重复失败过程，持续提升系统的容错和弹性能力。今天，阿里巴巴把六年来在故障演练领域的创意和实践汇浓缩而成的工具进行开源，它就是 “ChaosBlade”。如果你想要提升开发效率，不妨来了解一下。

王鹏，2017年加入去哪儿机票事业部，主要从事后端研发工作，目前在机票事业部负责行程单和故障演练平台以及公共服务ES、数据同步中间件等相关的研发工作。

高可用架构是保障服务稳定性的核心。

去哪儿网2005年成立至今，随着系统规模的逐步扩大，已经有成百上千个应用系统，这些系统之间的耦合度和链路的复杂度不断加强，对于我们构建分布式高可用的系统架构具有极大挑战。我们需要一个平台在运行期自动注入故障，检验故障预案是否起效——故障演练平台。

阿里巴巴在海量互联网服务以及历年双11场景的实践过程中，沉淀出了包括全链路压测、线上流量管控、故障演练等高可用核心技术，并通过开源和云上服务的形式对外输出，以帮助企业用户和开发者享受阿里巴巴的技术红利，提高开发效率，缩短业务的构建流程。

一、背景

例如，借助阿里云性能测试 PTS，高效率构建全链路压测体系，通过开源组件 Sentinel 实现限流和降级功能。这一次，经历了 6 年时间的改进和实践，累计在线上执行演练场景达数万次，我们将阿里巴巴在故障演练领域的创意和实践，浓缩成一个混沌工程工具，并将其开源，命名为 ChaosBlade。

这是某事业部的系统拓扑图：

ChaosBlade 是什么？

ChaosBlade 是一款遵循混沌工程实验原理，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，可实现底层故障的注入，特点是操作简洁、无侵入、扩展性强。

ChaosBlade 基于 Apache License v2.0 开源协议，目前有 chaosblade 和 chaosblade-exe-jvm 两个仓库。

chaosblade 包含 CLI 和使用 Golang 实现的基础资源、容器相关的混沌实验实施执行模块。chaosblade-exe-jvm 是对运行在 JVM 上的应用实施混沌实验的执行器。

ChaosBlade 社区后续还会添加 C 、Node.js 等其他语言的混沌实验执行器。

为什么要开源？

很多公司已经开始关注并探索混沌工程，渐渐成为测试系统高可用，构建对系统信息不可缺少的工具。但混沌工程领域目前还处于一个快速演进的阶段，最佳实践和工具框架没有统一标准。实施混沌工程可能会带来一些潜在的业务风险，经验和工具的缺失也将进一步阻止 DevOps 人员实施混沌工程。

混沌工程领域目前也有很多优秀的开源工具，分别覆盖某个领域，但这些工具的使用方式千差万别，其中有些工具上手难度大，学习成本高，混沌实验能力单一，使很多人对混沌工程领域望而却步。

阿里巴巴集团在混沌工程领域已经实践多年，将混沌实验工具 ChaosBlade 开源目的，我们希望：

• 让更多人了解并加入到混沌工程领域；
• 缩短构建混沌工程的路径；
• 同时依靠社区的力量，完善更多的混沌实验场景，共同推进混沌工程领域的发展。

系统之间的依赖非常复杂、调用链路很深、服务之间没有分层。在这种复杂的依赖下，系统发生了几起故障：

ChaosBlade 能解决哪些问题？

衡量微服务的容错能力

通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，同时观察系统整体的 QPS 或 RT 是否受影响。在此基础上可以缓慢增加故障节点范围，验证上游服务限流降级、熔断等是否有效。最终故障节点增加到请求服务超时，估算系统容错红线，衡量系统容错能力。

验证容器编排配置是否合理

通过模拟杀服务 Pod、杀节点、增大 Pod 资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及 Pod 下部署的容器是否合理。

测试 PaaS 层是否健壮

通过模拟上层资源负载，验证调度系统的有效性；模拟依赖的分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟主备节点故障，测试主备切换是否正常。

验证监控告警的时效性

通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确和时效性。

定位与解决问题的应急能力

通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报、处理流程是否合理，达到以战养战，锻炼人定位与解决问题的能力。

• 弱依赖挂掉，主流程挂掉，修改报销凭证的支付状态，下单主流程失败；
• 核心服务调用量陡增，某服务超时引起相关联的所有服务“雪崩”；
• 机房网络或者某些机器挂掉，不能提供核心服务。

功能和特点

场景丰富度高

ChaosBlade 支持的混沌实验场景不仅覆盖基础资源，如 CPU 满载、磁盘 IO 高、网络延迟等，还包括运行在 JVM 上的应用实验场景，如 Dubbo 调用超时和调用异常、指定方法延迟或抛异常以及返回特定值等，同时涉及容器相关的实验，如杀容器、杀 Pod。后续会持续的增加实验场景。

使用简洁，易于理解

ChaosBlade 通过 CLI 方式执行，具有友好的命令提示功能，可以简单快速的上手使用。命令的书写遵循阿里巴巴集团内多年故障测试和演练实践抽象出的故障注入模型，层次清晰，易于阅读和理解，降低了混沌工程实施的门槛。

场景扩展方便

所有的 ChaosBlade 实验执行器同样遵循上述提到的故障注入模型，使实验场景模型统一，便于开发和维护。模型本身通俗易懂，学习成本低，可以依据模型方便快捷的扩展更多的混沌实验场景。

三个故障原因：

ChaosBlade 的演进史

EOS（2012-2015）：故障演练平台的早期版本，故障注入能力通过字节码增强方式实现，模拟常见的 RPC 故障，解决微服务的强弱依赖治理问题。

MonkeyKing（2016-2018）：故障演练平台的升级版本，丰富了故障场景（如：资源、容器层场景），开始在生产环境进行一些规模化的演练。

AHAS（2018.9-至今）：阿里云应用高可用服务，内置演练平台的全部功能，支持可编排演练、演练插件扩展等能力，并整合了架构感知和限流降级的功能。

ChaosBlade：是 MonkeyKing 平台底层故障注入的实现工具，通过对演练平台底层的故障注入能力进行抽象，定义了一套故障模型。配合用户友好的 CLI 工具进行开源，帮助云原生用户进行混沌工程测试。

• 系统强弱依赖混乱、弱依赖无降级；
• 系统流量陡增，系统容量不足，没有限流熔断机制；
• 硬件资源网络出现问题影响系统运行，没有高可用的网络架构。

近期规划

功能迭代：

• 增强 JVM 演练场景，支持更多的 Java 主流框架，如 Redis，GRPC
• 增强 Kubernetes 演练场景
• 增加对 C 、Node.js 等应用的支持

各种各样的问题，在这种复杂的依赖结构下被放大，一个依赖30个SOA服务的系统，每个服务99.99%可用。99.99%的30次方≈99.7%。0.3%意味着一亿次请求会有3,000,00次失败，换算成时间大约每月有2个小时服务不稳定。随着服务依赖数量的变多，服务不稳定的概率会呈指数性提高，这些问题最后都会转化为故障表现出来。

社区共建：

欢迎访问 ChaosBlade@GitHub，参与社区共建，包括但不限于：

• 架构设计
• 模块设计
• 代码实现
• Bug Fix
• Demo样例
• 文档、网站和翻译

本文作者：中亭

阅读原文

本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

二、系统高可用的方法论

如何构建一个高可用的系统呢？首先要分析一下不可用的因素都有哪些：

高可用系统典型实践

理论上来说，当图中所有的事情都做完，我们就可以认为系统是一个真正的高可用系统。但真是这样吗？

那么故障演练平台就隆重登场了。当上述的高可用实践都做完，利用故障演练平台做一次真正的故障演练，在系统运行期动态地注入一些故障，从而来验证下系统是否按照故障预案去执行相应的降级或者熔断策略。

三、故障演练平台

故障演练平台：检验故障预案是否真正的起作用的平台。

故障类型：主要包括运行期异常、超时等等。通过对系统某些服务动态地注入运行期异常来达到模拟故障的目的，系统按照预案执行相应的策略验证系统是否是真正的高可用。

1、故障演练平台的整体架构

故障演练平台架构主要分为四部分：

• 前台展示系统（WEB）：展示系统之间的拓扑关系以及每个AppCode对应的集群和方法，可以选择具体的方法进行故障的注入和解除；
• 发布系统（Deploy）：这个系统主要用于将故障演练平台的Agent和Binder包发布到目标APP的机器上并且启动执行。前台展示系统会传递给发布平台要进行故障注入的AppCode以及目标APP的IP地址，通过这两个参数发布系统可以找到相应的机器进行Jar包的下载和启动；
• 服务和命令分发系统（Server）：这个系统主要是用于命令的分发、注入故障的状态记录、故障注入和解除操作的逻辑、权限校验以及相关的Agent的返回信息接收功能。前台页面已经接入QSSO会对当前人可以操作的IP列表做故障注入，防范风险。后端命令分发的模块会和部署在目标APP上的Agent进行通信，将命令推送到Agent上执行字节码编织，Agent执行命令后返回的内容通过Server和Agent的长连接传回Server端；
• Agent和Binder程序：Agent负责对目标APP做代理并且做字节码增强，具体代理的方法可以通过传输的命令来控制，代理方法后对方法做动态的字节码增强，这种字节码增强具有无侵入、实时生效、动态可插拔的特点。Binder程序主要是通过发布系统传递过来的AppCode和启动端口（ServerPort）找到目标APP的JVM进程，之后执行动态绑定，完成运行期代码增强的功能。

2、 Agent整体架构

目前AOP的实现有两种方式：

• 静态编织：静态编织发生在字节码生成时根据一定框架的规则提前将AOP字节码插入到目标类和方法中；
• 动态编织：在JVM运行期对指定的方法完成AOP字节码增强。常见的方法大多数采用重命名原有方法，再新建一个同名方法做代理的工作模式来完成。

静态编织的问题是如果想改变字节码必须重启，这给开发和测试过程造成了很大的不便。动态的方式虽然可以在运行期注入字节码实现动态增强，但没有统一的API很容易操作错误。基于此，我们采用动态编织的方式、规范的API来规范字节码的生成——Agent组件。

Agent组件：通过JDK所提供的Instrumentation-API实现了利用HotSwap技术在不重启JVM的情况下实现对任意方法的增强，无论我们是做故障演练、调用链追踪（QTrace）、流量录制平台（Ares）以及动态增加日志输出BTrace，都需要一个具有无侵入、实时生效、动态可插拔的字节码增强组件。

Agent的事件模型

如图所示，事件模型主要可分为三类事件：

BEFORE在方法执行前事件、THROWS抛出异常事件、RETURN返回事件。这三类事件可以在方法执行前、返回和抛出异常这三种情况做字节码编织。

如下代码：

// BEFORE

try {

/*

* do something...

*/

foo();

// RETURN

return;

} catch (Throwable e) {

// THROWS

}

本文由澳门新萄京官方网站发布于互联网信息,转载请注明出处：阿里开源混沌工程工具，搭建故障演练平台