专栏首页云计算与大数据去哪儿网基于ChaosBlade的混沌工程实践

去哪儿网基于ChaosBlade的混沌工程实践

1

前言

微服务架构已经在去哪儿网(Qunar)实施多年,微服务应用数量达到数千之多,随着服务之间的调用链路越来越复杂,故障频频发生,给公司带来巨大的经济损失,稳定性建设工作就成为了一项重要的工作。从 2010 年 Netflix 提出通过 Chaos Engineering 的方式提升系统稳定性之后,到今天 Chaos Engineering 已经被证明是一种有效的发现系统弱点,建立对系统抵御生产环境中失控条件的能力以及信心的有效手段。从 2019 年底去哪儿网也结合自身的技术体系开始进行混沌工程相关的探索,下面就来介绍下我们的实践经验。

2

选型

为了避免重复造轮子,我们在启动项目之初调研了当时已经开源的混沌工程相关工具,并结合自身的技术体系特点进行了分析:

  • 当时基础资源以 KVM 为主,同时也在探索容器化,所以两个平台都需要支持。
  • 公司内部主要的技术栈为 Java。

基于上面的两点,加上社区活跃情况等,选择 ChaosBlade 为故障注入的工具,加上自研的混沌工程控制台(当时还没有 chaosblade-box)作为最终方案。

3

架构

基于公司内部的系统体系,整体的架构如下:

纵向来看,自上而下:

  • 服务治理,Portal(提供应用画像,CICD的平台)提供了应用的依赖关系,应用的属性,运行时资源等信息,通过混沌工程UI可以创建出故障演练(故障演练包含了应用信息,应用资源,待注入故障等);
  • 混沌工程控制台(Chaos控制台),提供了多个应用多个故障的任务流程编排,故障演练流程的控制的功能;
  • Saltstack,chaosblade-operator 提供了 chaosblade 的安装和卸载能力;
  • 应用的资源分为 KVM 和 K8S 承载的容器,故障演练编排系统通过 Restful API 和 chaosblade 启动的 HTTP 服务进行通信,来进行故障的注入和恢复。

横向来看:

  • 自动化测试平台主要提供演练时线上 case 的回归能力,以及用来做强弱依赖的标记断言;
  • 演练开始时,Chaos控制台会监听相关应用的核心指标告警,如果有告警信息会通知给相关负责人并终止和恢复演练,这样可以及时止损。

4

系统演进

去哪儿网这边的混沌工程主要经历了 2 个阶段:

1、故障注入能力的建设。这个阶段主要解决的问题是用户可以手动的通过创建故障演练,通过合适的故障策略来验证系统的某些方面是否符合预期;

2、提供强弱依赖场景下的,依赖标记,强弱依赖验证,以及自动化强弱依赖闭环的能力,用混沌工程来提高微服务治理效率。

4.1 故障演练

通过故障注入来模拟故障发生是混沌工程的基础能力。在这个阶段主要提供 3 种场景的故障注入,机器关机,OS 层的故障,以及 Java 应用的故障注入,在此基础之上我们还做了场景化的功能。

4.1.1 演练流程

一个典型的演练流程如下:

4.1.2 难点

  • 开源故障策略不足

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个问题:

  • agent的安装和卸载
  • 策略的注入和恢复
  • 控制端的改造成本

基于上面几个方案的对比,最终是基于方案 3 进行实施的。

4.2 强弱依赖自动闭环

4.2.1 背景

基于故障演练平台我们提供了强弱依赖场景下的故障演练功能:

  • 应用间依赖信息展示,依赖关系标注
  • 根据依赖信息,反填故障策略参数

但是整个强弱依赖关系的验证还是需要人来驱动,于是我们结合了自动化测试工具开发强弱依赖自动标记的功能,通过自动化的流程完成强弱依赖关系的维护,形成闭环。

4.2.2 方案

chaos 控制台会周期性的从服务治理平台获取应用的依赖关系,根据下游接口来生成基于抛异常策略的故障演练。接着对应用的测试环境进行故障注入,再通过自动化测试平台跑 case 以及实时做 diff 来断言,最终得到断言结果。chaos 控制台结合测试断言加故障策略命中的日志来判断当前下游接口是强依赖还是弱依赖。

4.2.3 难点

1、java Agent 兼容性

自动化测试平台支持录制回放模式,在回归测试时,可以对某些接口使用事先录制好的流量进行mock,这种模式下会使用基于 jvm-sandbox 的录制回放agent。chaosblade-exec-jvm 也是基于 jvm-sandbox 的agent,2个agent在一起使用会有一些兼容性问题需要解决。

  • 两个agent不能同时生效?jvm-sandbox 在1.3.0版本增加 namespace 功能,也就是说可以同时启用多个基于 jvm-sandbox 的 java agent,但是前提条件是 namespace 不同。chaosblade 中默认使用的 default namespace, 通过修改 chaosblade 的中的 namespce 来解决。
  • AOP同时切一个Libary的时候,如果mock先生效,故障注入就无效了?在录制回放的agent增加了黑名单的功能来规避这个问题。

2、测试断言和普通测试有区别

使用自动化测试平台做回归测试的时候,更关注是是数据的完整性和准确性,但是在做故障演练的时候,通常是弱依赖已经有问题,除了常规的状态码判断等,对返回结果的判断更多是核心数据节点是否正确。为此在自动化测试平台中单独多了一套断言配置来适配故障演练。

5

开源贡献

去哪儿网混沌工程的实践过程中主要使用的开源项目是 Chaosblade。在使用过程对 chaosblade、chaosblade-exec-jvm、chaosblade-operator 有不同程度的二次开发和Bug修复,部分修改已经提交给官方repo并merge。同时也和 Chaosblade 社区有过交流沟通,准备进行社区共建,为开源社区贡献自己的一份力量。

6

未来规划

当前我们的故障演练平台已经支持80+次模拟机房断电演练,同时也已经有500+次日常演练,涉及核心应用50+,机器4000+,业务线也形成了按季度周期演练及上线前验证的良好文化氛围。

我们下一步的主要目标就是自动化线上随机演练,通过服务依赖链路确定最小化爆炸半径,建立线上演练稳态断言,最终实现全司核心页面的全部链路定期随机演练,同时也会发掘混沌工程在服务治理、稳定性建设中的使用场景,为公司业务稳定发展提供技术保障。

本文分享自微信公众号 - 黑洞日志(heidcloud)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-08-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • ChaosBlade:混沌工程

    ChaosBlade 项目覆盖基础资源、应用服务、容器服务等混沌实验场景。在实验工具设计之初就考虑了场景模型统一,便于场景扩展和沉淀,也为平台托管实验工具实现统...

    heidsoft
  • 混沌工程介绍与实践

    在分布式系统架构下,服务间的依赖日益复杂,很难评估单个服务故障对整个系统的影响,并且请求链路长,监控告警的不完善导致发现问题、定位问题难度增大,同时业务和技术迭...

    CNCF
  • 混沌工程(Chaos Engineering) 到底是什么?

    2014年,Netflix团队创建了一种新的角色,叫作混沌工程师(Chaos Enigneer),并开始向工程社区推广。项目目标、业务场景、人员结构、实施方式的...

    一个会写诗的程序员
  • ChaosBlade:从零开始的混沌工程(一)

    随着微服务的盛行以及容器技术的普及,借助 Kubernetes 的容器编排能力,部署一套分布式系统的难度也越来越低。但随之而来的是越来越复杂的系统,以及越来越难...

    郭旭东
  • 软件混沌工程原则以及应用介绍(PRINCIPLES OF CHAOS ENGINEERING)

    Chaos Engineering(混沌工程),相信搞互联网的或多或少都听过,Netflix 发明了 Chaos Monkey,经过社区的发展回馈,慢慢形成了 ...

    软测小生
  • ChaosBlade:从零开始的混沌工程(二)

    在上篇文章中,我们介绍了混沌工程以及 ChaosBlade。从本篇开始,从 ChaosBlade 的安装部署,到实验的创建销毁,在实践的角度,一步步的完成各种混...

    郭旭东
  • 混沌工程在工商银行的探索实践 | Q推荐

    混沌工程是一种提高技术架构弹性能力的复杂技术手段,旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为...

    深度学习与Python
  • ChaosBlade:从零开始的混沌工程(五)

    在上篇文章中,我们介绍了如何使用 ChaosBlade Operator 对 node 资源进行混沌实验。从本章将继续对 Kubernetes Containe...

    郭旭东
  • 混沌工程-初识

    公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程。为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践。

    老_张
  • 混沌工程-初识

    公司新成立了一个稳定性团队,20年的重要目标之一就是开展混沌工程。为了后续更好的开展工作,记录关于“混沌工程”相关的知识以及工程实践。

    周辰晨
  • 微服务架构下的质量迷思——混沌工程

    从2005年Peter Rodgers博士提出微web服务,到2014年ThoughtWorks首席科学家Martin Fowler与James Lewis共同...

    ThoughtWorks
  • China .NET Conf 2019-.NET技术架构下的混沌工程实践

    这个月的8号、9号,个人很荣幸参加了China.NET Conf 2019 , 中国.NET开发者峰会,同时分享了技术专题《.NET技术架构下的混沌工程实践》,...

    Edison.Ma
  • 混沌工程之ChaosMesh使用之三模拟POD网络丢包

    在《混沌工程之ChaosBlade-Operator使用之一模拟POD丢包场景》中,我们提到过一次丢包场景的模拟了,但是不同的混沌工具,是否有不同的实现方式呢...

    高楼Zee
  • 混沌工程之ChaosMesh使用之二模拟POD网络丢包

    在《混沌工程之ChaosBlade-Operator使用之一模拟POD丢包场景》中,我们提到过一次丢包场景的模拟了,但是不同的混沌工具,是否有不同的实现方式呢...

    高楼Zee
  • ChaosBlade:从零开始的混沌工程(三)

    在上篇文章中,我们介绍了如何安装 ChaosBlade Operator,并进行了简单的使用。从本章开始,所有的实践章节,都会有配套的 katacode[1] ...

    郭旭东
  • 熟悉又陌生的 k8s 字段:finalizers

    经常操作 Kubernetes 集群的同学肯定对 finalizers 字段不陌生,每当删除 namespace 或 pod 等一些 Kubernetes 资源...

    Jintao Zhang
  • 干货 | 通过不断地失败来避免失败,携程混沌工程实践

    Ctrip SRE,负责携程网站系统可靠性保障,探索和落地高可用体系的运维架构,如多活容灾、全链路压测、混沌工程、AIOPS等。

    携程技术
  • ChaosBlade:从零开始的混沌工程(四)

    在上篇文章中,我们介绍了如何使用 ChaosBlade Operator 对 pod 资源进行混沌实验。从本章将继续对 Kubernetes Node 资源的混...

    郭旭东
  • 混沌工程之ChaosBlade-Operator使用之一模拟POD丢包场景

    ChaosBlade-Operator 启动后将会在每个节点部署一个 chaosblade-tool Pod 和一个 chaosblade-operator P...

    高楼Zee

扫码关注云+社区

领取腾讯云代金券