作者 | 穹谷

导读：从上篇开始，我们进入到了高可用的章节，上篇提到的熔断能力，是历年保障大促当天晚上整个系统不被洪峰流量打垮的法宝。本文将重点介绍为什么我们要做混沌工程以及如何使用 ChaoBlade 工具和 AHAS 平台快速实施混沌工程。

前言

从上篇开始，我们进入到了高可用的章节，上篇提到的熔断能力，是历年保障大促当天晚上整个系统不被洪峰流量打垮的法宝，本篇介绍的措施与熔断有不一样的地方，一个是线上洪峰来临时的保护措施，它更多的是流量低峰或者在专门的演练环境中，针对可能遇见的各类故障，采取演练的手段，来窥探对业务的影响；它的主要目的是让我们自己更加了解自己业务系统的薄弱环节，以便来对症下药增强系统的高可用能力。

为什么需要混沌工程？

任何一个系统都会有未曾可知的故障出现，拿现代工艺已经很好的磁盘来说，有统计数据的磁盘最低的年故障率都可达到 0.39% 。即便是这么底层基础设施，也会有这么高的不确定性。

尤其当下大部分的服务形态都是分布式架构，在分布式系统架构下，服务间的依赖日益复杂，更很难评估单个服务故障对整个系统的影响；并且请求链路长，监控告警的不完善导致发现问题、定位问题难度增大；同时业务和技术迭代快，如何持续保障系统的稳定性和高可用性受到很大的挑战。

1. 云原生系统挑战更大

谈到云原生，可以说云原生是一个理念，主要包含的技术有云设施、容器、微服务、服务网格、Serverless 等技术。云设施指公有云、专有云和混合云等，是云原生系统的基础设施，基础实施的故障可能对整个上层业务系统造成很大影响，所以说云设施的稳定性是非常重要的。

容器服务的挑战可以分两大类：一类是面向 K8s 服务提供商，服务是否稳定；另一类是面向用户，配置的扩缩容规则是否有效，实现的 CRD 是否正确，容器编排是否合理等问题。

分布式服务的挑战主要是复杂性，单个服务的故障很难判断对整个系统的影响；service mesh，sidecar 的服务路由、负载均衡等功能的有效性，还有 sidecar 容器本身的可用性。

一些新兴的部署模式的挑战如 serverless，现在基本上都是函数加事件的形式，资源调度是否有效，而且 serverless 服务提供商屏蔽了一些中间件，你能掌控的是函数这些服务，那么你可以通过混沌工程去验证你函数调用的一些配置，比如超时配置、相关的一些降级策略等这些是否合理。

以上技术都有相同的共性，比如弹性可扩展、松耦合、容错性高、还有一些易于管理，便于观察这些特性。所以说在云原生时代，通过混沌工程可以更有效的推进系统的“云原生”化。

2. 每个职位都需要懂混沌工程

混沌工程是一种思想，它让系统中的每个参与者都学会去考虑一件事情：如果所依赖的某服务中断了服务该怎么办？对于以下四类人群而言，意义尤显突出：

对于架构师来说，可以验证系统架构的容错能力，我们需要面向失败设计的系统，混沌工程的思想就是践行这一原则的方式；
对于开发和运维，可以提高故障的应急效率，实现故障告警、定位、恢复的有效和高效性；
对于测试来说，可以弥补传统测试方法留下的空白，之前的测试方法基本上是从用户的角度去做，而混沌工程是从系统的角度进行测试，降低故障复发率；
对于产品和设计，通过混沌事件查看产品的表现，提升客户使用体验。所以说混沌工程面向的不仅仅是开发、测试，拥有最好的客户体验是每个人的目标，所以实施混沌工程，可以提早发现生产环境上的问题，并且可以以战养战，提升故障应急效率和可以使用体验，逐渐建设高可用的韧性系统。

混沌工程实操

在一次完整的演练流程中，需要先做好计划，对相关的演练计划有一个行为预期；演练相关计划的同时，我们推荐的最佳实践是需要配合有业务的自动化测试，每演练一次需要全方位的跑完自动化测试用例，这样才能全面的了解真正的业务产生时对业务造成的影响：

在上面的图中描述了一次完整的故障演练需要经过的步骤，其中最重要的一步的实践是如何“执行预制混沌实验”？因为这一步需要一个专业的工具，在业内目前最流行的工具是 Netflix 的 Chaos Monkey 和阿里巴巴开源的 ChaosBlade，我们接下来主要是介绍如何使用 ChaosBlade 来完成一次演练。

1. 使用 ChaosBlade 去做

ChaosBlade 是阿里巴巴一款遵循混沌实验模型的混沌实验执行工具，具有场景丰富度高，简单易用等特点，而且扩展场景也特别方便，开源不久就被加入到 CNCF Landspace 中，成为主流的一款混沌工具。目前包含的场景有基础资源、应用服务、容器服务、云资源等。ChaosBlade 下载解压即用，可以通过执行 blade 命令来执行云原生下微服务的演练场景，下面是模拟 Kubernetes 下微服务中数据库调用延迟故障。

2. 使用 AHAS 故障演练平台去做

AHAS 故障演练平台是阿里云对外部用户开放的云产品，使用方式可参考官方文档。其底层的故障注入能力大部分来源于 ChaosBlade 实现，另一部分使用自身小程序扩展实现。AHAS 相比于 ChaosBlade，除了简单易用的白屏操作之外，还实现了上层的演练编排、权限控制、场景管理等，而且还针对微服务新增应用维度演练，简化演练成本，优化演练体验。

结尾

混沌工程是一种主动防御的稳定性手段，体现的是反脆弱的思想，实施混沌工程不能只是把故障制造出来，需要有明确的驱动目标。我们要选择合适的工具和平台，控制演练风险，实现常态化演练。

阿里巴巴内部从最早引入混沌工程解决微服务的依赖问题，到业务服务、云服务稳态验证，进一步升级到公共云、专有云的业务连续性保障，以及在验证云原生系统的稳定性等方面积累了比较丰富的场景和实践经验；这一些经验沉淀我们都通过开源产品以及云产品 AHAS 一一对外输出。

Spring Cloud 应用在 Kubernetes 上的最佳实践 — 高可用（混沌工程）相关推荐

SpringCloud 应用在 Kubernetes 上的最佳实践 —— 高可用（容量评估）
作者 | 牛兔导读:本文是<SpringCloud 应用在 Kubernetes 上的最佳实践>系列文章的第 11 篇,从前面两期开始我们进入到了高可用专题,分别介绍了流量防护和故障演练 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 —— 高可用（弹性伸缩）
作者 | 三未前言弹性伸缩是一种为了满足业务需求.保证服务质量.平衡服务成本的重要应用管理策略.弹性伸缩让应用的部署规模能够根据实时的业务量产生动态调整,在业务高峰期扩大部署规模,保证服务不被业务 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（熔断）
作者 | 宿何导读:前几篇我们主要站在应用发布的场景,描述在发布过程中会遇到的灰度.监控.回滚.优雅上下线等保障发布能顺利进行的注意事项.作为一个程序员 GG,可灰度的发布顺利上线往往意味着准点下班 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（优雅上下线）
作者 | 骄龙导读:本篇是<SpringCloud 应用在 Kubernetes 上的最佳实践>系列文章的第八篇,主要介绍了如何做到流量的无损上/下线.更多相关文章阅读可查看文末. 前言 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可回滚）
作者 | 长门 **导读:**本篇是<SpringCloud 应用在 Kubernetes 上的最佳实践>系列文章的第七篇,主要介绍了新功能上线时,如何尽快减少对线上用户的影响?发布系统需 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可监控）
作者 | 骐羽阿里巴巴技术专家导读:本篇是"SpringCloud 应用在 Kubernetes 上的最佳实践"系列文章的第六篇,主要介绍了如何保障生产环境服务稳定,做到随时发 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 诊断（线上联调）
作者 | 纳海阿里巴巴高级开发工程师 **导读:**上篇我们介绍了应用成功上云后,面对应用的管理,如何做可灰度的线上发布,那么当云上的应用行为不符合预期的时候,您会怎么处理呢?修改代码,打包,部署 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可灰度）
作者 | 白寂阿里云开发工程师导读:前三篇文章我们介绍了应用的开发和部署,那么在应用成功上云后,我就要面对应用的管理话题了,这一篇我们来看看如何做线上发布,并且是可灰度的. 相关文章推荐: &l ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署)
作者 | 孤弋阿里云高级技术专家,负责 EDAS 的开发和用户体验优化工作. 导读:上一篇文章<SpringCloud 应用在 Kubernetes 上的最佳实践 - 部署篇(开发部署)&g ...

Spring Cloud 应用在 Kubernetes 上的最佳实践 — 高可用（混沌工程）

前言