本文来自阿里巴巴高可用架构团队高级开发工程师肖长军(花名穹谷)在 GIAC(全球互联网架构大会)上的分享,包含三部分内容:(阿里巴巴中间件公众号对话框发送“混沌工程”,获取分享PPT)
- 混沌工程的定义、价值、原则和流程;
- 混沌工程如何在企业中落地,以及 ChaosBlade 和混沌实验平台 AHAS Chaos 架构设计;
- 结合两个具体案例介绍了分布式服务下的混沌工程实践;
大家好,我是来自阿里的肖长军,今天给大家分享混沌工程在分布式服务架构下的具体实践。
先做个自我介绍,我来自于阿里高可用架构团队,花名穹谷,做过分布式系统设计和 APM 研发相关工作,现在专注于高可用架构和混沌工程领域,是阿里云产品 AHAS 底层技术负责人和开源项目 ChaosBlade 负责人,并且承担集团内故障演练、突袭演练、攻防演练相关的研发工作。今天分享的内容包含以下三个方面。
先从混沌工程的定义、价值、原则和实施步骤介绍混沌工程,然后分享混沌工程如何在企业中落地,最后介绍分布式服务下混沌工程实践案例。我们先来看一下什么是混沌工程。
混沌工程理论一文中提到,其是在分布式系统上进行实验的学科,核心目的是提高生产环境中系统的容错性和可恢复性。尼采的这句话: "打不倒我的必使我强大",也很好的诠释了混沌工程反脆弱的思想。除了这里提到的目的,实施混沌工程还有哪些价值呢?
这里我从四个角色来说明,对于架构师来说,可以验证系统架构的容错能力,比如验证现在提倡的面向失败设计的系统;对于开发和运维,可以提高故障的应急效率,实现故障告警、定位、恢复的有效和高效性。对于测试来说,可以弥补传统测试方法留下的空白,之前的测试方法基本上是从用户的角度去做,而混沌工程是从系统的角度进行测试,降低故障复发率。对于产品和设计,通过混沌事件查看产品的表现,提升客户使用体验。所以说混沌工程面向的不仅仅是开发、测试,拥有最好的客户体验是每个人的目标。我们知道,系统发生故障的那一刻不是由你来选择的,而是那一刻选择你,你所能做,只能是为之做好准备。了解了混沌工程的价值,我们再来看一下实施混沌工程的一些原则。
前面 Vilas 老师也提到了,我这里重点来介绍一下这五项原则。第一条:”建立一个围绕稳定状态行为的假说“,其包含两个含义,一个是定义能直接反应业务服务的监控指标,需要注意的是这里的监控指标并不是系统资源指标,比如CPU、内存等,这里的监控指标是能直接衡量系统服务质量的业务监控。举个例子,一个调用延迟故障,请求的 RT 会变长,对上层交易量造成下跌的影响,那么这里交易量就可以作为一个监控指标。这条原则的另一个含义是故障触发时,对系统行为作出假设以及监控指标的预期变化。第二个指模拟生产环境中真实的或有理论依据的故障,第三个建议在生产环境中运行实验,但也不是说必须在生产环境中执行,只是实验环境越真实,混沌工程越有价值。持续的执行才能持续的降低故障复发率和提前发现故障,所以需要持续的自动化运行试验,最后一个,混沌工程很重要的一点是控制爆炸半径,也就是试验影响面,防止预期外的资损发生,后面会介绍控制爆炸半径的方式。依据这些指导原则可以更有效实施混沌工程,那么混沌工程的实施步骤是什么?
主要细分为这 8 步,指定试验计划,定义稳态指标,做出系统容错假设,执行实验,检查稳态指标,记录、恢复 实验,修复发现的问题,然后做持续验证。以上是对混沌工程理论相关的介绍,那么如何在企业中落地混沌工程呢?
我这里分为三个阶段,首先要坚定价值,因为你会受到来自多方面的挑战,其次引入混沌工程技术,最后在企业中推广混沌工程文化。在实施混沌工程之前,必须能说清楚混沌工程的价值,而且当受到挑战时,意志要坚定。
比如来自老板的挑战,”如何衡量混沌工程的价值?“,可以向老板表达出,”从故障的应急效率、故障复发率、线上故障发现数来衡量“等等。所以这些问题自己要想清楚。有了坚定的意志,就要开始落地,首先要先了解自己的系统。
这里系统成熟度分 5 个等级,也可以说是业务系统所处的阶段,列出了每个阶段适合什么故障场景。刚才也有听众问,”我的服务就是单点的,还有没有实施混沌工程的必要?“,有必要,可以实施简单的实验场景,比如 CPU 满载等,来验证监控告警,如果发现没有监控告警,就要去推动完善它,然后再推动服务多实例部署,通过混沌工程一级一级的去推动系统的演进,最终实现具有韧性的系统。根据系统成熟度了解自己系统所适合的场景,接下来就要选择一款合适的混沌实验工具。
这里列举了五个维度:场景丰富度、工具类型、易用性等。可以从 awesome-chaos-engineering github 项目查找或者从 CNCF Landscpage 中查看混沌实验工具。阿里今年开源的 ChaosBlade 也已经加入到 CNCF Landscape 中,后面会对此项目做重点介绍,先来看阿里混沌工程技术的演进。
2012 年阿里内部就上线了 EOS 项目,用于梳理分布式服务强弱依赖问题,同年进行了同城容灾的断网演练。 15 年 实现异地多活,16 年内部推出故障演练平台 MonkeyKing,开始在线上环境实施混沌实验,然后 18 年输出了 ACP 专有云产品 和 AHAS 公有云产品,其中 AHAS 旨在将阿里的高可用架构经验以产品的形式对外输出,服务于外部。19 年推出 ChaosBlade 项目,将底层的故障注入能力对外开源,同年也推出混沌实验平台专有云版本 AHAS Chaos,接下来重点介绍一下 ChaosBlade 项目。
ChaosBlade 中文名混沌之刃,是一款混沌实验实施工具,支持丰富的实验场景,比如应用、容器、基础资源等。工具使用简单,扩展方便,其遵循社区提出的混沌实验模型。
该模型分四次,层层递进,很清晰的表达出对什么组件做实验,实验范围是什么,实验触发的匹配规则有哪些,执行什么实验。该模型简洁、通用,语言领域无关、易于实现。阿里集团内的 C++、NodeJS、Dart 应用以及容器平台的实验场景都基于此模型实现。此模型具有很重要的意义,依据此模型可以更精准的描述、更好的理解、更方便沉淀实验场景以及发掘更多的场景。依据此模型实现的工具更加规范、简洁,我们具体看下 ChaosBlade 基于此模型的架构设计。
我将 ChaosBlade 的设计总结为这六点。使用 Golang 构建,实现跨平台,并且解压即用;工具使用采用 CLI 的方式,使用简单,具备完善的命令提示;遵循混沌实验模型定义场景接口,所有场景基于此接口实现,将模型转换为 cobra 框架所支持的命令参数,实现变量参数化、参数规范化,并且通过实验模型 Yaml 描述,可以很方便的实现多语言、多领域的场景扩展。而且将整个实验对象化,每个实验对象都会有个 UID,方便管理。左下角是 chaosblade 工具的使用事例,可以看出使用简洁、清晰。介绍完工具设计,我们再来谈实施混沌工程很重要的一点,如何控制爆炸半径,减小实施风险。
环境越往下,实施风险越高,实验越真实,越具有价值。我们通过两种方式来控制爆炸半径,一是实验场景粒度,从 IDC 到用户,影响范围越来越低,另一个是从生产环境隔离出一部分机器,通过录制流量,对线上流量重放,进行请求打标,实现流量路由到隔离出的环境,对这些机器和请求做实验,这样可控制的爆炸半径更大。
具备了控制爆炸半径的能力,我们可以通过平台,标准化实验流程,实现自动化执行。中间部分的图片是阿里云产品 AHAS Chaos 混沌实验平台的截图,该平台将实施混沌工程分为四个阶段。首先是准备阶段,此阶段可以定义监控指标,准备实验环境等,比如 ChaosBlade 执行 Java 应用实验,必须先执行 Prepare 操作挂载 Agent,则可放到此阶段执行。第二个阶段是执行阶段,此阶段用于执行混沌实验。第三个检查阶段,用于检查监控指标,记录问题等,第四阶段是还原阶段。此四个阶段囊括了前面提到的混沌工程实施的八个步骤,大家看到每个阶段下的每项都是一个小程序,大家可以基于规范开发自己的小程序来扩展自身实验所需要的能力,比如对接自己的业务监控,做实验前通知等。接下来看一下该平台的架构设计。
这是集团和云上混沌实验平台的架构图,通过流程引擎规范混沌工程实施步骤,对外开放平台 OpenAPI,便于上层业务建设,并且提供小程序的机制,可以对接监控平台或做一些实验前的准备操作等,将故障注入能力收敛到 ChaosBlade。基于此混沌实验平台承载了集团突袭演练、攻防演练、新零售演练等业务。此平台已经对外输出,包含公有云和专有云版本,阿里云网站搜索 AHAS 即可。具备了完善的混沌实验平台,可以在企业中推广混沌工程文化
比如建立门户网站,宣传好的架构,并且推送演练红黑榜。制订攻防制度,如故障分、演练分来推动并量化演练。可以设定固定的攻防日,全企业参与,以战养战,培养混沌文化。介绍完混沌工程在企业落地的流程,我们最后分享下分布式服务下的混沌工程实践,先来看一下分布式服务所面临的问题。
系统日益庞大,服务间的依赖错综复杂,很难评估单个服务故障对整个系统的影响,并且请求链路长,监控告警不完善,导致发现问题、定位问题难度增大,同时业务和技术迭代快,如何持续保障系统的稳定性受到很大的挑战。那么一个高可用的分布式服务应该具备哪些能力呢?
这里列举了分布式系统的高可用原则,前面的讲师伍道长提到系统的好模式和坏模式,我这里列举出的都是好模式。比如入口请求负载均衡,对异常的节点进行流量调度,通过请求限流来控制访问量,防止打垮系统,提供超时重试,当单个服务实例访问超时时,可以将请求路由到其他服务实例进行重试,梳理强弱依赖,对占用资源高的弱依赖服务进行降级,对下游出问题的服务进行熔断等等。还有系统运维方面,系统要做到可监控、可灰度、可回滚,具备弹性伸缩的能力,能快速扩容或者线下有问题的节点。这些高可用原则都可以作为混沌实验场景,从中挑选两个来讲下具体的混沌工程实践。先来看一下 Demo 拓扑图。
此拓扑图来自于阿里云 AHAS 产品架构感知功能,可自动感知架构拓扑,并且可以展示进程、网络、节点等数据。这个分布式服务 Demo 分三级调用,consumer 调用 provider,provider 调用 base,同时 provider 还调用 mk-demo 数据库,provider 和 base 服务具有两个实例,在 AHAS 架构拓扑图上,我们点击一个实例节点,可以到非常清晰的调用关系。我们后面结合这个 Demo 去讲解案例。
案例一,我们验证系统的监控告警性有效性。按照前面提到的混沌工程实施步骤,那么这个案例执行的实验场景是数据库调用延迟,我们先定义监控指标:慢 SQL 数和告警信息,做出期望假设:慢 SQL 数增加,钉钉群收到慢 SQL 告警。接下来执行实验。我们直接使用 ChaosBlade 工具执行,可以看下左下角,我们对 demo-provider 注入调用 mysql 查询时,若数据库是 demo 且表名是 d_discount,则对 50% 的查询操作延迟 600 毫秒。我们使用阿里云产品 ARMS 做监控告警。大家可以看到,当执行完混沌实验后,很快钉钉群里就收到了报警。所以我们对比下之前定义的监控指标,是符合预期的。但需要注意的是这次符合预期并不代表以后也符合,所以需要通过混沌工程持续性的验证。出现慢 SQL,可通过 ARMS 的链路根据来排查定位,可以很清楚的看出哪条语句执行慢。
前面讲了一个符合预期的案例,我们再来看一个不符合预期的。此案例是验证系统异常实例隔离的能力,我们的 Demo 中 consumer 调用 provider 服务,provider 服务具有两个实例,我们对其中一个注入延迟故障,监控指标是 consumer 的 QPS,稳态在 510 左右。我们做的容错假设是系统会自动隔离或下线出问题的服务实例,防止请求路由的此实例,所有 QPS 会有短暂的下跌,但很快会恢复。这个案例,我们使用阿里云 AHAS 混沌实验平台来执行,我们对 demo-provider-1 注入延迟故障,基于此平台可以很方便的执行混沌实验。执行混沌实验后,QPS 下跌到 40 左右,很长时间没有自动恢复,所以不符合预期,我们通过人工的方式对该异常的实例做下线处理,很快就看到,consumer 的 QPS 恢复正常。所以我们通过混沌工程发现了系统问题,我们后面需要做就是记录此问题,并且推动修复,后续做持续性的验证。
我这次分享从介绍混沌工程到如何在企业中落地,并且通过具体的分布式服务的例子介绍混沌工程的实践。我们做一下回顾总结。一是混沌工程是一种主动防御的稳定性手段,体现了反脆弱的思想;二,落地混沌工程会遇到很多挑战,坚持原则不能退让;很重要的一点是实施混沌工程不能只是把故障制造出来,需要有明确的驱动目标;最后选择合适的工具和平台,控制演练风险,实现常态化演练。
这个是部门内部部分高可用架构相关的产品图,以及对应的对外输出的阿里云产品,如包含架构感知、故障演练、限流降级的 AHAS,具备监控告警和链路跟踪的 ARMS,以及性能测试服务 PTS,欢迎大家使用。我的分享到此结束,谢谢大家。
ChaosBlade 项目地址:https://github.com/chaosblade-io/chaosblade
AHAS 云产品地址:https://www.aliyun.com/product/ahas
本文作者:中间件小哥
本文为云栖社区原创内容,未经允许不得转载。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。