微服务架构已经在去哪儿网(Qunar)实施多年,微服务应用数量达到数千之多,随着服务之间的调用链路越来越复杂,故障频频发生,给公司带来巨大的经济损失,稳定性建设工作就成为了一项重要的工作。从 2010 年 Netflix 提出通过 Chaos Engineering 的方式提升系统稳定性之后,到今天 Chaos Engineering 已经被证明是一种有效的发现系统弱点,建立对系统抵御生产环境中失控条件的能力以及信心的有效手段。从 2019 年底去哪儿网也结合自身的技术体系开始进行混沌工程相关的探索,下面就来介绍下我们的实践经验。
为了避免重复造轮子,我们在启动项目之初调研了当时已经开源的混沌工程相关工具,并结合自身的技术体系特点进行了分析:
基于上面的两点,加上社区活跃情况等,选择 ChaosBlade 为故障注入的工具,加上自研的混沌工程控制台(当时还没有 chaosblade-box)作为最终方案。
基于公司内部的系统体系,整体的架构如下:
纵向来看,自上而下:
横向来看:
去哪儿网这边的混沌工程主要经历了 2 个阶段:
1、故障注入能力的建设。这个阶段主要解决的问题是用户可以手动的通过创建故障演练,通过合适的故障策略来验证系统的某些方面是否符合预期;
2、提供强弱依赖场景下的,依赖标记,强弱依赖验证,以及自动化强弱依赖闭环的能力,用混沌工程来提高微服务治理效率。
通过故障注入来模拟故障发生是混沌工程的基础能力。在这个阶段主要提供 3 种场景的故障注入,机器关机,OS 层的故障,以及 Java 应用的故障注入,在此基础之上我们还做了场景化的功能。
一个典型的演练流程如下:
chaosblade-exec-jvm 中提供了 Java 故障注入的基础能力,也提供了部分开源组件的插件,但是对于公司内部的组件来说还是不足。于是我们中间件的同学进行了二次开发,增加了 AsyncHttpClient, QRedis 故障注入相关的插件,同时也针对 HTTP DUBBO 增加了基于调用点的故障注入功能。
2021年中,去哪儿网开始应用的容器化迁移,故障演练也需要支持容器化下的演练。基于 chaosblade-operator 做了如下几个方案选型:
方案 | 说明 | 优势 | 劣势 |
---|---|---|---|
chaosblade-operator | 完全采用开源方案,Agent安装和策略注入都使用CRD的方式 | 贴近云原生,CRD比较完善 | 控制端需要重新开发一套对接K8s的故障注入流程,前端给用户的策略也需要重新兼容,如果新增策略也需要开发CRD |
sidecar | 伴随应用整个应用周期,也需要通过CRD或者exec的方式来操作agent | 提前占用内存,CPU资源,只解决了agent安装问题,策略下发和控制端逻辑没解决 | |
chaosblade-operator + blade server | 使用CRD完成Agent的安装卸载,策略注入还是使用http端口交互的模式 | 改造成本小,控制端跟KVM的方式一致 | 需要对 chaosblade-operator 进行部分功能的二次开发 |
方案中主要关注的3个问题:
基于上面几个方案的对比,最终是基于方案 3 进行实施的。
基于故障演练平台我们提供了强弱依赖场景下的故障演练功能:
但是整个强弱依赖关系的验证还是需要人来驱动,于是我们结合了自动化测试工具开发强弱依赖自动标记的功能,通过自动化的流程完成强弱依赖关系的维护,形成闭环。
chaos 控制台会周期性的从服务治理平台获取应用的依赖关系,根据下游接口来生成基于抛异常策略的故障演练。接着对应用的测试环境进行故障注入,再通过自动化测试平台跑 case 以及实时做 diff 来断言,最终得到断言结果。chaos 控制台结合测试断言加故障策略命中的日志来判断当前下游接口是强依赖还是弱依赖。
1、java Agent 兼容性
自动化测试平台支持录制回放模式,在回归测试时,可以对某些接口使用事先录制好的流量进行mock,这种模式下会使用基于 jvm-sandbox 的录制回放agent。chaosblade-exec-jvm 也是基于 jvm-sandbox 的agent,2个agent在一起使用会有一些兼容性问题需要解决。
2、测试断言和普通测试有区别
使用自动化测试平台做回归测试的时候,更关注是是数据的完整性和准确性,但是在做故障演练的时候,通常是弱依赖已经有问题,除了常规的状态码判断等,对返回结果的判断更多是核心数据节点是否正确。为此在自动化测试平台中单独多了一套断言配置来适配故障演练。
去哪儿网混沌工程的实践过程中主要使用的开源项目是 Chaosblade。在使用过程对 chaosblade、chaosblade-exec-jvm、chaosblade-operator 有不同程度的二次开发和Bug修复,部分修改已经提交给官方repo并merge。同时也和 Chaosblade 社区有过交流沟通,准备进行社区共建,为开源社区贡献自己的一份力量。
当前我们的故障演练平台已经支持80+次模拟机房断电演练,同时也已经有500+次日常演练,涉及核心应用50+,机器4000+,业务线也形成了按季度周期演练及上线前验证的良好文化氛围。
我们下一步的主要目标就是自动化线上随机演练,通过服务依赖链路确定最小化爆炸半径,建立线上演练稳态断言,最终实现全司核心页面的全部链路定期随机演练,同时也会发掘混沌工程在服务治理、稳定性建设中的使用场景,为公司业务稳定发展提供技术保障。