作者 | 肖长军、桑杰
ChaosBlade 是阿里巴巴 2019 年开源的混沌工程项目，已加入到 CNCF Sandbox 中。起初包含面向多环境、多语言的混沌工程实验工具 ChaosBlade，到现在发展到面向多集群、多环境、多语言的混沌工程平台 chaosblade-box，平台支持实验工具托管和工具自动化部署，通过统一用户实验界面，将用户的精力聚焦在通过混沌工程解决云原生过程中高可用问题上。本文从混沌实验模型抽象、混沌实验工具开源和混沌工程平台升级项目三阶段出发，详细介绍 ChaosBlade。
在今年可信云测评中，阿里云故障演练平台以最高分首批通过可信云混沌工程平台能力要求最高等级-先进级认证。
混沌实验模型
ChaosBlade 项目覆盖基础资源、应用服务、容器服务等混沌实验场景。在实验工具设计之初就考虑了场景模型统一，便于场景扩展和沉淀，也为平台托管实验工具实现统一场景调用提供模型依据。ChaosBlade 项目中所有的实验场景均遵循此实验模型设计，下面通过实验模型的推导、介绍、意义和具体的应用来详细介绍此模型。
1、实验模型的推导
混沌实验主要包含故障模拟，我们一般对故障的描述如下：
- 10.0.0.1 机器上挂载的 A 磁盘满造成了服务不可用；
- 所有节点上的 B dubbo 服务因为执行缓慢造成上游 A dubbo 服务调用延迟，从而造成用户访问缓慢；
- Kubernetes A 集群中 B 节点上 CPU 所有核使用率满载，造成 A 集群中的 Pod 调度异常；
- Kubernetes C 集群中 D Pod 网络异常，造成 D 相关的 Service 访问异常。
通过上述，我们可以使用以下句式来描述故障：因为某某机器（或集群中的资源，如 Node，Pod）上的哪个组件发生了什么故障，从而造成了相关影响。我们也可以通过下图来看故障描述拆分：
可以通过这四部分来描述现有的故障场景，所有我们抽象出了一个故障场景模型，也称为混沌实验模型。
2、实验模型的介绍
此实验模型详细描述如下：
- Scope: 实验实施范围，指具体实施实验的机器、集群及其资源等。
- Target: 实验靶点，指实验发生的组件。如基础资源场景中的 CPU、网络、磁盘等，Java 场景中的应用组件如 Dubbo、Redis、RocketMQ、JVM 等，容器场景中的 Node、Pod、Container自身等。
- Matcher: 实验规则匹配器，根据所配置的 Target，定义相关的实验匹配规则，可以配置多个。由于每个 Target 可能有各自特殊的匹配条件，比如 RPC 领域的 Dubbo、gRPC 可以根据服务提供者提供的服务和服务消费者调用的服务进行匹配，缓存领域的 Redis，可以根据 set、get 操作进行匹配。还可以对 matcher 进行扩展，比如扩展实验场景执行策略，控制实验触发时间。
- Action: 指实验模拟的具体场景，Target 不同，实施的场景也不一样，比如磁盘，可以演练磁盘满，磁盘 IO 读写高，磁盘硬件故障等。如果是应用，可以抽象出延迟、异常、返回指定值（错误码、大对象等）、参数篡改、重复调用等实验场景。如果是容器服务，可以模拟 Node、Pod、Container 资源异常或者其上的基础资源异常等。
使用此模型可以很清晰表达出以下实施混沌实验需要明确的问题：
- 混沌实验的实施范围是什么
- 实施混沌实验的对象是什么
- 实验对象触发实验的条件有哪些
- 具体实施什么实验场景
3、实验模型的意义
此模型具有以下特点：
- 简洁：层次清晰，通俗易懂；
- 通用：覆盖目前所有的故障场景，包含基础资源、应用服务、容器服务、云资源等；
- 易实现：很方便的定义清晰的接口规范，实验场景扩展实现简单；
- 语言、领域无关：可以扩展多语言、多领域的模型实现。
此模型具有以下的意义：
- 更精准的描述混沌实验场景；
- 更好的理解混沌实验注入；
- 方便沉淀现有的实验场景；
- 依据模型发掘更多的场景；
- 混沌实验工具更加规范、简洁。
4、实验模型的应用
混沌实验模型的应用可归纳为以下几点：
- 混沌实验模型使实验场景变量参数化，参数规范化；
- 可遵循模型实现实验场景领域化的水平扩展；
- 可将混沌实验模型和领域内标准化实现相结合，便捷实现领域内场景垂直扩展；
- 上层的领域场景可以复用遵循混沌实验模型定义的场景；
- 通过混沌实验模型声明的场景描述可以很好的接入到 ChaosBlade 中；
- 遵循实验模型可以很方便的构建上层混沌实验平台。
下文重点介绍基于此模型实现的混沌工程工具 ChaosBlade。
混沌工程实验工具：ChaosBlade
阿里巴巴内部从最早引入混沌工程解决微服务的依赖问题，到业务服务、云服务稳态验证，进一步升级到公共云、专有云的业务连续性保障，以及在验证云原生系统的稳定性等方面积累了比较丰富的场景和实践经验。并且当时混沌工程相关的开源工具存在场景能力分散、上手难度大、缺少实验模型标准，场景难以扩展和沉淀等问题。这些问题就会导致很难实现平台化，你很难通过一个平台去囊括这些工具。所以开源混沌工程实验执行工具 chaosblade，下面通过场景介绍、使用方式、架构设计和案例来详细介绍此工具。
1、混沌实验场景
ChaosBlade 工具设计初期就考虑了易用性和场景扩展的便捷性，方便大家上手使用以及根据各自需要扩展更多的实验场景，遵循混沌实验模型提供了统一的操作简洁的执行工具。混沌实验工具支持 Linux、Windows、Docker、Kubernetes等系统平台，覆盖 Java、Golang、NodeJS、C++ 语言应用，共涉及 200 多个实验场景，3000 多个实验参数（v1.0.0-GA）。目前包含的场景领域如下：
- 基础资源：比如 CPU、内存、网络、磁盘、进程、内核等
- 应用服务：比如数据库、缓存、消息、JVM 本身、微服务等，还可以指定任意类方法注入各种复杂的实验场景；指定任意方法或某行代码注入延迟、变量和返回值篡改等实验场景
- Docker 容器：比如杀容器、容器内 CPU、内存、网络、磁盘、进程等实验场景
- Kubernetes 平台：比如节点上 CPU、内存、网络、磁盘、进程实验场景，Pod 网络和 Pod 本身实验场景如杀 Pod，容器的实验场景如上述的 Docker 容器实验场景
- 云资源：比如阿里云 ECS 宕机等实验场景
2、工具使用方式
ChaosBlade 是个直接下载解压就可以使用的工具，不需要安装，然后它支持的调用方式包含 CLI 方式，直接执行 blade 命令。
比如这里举的做网络延迟的例子，你添加 -h 参数就可以看到非常完善的命令提示，比如我要一个 9520 端口调用做网络丢包，对齐前面的实验模型，我们就可以看到，它的演练目标是 network，它的 action 是丢包，它的 matcher 就是调用远程的一个服务端口 9520。执行成功后会返回实验结果，每一个实验场景我们都会作为一个对象，它会返回一个实验对象的 UID，此 UID 用于后续的实验管理，比如销毁、查询实验都是通过此 UID 来做的。要销毁实验，也就是恢复实验，直接执行 blade destroy 命令就可以了。
ChaosBlade 另一种调用方式是 Web 方式，通过执行 server 命令对外暴露 HTTP 服务，那么在上层，你如果自己构建混沌实验平台的话，你直接可以通过 HTTP 请求去调用就可以。
3、工具架构设计
ChaosBlade 依据领域实现封装成各自独立的项目，每个项目根据各领域的最佳实践来实现，不仅能满足各领域使用习惯，而且还可以通过混沌实验模型来建立与 chaosblade cli 项目的关系，方便使用 ChaosBlade 来统一调用，各领域下的实验场景依据混沌实验模型生成 yaml 文件描述，暴露给上层混沌实验平台，混沌实验平台根据实验场景描述文件的变更，自动感知实验场景的变化，无需新增场景时再做平台开发，使混沌平台更加专注于混沌工程其他部分。目前包含的执行器项目如下：
- chaosblade：混沌实验管理工具，包含创建实验、销毁实验、查询实验、实验环境准备、实验环境撤销等命令，是混沌实验的执行工具，执行方式包含 CLI 和 HTTP 两种。提供完善的命令、实验场景、场景参数说明，操作简洁清晰。
- chaosblade-spec-go: 混沌实验模型 Golang 语言定义，便于使用 Golang 语言实现的场景都基于此规范便捷实现。
- chaosblade-exec-os: 基础资源实验场景实现，如CPU、网络、内存、磁盘等。
- chaosblade-exec-docker: Docker 容器实验场景实现，通过调用 Docker API 标准化实现。
- chaosblade-operator: Kubernetes 平台实验场景实现，将混沌实验通过 Kubernetes 标准的 CRD 方式定义，很方便的使用 Kubernetes 资源操作的方式来创建、更新、删除实验场景，包括使用 kubectl、client-go 等方式执行，而且还可以使用上述的 chaosblade cli 工具执行。
- chaosblade-exec-jvm: Java 应用实验场景实现，使用 Java Agent 技术动态挂载，无需任何接入，零成本使用，而且支持卸载，完全回收 Agent 创建的各种资源。
- chaosblade-exec-cplus: C++ 应用实验场景实现，使用 GDB 技术实现方法、代码行级别的实验场景注入。
4、工具使用案例
通过一个 Dubbo 微服务案例，来介绍 ChaosBlade 工具的使用。这个微服务 Demo 分三级调用，consumer 调用 provider，provider 调用 base，同时 provider 还调用 mk-demo 数据库，provider 和 base 服务具有两个实例。
这个案例执行的实验场景是数据库调用延迟，我们先定义监控指标：慢 SQL 数和告警信息，做出期望假设：慢 SQL 数增加，钉钉群收到慢 SQL 告警。接下来执行实验。我们直接使用 ChaosBlade 工具执行，可以看下左下角，我们对 demo-provider 注入调用 mysql 查询时，若数据库是 demo 且表名是 d_discount，则对 50% 的查询操作延迟 600 毫秒。
我们使用阿里云产品 ARMS 做监控告警。大家可以看到，当执行完混沌实验后，很快钉钉群里就收到了报警。所以我们对比下之前定义的监控指标，是符合预期的。但需要注意的是这次符合预期并不代表以后也符合，所以需要通过混沌工程持续性的验证。出现慢 SQL，可通过 ARMS 的链路追踪来排查定位，可以很清楚的看出哪条语句执行慢。
混沌工程平台：chaosblade-box
为了让使用者将精力聚焦在通过混沌工程解决系统高可用问题上，而不是实验工具的选择、部署上，所以将 ChaosBlade 品牌进行升级，开源 chaosblade-box 混沌工程平台。平台托管主流的混沌实验工具，实现工具自动化的部署，通过统一的操作页面实现混沌工程实施。
下面通过平台的功能特点、架构设计及使用案例来介绍混沌工程平台 chaosblade-box。
1、平台功能特点
具备以下功能特点：
- 支持开源实验工具托管：平台可托管业界主流的实验工具，如自身的 ChaosBlade 和外部的 litmuschaos 等。后续也会托管 chaos mesh 实验工具。
- 具备丰富的实验场景：包含基础资源（CPU、内存、网络、磁盘、进程、内核、文件等）、多语言应用服务（Java、C++、NodeJS、Golang 等）、Kubernetes 平台（覆盖 Container、Pod、Node 资源场景，包含上述实验场景）。
- 实验工具自动化部署：无需手动部署实验工具，实现实验工具在主机或集群上自动化部署。
- 统一混沌实验用户界面：用户无需关心不同工具的使用方式，在统一用户界面进行混沌实验。
- 多维度实验方式：支持从主机到 Kubernetes 资源，再到应用维度进行实验编排。
- 集成云原生生态：采用 Helm 部署管理，集成 Prometheus 监控，支持云原生实验工具托管等。
2、平台架构设计
通过控制台页面可实现 chaosblade、litmuschaos 等已托管工具自动化部署，按照社区的建立的混沌实验模型统一实验场景，根据主机、Kubernetes、应用来划分目标资源，通过目标管理器来控制，在实验创建页面，可以实现白屏化的目标资源选择。平台通过调用混沌实验执行来执行不同工具的实验场景，配合接入 prometheus 监控，可以观察实验 metric 指标，后续会提供丰富的实验报告。Chaosblade-box 的部署也非常简单，具体可以查看：https://github.com/chaosblade-io/chaosblade-box/releases
3、使用说明
安装部署完成后，通过配置 Kubernetes 集群或者主机信息，可以在机器列表页面看到集群或主机数据。选择实验管理创建实验，演练维度支持主机、Node、Pod、Container 维度，选择相应的维度后，会出现对应的资源列表，可以很方便的选择。演练内容包含所托管的所有实验场景。完成实验创建后，自动跳转到演练详情页面，点击执行跳到任务详情页。
演练任务详情页面展示实验的基本信息和实验任务状态，可以很方便的控制实验，以及明确实验任务状态。
未来规划
1、chaosblade
ChaosBlade 未来以云原生为基础，提供面向多集群、多环境、多语言的混沌工程平台和混沌工程实验工具。实验工具继续聚焦在实验场景丰富度和稳定性方面，支持更多的 Kubernetes 资源场景和规范应用服务实验场景标准，提供多语言实验场景标准实现。
2、chaosblade-box
后续会将阿里云故障演练平台（可信云混沌工程平台先进型认证）核心功能开源，与现有的混沌工程平台进行融合，实现更多能力的开放。同时简化混沌工程工具部署实施方面，后续会托管更多的混沌实验工具和兼容主流的平台，实现场景推荐，提供业务、系统监控集成，输出实验报告，在易用的基础上完成混沌工程操作闭环。
作者介绍：
肖长军（花名：穹谷）：阿里巴巴技术专家，开源项目 ChaosBlade Founder&Maintainer，阿里云故障演练平台端侧负责人，可信云标准专家，混沌工程布道师，多年分布式系统架构和稳定性建设经验。
桑杰：就职于中国农业银行研发中心，从事于财务相关系统大数据研发工作。
