java工商银行项目_ChaosBlade 在工商银行混沌工程体系中的应用实践

作者 | 吴冕冠 来源|阿里巴巴云原生公众号

互联网金融时代下，金融产品和服务模式不断创新，交易量大幅攀升。面对互联网金融的全新发展态势，传统的单体 IT 架构暴露出很多不适应的地方，为此业界广泛应用云计算、分布式等新技术，构建分布式架构和运维体系，以支撑金融业务的快速发展。这些新技术的应用使得基础设施复杂性日益增加，不可预见的用户行为和事件交织在一起，对系统、应用架构的可靠性提出了更高要求。为解决分布式系统的不确定性，确保生产稳定运行，混沌工程应运而生。根据《Chaos Engineering》书中的定义：混沌工程是在分布式系统上进行实验的学科，目的是建立系统抵御生产环境中湍流条件的能力。通常来说，混沌工程指对分布式系统中的服务器随机注入不同类型的故障，发现并修复系统中的潜在问题，从而提升整个分布式系统的高可用能力。

传统系统高可用测试的痛点

中国工商银行从 2015 年启动了 IT 架构转型工程，基于分布式、云计算初步构建了开放平台核心银行系统，目前分布式体系已承载 150 余个应用，累计部署容器超过 2 万套，日均服务调用量超 70 亿，消息发送峰值每秒逾 150 万笔，实现了远超主机性能容量的集群处理能力。但与此同时，在分布式体系下支撑服务的底层技术架构和平台系统日益复杂，生产运行不确定因素相较于主机明显增多，网络异常、磁盘 IO 夯等系统层面故障导致的生产问题呈现增长趋势。由于传统项目测试人员针对系统高可用相关场景的测试意识和能力相对缺乏，且目前该领域暂无统一的测试工具，测试人员需耗费较高的学习成本去筛选和学习各类测试工具，导致项目测试主要集中在业务功能测试，缺乏对系统可用性的测试。

故障注入工具选型

为提升工行分布式体系的稳定性，降低测试人员学习和使用相关工具的门槛，我们着重分析了 Chaosblade、Litmus、Choas Monkey 等优秀开源工具在各类故障注入场景中的能力。这些故障注入工具既有专用于云平台环境，也有适用于操作系统层面，还有针对如服务异常等应用层面的故障注入。但这些工具大多仅提供了基本的故障注入能力，还需进一步扩展完善，实现企业级的平台能力。

表 1  业界主流故障注入工具能力情况

ChaosBlade 支持目前主流的故障注入场景，相对其他几个故障注入工具，ChaosBlade 故障注入覆盖的场景最全，支持四大类、几十种常用的故障注入能力，且提供了统一的 CLI 交互界面，学习成本相对较低，其技术栈与我行分布式体系和云计算体系兼容性也较好。

图 1  ChaoBlade 故障注入能力

因此，ChaosBlade 各方面基本满足我行技术体系的需求。为保障故障注入工具能力的可扩展性，实现与上层调度平台的解耦，降低调用方的使用难度，我们基于 ChaosBlade 进行了二次开发，扩展了 ChaosBlade 的故障注入能力。

一是将故障注入的调用能力封装成 Rest 接口(当时 ChaosBlade 还不支持通过 http 与之交互)。

二是增加服务器系统指标收集模块，可实时收集服务器的 CPU、内存、网络等系统硬件使用情况。

三是增加了故障注入任务解析模块，该模块可将混沌工程故障演练管理平台下发的故障演练任务解析成多个故障注入事件，然后根据各个故障注入事件的开始和结束时间分别调用 ChaosBlade 故障注入工具实施故障注入和撤销操作。

基于 ChaosBlade 的系统高可用测试解决方案

基于 ChaosBlade 故障注入工具，我们建设了一套功能完备的企业级混沌工程故障演练平台。

1. 平台架构

平台主要由门户、任务调度框架、故障注入介质、高可用专家库四部分组成。

门户提供各类混沌实验任务的编排和配置服务，借助演练流程编排面板，用户可以便捷地管理各类混沌实验任务；混沌实验开始实施后，用户可通过任务进度条、服务器指标展示图等实时查看混沌实验任务的进度和服务器各项系统指标情况；混沌实验执行结束后，门户会收集混沌实验过程中的所有数据，并对数据进行分析和加工，生成混沌工程实验报告供后续分析和归档。

任务调度框架负责门户和故障注入介质之间的交互，核心功能是实现混沌实验任务的批量下发和调度，该模块可以快速批量下发各种类型的混沌实验，支持失败重发、超时重发、高并发等机制。

故障注入介质负责接收门户下发的任务，并实施相应的故障注入事件。

高可用专家库是混沌工程测试人员根据平时混沌测试总结得到的高可用测试模型，基于高可用专家库用户可以根据演练场景自动关联对应的故障注入事件，并为用户提供一键生成演练流程的能力。

图 2  工行混沌工程故障演练平台架构

2. 故障演练过程详解

工程师对目标服务器进行故障注入时，涉及环境准备、故障注入任务编排、实施故障注入、终止故障注入任务等一系列操作。

1)环境准备

在实施故障演练之前，需要在混沌工程故障演练平台添加将要实施故障注入的目标服务器。如果实施目标是容器，则无需用户维护，系统可以自动关联 PaaS 平台查询各应用的容器。

2)故障演练任务编排

用户登陆故障演练平台后，选择故障演练环境。创建一个故障演练流程，每个故障演练流程至少添加一个故障演练任务，每个故障演练任务可以有一个或多个故障演练事件，每个故障演练任务可以关联一台或多台服务器。常用的故障演练事件包括对 CPU、内存、磁盘、网络、数据库、服务调用、JVM 等注入各类故障。

3)实施故障注入

用户完成故障注入任务编排后，即可开始实施故障演练。用户点击安装按钮之后，混沌工程故障演练平台就会将故障注入介质下发至目标服务器，并执行用户预先编排好的故障演练任务。

此外，故障注入介质还可实时收集服务器在混沌实验运行期间的性能状态，如系统层面的 CPU、内存、网络、磁盘使用情况，并将这些系统指标回传至混沌工程故障演练管理平台，以图形化的方式进行展示，以验证在执行混沌实验期间系统状态是否达到预期效果。

4)终止故障注入任务

故障演练任务被用户手动停止或者正常执行结束后，平台会自动调用虚机管理平台或 PaaS 管理平台的接口，将故障演练销毁命令下发至各目标服务器，恢复之前注入的故障并销毁故障注入介质。

实际效果

1. 节点管理模块

支持用户根据故障演练具体需求，在工行混沌工程故障演练平台定义不同的故障演练环境，并为各环境添加对应的目标服务器列表。

图 3  工行混沌工程故障演练平台节点管理模块

2. 演练管理模块

演练管理模块负责维护故障演练任务，支持用户选择需要实施故障演练的目标服务器以及需要执行的故障注入事件。

图 4  工行混沌工程故障演练平台演练管理模块

3. 演练监控模块

演练监控模块主要通过故障注入介质收集故障演练过程中各目标服务器当前系统层面的关键指标信息，并在工行混沌工程故障演练平台进行实时展示。

图 5  工行混沌工程故障演练平台监控管理模块

4. 高可用专家库

我们通过对历史生产问题的排查经验进行总结，并结合在大量混沌测试实践中归纳得到的高可用测试模型，建立了工行混沌工程故障演练平台高可用专家库，共包含六大类一百多种测试案例，涵盖了应用层、数据库层、平台层、中间件层、路由层、缓存层等主流的应用高可用测试场景。为降低混沌测试门槛，高可用专家库支持应用基于自身架构自动匹配测试案例，达到一键生成故障演练任务的目的。

图 6  工行混沌工程故障演练平台高可用专家库

5. 其他能力

此外，为方便混沌测试人员使用混动工程故障演练平台对测试案例和测试结果的管理，平台也提供了测试案例管理，问题管理等附加模块。同时对于一些 ChaosBlade 暂时还不具备的故障注入能力如 IO 夯住，我们也自行研发了相关功能并集成至故障注入介质当中。

6. 实践情况

我们根据分布式技术体系生产运维中的“痛点”：

一是全行应用众多，高可用测试的场景和规模庞大，基于故障注入工具通过手动输入命令的方式实施故障演练效率十分低下。

二是工行分布式系统底层架构非常复杂，涉及容器、虚机、物理机等多类设施，单一故障注入工具无法满足不同场景的故障演练需求。

因此我们建设了工行混沌工程故障演练平台，将服务器系统故障和 JVM 故障这两大类作为主要切入点，基于工行混沌工程故障演练平台高可用专家库，率先在行内快捷支付、聚合支付等一些重点业务线进行落地试点，通过注入上下游调用异常、线程池异常、磁盘 IO 夯等多种类型的故障，在各业务线的平台层、消息中间件层、应用层、数据库层、路由层均发现了一些传统测试难以发现的高可用设计等方面的问题。例如：通过对支付类交易实施混沌实验，模拟双活应用的单园区网络断连然后再恢复，发现该过程中支付链路存在一些底层故障场景下交易失败的架构设计缺陷，并在投入生产之前对支付系统架构进行了重新设计和升级。截止目前全行已对七十多各应用开展常态化故障演练测试，共实施故障演练七千余次，发现并解决了一百多个应用系统层面的高可用问题，有效避免了在生产环境触发这些问题。

未来展望

后续，工行将持续全面推广混沌工程文化，在大型活动前期进行专项大规模混沌测试，并根据各应用的测试结果，制定应用高可用水平量化评估体系。此外，随着混沌工程故障演练在测试环境的不断推进，平台应用可靠性不断增强，除了不断扩大演练半径外，下一步计划将混沌工程故障演练逐步从测试环境向生产环境推移，对全行重要产品线编排实施各种类型的演练，以确保整个平台能应对业务高峰极端条件下的压力，全面提升全行开放平台应用服务水平，为工商银行系统架构的持续优化、产品的快速创新提供坚实支撑。