小熊科技|SpringCloud在K8s上的最佳实践—高可用混沌工程前言从上篇开始

前言从上篇开始，我们进入到了高可用的章节，上篇提到的熔断能力，是历年保障大促当天晚上整个系统不被洪峰流量打垮的法宝，本篇介绍的措施与熔断有不一样的地方，一个是线上洪峰来临时的保护措施，他更多的是流量低峰或者在专门的演练环境中，针对可能遇见的各类故障，采取演练的手段，来窥探对业务的影响。他的主要目的是让我们自己更加了解自己业务系统的薄弱环节，以便来对症下药增强系统的高可用能力。本文重点介绍为什么要做混沌工程以及如何使用 ChaosBlade 工具和 AHAS 平台快速实施混沌工程。
为什么需要混沌工程任何一个系统都会有未曾可知的故障出现，拿现代工艺已经很好的磁盘来说，有统计数据的磁盘最低的年故障率都可达到 0.39%。即便是这么底层基础设施，也会有这么高的不确定性。尤其当下大部分的服务形态都是分布式架构，在分布式系统架构下，服务间的依赖日益复杂，更很难评估单个服务故障对整个系统的影响；并且请求链路长，监控告警的不完善导致发现问题、定位问题难度增大；同时业务和技术迭代快，如何持续保障系统的稳定性和高可用性受到很大的挑战。
云原生系统挑战更大谈到云原生，可以说云原生是一个理念，主要包含的技术有云设施、容器、微服务、服务网格、Serverless等技术。云设施指公有云、专有云和混合云等，是云原生系统的基础设施，基础实施的故障可能对整个上层业务系统造成很大影响，所以说云设施的稳定性是非常重要的。容器服务的挑战可以分两大类，一类是面向 k8s 服务提供商，服务是否稳定，另一类是面向用户，配置的扩缩容规则是否有效，实现的 CRD 是否正确，容器编排是否合理等问题。分布式服务的挑战主要是复杂性，单个服务的故障很难判断对整个系统的影响；service mesh ， sidecar 的服务路由、负载均衡等功能的有效性，还有 sidecar 容器本身的可用性。一些新兴的部署模式的挑战如 serverless ，现在基本上都是函数加事件的形式，资源调度是否有效，而且 serverless 服务提供商屏蔽了一些中间件，你能掌控的是函数这些服务，那么你可以通过混沌工程去验证你函数调用的一些配置，比如超时配置，还有相关的一些降级策略，这些是否合理。以上技术都有相同的共性，比如弹性可扩展、松耦合、容错性高、还有一些易于管理，便于观察这些特性。所以说在云原生时代，通过混沌工程可以更有效的推进系统的“云原生”化。
每个职位都需要懂混沌工程【小熊科技|SpringCloud在K8s上的最佳实践—高可用混沌工程】混沌工程是一种思想，他让系统中的每个参与者都学会去考虑一件事情：如果所依赖的某服务中断了服务该怎么办？对于以下四类人群而言，意义尤显突出：

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

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