混沌工程随着云原生的发展逐渐进入大家的视野，通过混沌工程可以很好地发现和解决在云原生化过程中的高可用问题。阿里巴巴在 2019 年开源了底层的混沌工程工具 - chaosblade，今年年初再次开源混沌工程控制台 chaosblade-box，ChaosBlade 品牌进一步升级。本文主要围绕云原生面临的高可用挑战和混沌工程机遇，详细介绍开源控制台的设计、特性和实践和未来规划，旨在帮助企业更好的了解控制台并通过其来实现混沌工程落地，解决云原生系统下高可用问题。
去年年底 AWS 和 Google 都出现了比较严重的服务故障：AWS 故障是由于处理数据流服务 kinesis 出现问题，导致很多云服务不可用；Google 故障是由于登录服务的扩容配额问题导致多服务不可用。从中可以发现，他们都存在因服务依赖不合理，导致一个服务故障影响多个服务不可用，缺少应急预案，整个故障恢复时间比较长，监控告警系统不完善等问题，Google 故障发生几十分钟后才感知故障的发生，AWS 的 CloudWatch 处于不可用的状态。故障不可避免，所有的一切时时刻刻存在着失败的风险。
尤其随着敏捷开发、DevOps、微服务、云原生架构和治理的出现，应用的交付能力大大提升，但系统的复杂度也日益增加，在业务快速迭代的同时，如何保障业务持续的高可用性和稳定性面临着很大的挑战。混沌工程通过主动注入故障的方式，提前发现系统的薄弱点，推进架构的改进，最终实现业务韧性。
打不倒我的必使我强大，建设韧性架构是混沌工程的目标。韧性架构包含两部分，一部分是韧性系统，比如具备冗余性、扩展性、降级熔断、故障隔离等，避免级联故障，构建容灾容错的韧性系统。另一部分是韧性组织，包含高效交付、故障预案、应急响应等组织协同建设。高度韧性的系统也会出现预期之外的故障，所以韧性的组织能弥补韧性系统缺失的部分，通过混沌工程构建极致的韧性架构。
常见的云原生高可用架构架构基本上是基于多可用区，或者是跨地域级的容灾架构，业务应用采用微服务架构下集群部署，中间件具备容错容灾能力等等。从底层设施到上层业务，都存在潜在的故障风险，比如机房断网、整个可用区不可用、集群宕机、中间件节点 crash 等。从可用区到集群、主机，再到细粒度的请求，故障影响的爆炸半径逐渐减小，这也是混沌工程原则中非常重要的一点 -- 控制爆炸半径。控制爆炸半径的方式一般有两种：一是环境隔离，通过隔离实验的机房、集群等来控制影响面；二是基于实验工具或平台自身的场景控制能力，比如 chaosblade 实验工具，通过实验参数来控制实验粒度，比如微服务调用延迟，可以控制到单个服务接口、版本，甚至一次请求。下面我们来介绍一下 chaosblade 混沌实验工具。
Chaosblade 是一款遵循混沌实验模型的混沌实验执行工具，具有场景丰富度高、简单易用等特点，而且扩展场景也特别方便，开源不久便被加入到 CNCF Landspace 中，成为主流的一款混沌工具。chaosblade 是个直接下载解压即可使用的工具，不需要安装，它支持的调用方式包含 CLI 方式，直接执行 blade 命令，这里举个做网络屏蔽的例子：我们添加 -h 参数就可以看到非常完善的命令提示，比如要一个 9520 端口调用做网络丢包，它的演练目标是 network；它的 action 是丢包；它的 matcher 就是调用远程的一个服务端口 9520。执行成功后会返回实验结果，每一个实验场景我们都会作为一个对象，它会返回一个实验对象的 UID，此 UID 用于后续的实验管理，比如销毁、查询实验都是通过此 UID 来做的。要销毁实验，也就是恢复实验，直接执行 blade destroy 命令就可以。
Chaosblade 支持多平台、多语言环境，包含 Linux、Kubernetes、Docker 平台，以及 Java、NodeJS、C++、Golang 语言应用。共涉及 200 多个场景、3000 多个参数，为用户提供丰富的场景和实验参数控制。使用 blade -h 命令可以查看详细的使用文档，包含案例和场景、参数介绍。下面我们重点介绍一下 chaosblade 对应用服务场景的支持。
Chaosblade 支持 Java、C++、Golang、NodeJS 语言应用，其中对 Java 应用的支持能力更丰富，包含 OOM、线程池满、指定线程数、CPU 负载、codecache 满等 JVM 本身的场景，还支持很多常用组件，比如 Druid、Dubbo、Elasticsearch、HBase、HttpClient、Redis、Kafka、Lettuce、MongoDB、MySQL、PostgreSQL、RabbitMQ、RocketMQ、Servlet、Tars、gRPC 等。Java 场景更强大的一个功能是可用指定任意类和方法注入异常、延迟、篡改返回，甚至可以通过自己编写 Groovy 或 Java 脚本，实现更加复杂的实验场景来满足自身业务实验需求。还支持链路标识识别、请求数限制等能力。Golang 场景是通过编译时在任意代码行注入埋点逻辑来实现，目前支持修改变量值、修改参数值、修改返回值、异常、延迟、内存溢出和 Panic 场景。现在，已登记的试用或在使用的企业已经 40 家，其中包含一些深度合作共建的企业用户。下面我们举个例子来说明 chaosblade 故障注入的执行流程。
以云原生 Dubbo 应用调用下游 PetQueryService 服务延迟三秒故障场景为例，我们可以通过 chaosblade 自带的 blade 工具或 kubectl 以及通过编码的方式来执行。此处列举了使用 kubectl 和自身的 blade 工具执行。先看使用 kubectl 执行，通过配置 ChaosBlade 类型的 YAML 文件，使用 kubectl apply 命令来创建实验，Kubernetes 会创建一条 chaosblade 资源，后续通过 kubectl delete 命令删除此咨询即可恢复实验。创建好 chaosblade 资源后，chaosblade operator 监听 chaosblade 资源创建，查询目标容器，按需透传场景相关的实验工具，调用 blade 工具在容器内执行实验。使用 blade 执行，命令如上图，指定 K8s 下的 dubbo 应用注入延迟故障，通过 process 参数指定应用名、time 参数指定延迟时间、service 参数指定受影响的服务接口、names 参数和 container-names 分别指定 Pod 和 Container 名称，如果不清楚参数可以添加 -h 来查看命令帮助。
通过以上案例可以看出 chaosblade 工具使用简单，而且支持丰富的实验场景，我们在此工具的基础上做了 ChaosBlade 品牌升级。
我们开源了 chaosblade-box 混沌工程控制台，可实现混沌实验平台化操作，而且支持更多混沌工程实验工具的托管，比如 litmuschaos 等。品牌升级后，我们更进一步地解决了用户落地混沌工程的困难度，让用户将更多的精力放到推进系统韧性提升上，旨在通过混沌工程帮助企业解决系统云原生化过程中高可用问题。
Chaosblade-box 是一个面向多集群、多环境、多语言的云原生混沌工程平台。关键功能如下所示：
- 实现了实验工具自动化部署，无需用户登录到每台机器部署实验工具，简化用户部署成本。
- 支持实验工具托管，现在已支持 litmuschaos ，后续会支持更多优秀的实验工具来满足各种实验场景需求。
- 通过提供统一的混沌实验用户界面，屏蔽底层故障注入方式，让用户在同一个平台上实现不同工具的实验。
- 支持实验目标自动获取、实验场景管理等等。
- 支持多个实验维度，比如主机、Kubernetes、应用，其中 Kubernetes 又包含 Container、Pod、Node 实验维度。
- 后续会更进一步支持混沌工程闭环，实现稳态定义、实验执行、稳态评估等，协助用户构建高可用的云原生系统。
下面通过页面截图来了解一下 chaosblade-box 平台能力。
通过上述图片可以看出 chaosblade-box 平台整体功能，在托管更多工具场景的基础上，标准化实验场景和实验管控界面，简化用户操作，降低使用门槛，提供详细的白屏化日志，便于问题跟踪和排查。接下来我们看下平台技术架构图。
通过控制台页面可实现 chaosblade、litmus 等已托管的工具部署，按照社区的建立的混沌实验模型统一实验场景，根据主机、Kubernetes、应用来划分目标资源，通过目标管理器来控制，在实验创建页面，可以实现白屏化的目标资源选择。平台通过调用混沌实验执行来执行不同工具的实验场景，配合接入 prometheus 监控，可以观察实验 metric 指标，后续会提供丰富的实验报告。
下面我们通过一个杀 Pod 实验场景来介绍平台的使用。
首先是部署 chaosblade-box，部署完成后，在实验列表页面创建实验，选择 Kubernetes Pod 实验维度，实验创建共分为四步，前两步资源选择和场景选择是必填项，后两步监控接入和实验名称是非必填项。在 Pods 列表中选择多个目标 Pods，然后选择杀 Pods 实验场景，对接 Prometheus Pod 监控，完成实验创建。在实验详情页面可以点击执行实验进入实验任务详情页面，查看实验详细信息。
Chaosblade-box 后续规划重点在托管更多的实验工具，实现更多工具自动化部署，同时支持更多的语言应用，添加更加复杂的调度策略和流程编排，生成实验报告，实验报告分三个阶段，一是实验基础报告，包含实验和监控的基本信息，二是实验缺陷报告，包含实验中发现的问题，三是实验高可用建设报告，根据实验中发现的问题提出解决方案建议。
作者 | 肖长军（穹谷）
本文为阿里云原创内容，未经允许不得转载。
有疑问加站长微信联系（非本文作者）
