分布式架构下混沌工程提升云原生应用的稳定性和可观测性

　　在谈云原生整体解决方案的时候经常会听到混沌工程这个词，实际自己是在去年就不断听到这个词，但是一直没有仔细去了解清楚究竟是什么意思，最近由于阿里开源自己在云原生下的混沌工程工具和框架，因此有必要将混沌工程的一些思考做下简单记录。
　　在我谈学习的金字塔模型的时候经常谈到，对于任何新知识或技术的学习首先要形成自己能够理解的概念模型，做到在概念上和原理上明白，其次才是去自我实践，真正从内部实现机制上明白。
　　今天这篇文章重点还是将混沌工程究竟是什么解释清楚。混沌工程是什么
　　2010年，Netflix Eng Tools团队开发出了Chaos Monkey。当时Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。
　　在17年Netflix出版了一本书籍《Chaos Engineering》,正是提出混沌工程的概念，该书在19年引入了国内，中文名即《混沌工程-系统稳定性探索之路》。因此混沌工程的概念在19年左右被大家越来越重视，特别是随着云原生，分布式微服务架构的发展，也促进了混沌工程本身的快速发展。
　　我们先看下网上对混沌工程的一个基础定义和说明。
　　混沌工程是对分布式系统进行实验的学科，以便建立对系统抵御生产中动荡条件的能力的信心。Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’scapability to withstand turbulent conditions in production.
　　通俗地说，混沌工程就是要在你的系统上进行混沌实验，根据实验结果分析来发现你的系统有哪些缺陷，然后对系统加以改进，如果有不可解决的问题，那么可以提前知道一旦发生怎么处理是损失最小的。
　　通过不断地迭代实验来提高系统的弹性，不仅可以很好地给客户提供服务，还能够让各位工程师高枕无忧，减少半夜被叫起来处理故障的次数，最终帮助建立起稳定可靠的系统。
　　混沌工程是由混沌工程师来执行的，他们通过一系列的混沌实验，来学习观察系统的表现，并能通过此种表现去指导工程师来提高系统的健壮性。这有点像科学家通过做实验去学习定律，混沌工程师就是通过实验来发现系统的知识的。
　　它跟传统的测试有很大的区别，传统测试会提前定义好输入和输出，如果不满足这个结论，测试就出错了，具有非常明确的目的；混沌实验不是如此，实验会产生什么样的信息是不确定的。比如整个网络延迟、CPU 过载、内存过载、IO 出错等等实验，会产生什么样的结果呢？有些我们可以预料，有些则不然，只有发生了，我们才会看到。
　　通过以上对混沌工程的说明，可能理解起来还是比较困难。
　　简单总结下混沌工程的核心，就是通过一个工具或系统，能够动态不确定的模拟生产环境的各种不确定性故障，类似网络延迟或中断，节点故障，CPU或内存超负荷等。以观察整个IT资源平台和应用系统在故障下的容错性，稳定性。测试环境能否完全模拟生产？
　　对于做过大型系统或软件项目建设得都清楚。
　　一个大型的软件系统上线前，不仅仅是要做软件系统的功能性测试，更加重要的是需要进行安全，性能，高可靠性，耐受性等各方面的测试工作。
　　对于性能测试大家都比较清楚，我们会根据实际的业务场景并发需求来设计或模拟相应的用户数或并发量，数据量等对IT系统性能进行测试，并根据TPS值，CPU和内存负荷，平均响应时间来预估业务系统能否满足大并发业务场景需求。
　　而对于高可靠性测试，我们会做一些和高可用性相关的容灾演练，比如模拟节点中断，网络中断等场景，来验证整个IT基础部署架构本身的高可靠性。
　　在这里我们来谈两个问题。
　　性能测试难以完全模拟真实场景
　　首先测试环境能否完全模拟生产的业务量，并发访问场景。做这个项目的人往往都清楚，这个实际上相当难的事情。其一是测试环境往往资源配置比生产环境要少，也就是说测试环境的IT基础设施配置难以和生产环境完全相同；其二是虽然类似LoadRunner等各种性能测试工具也可以录制各种复合并发场景，但是这个复合场景也很难和真实生产环境业务和并发完整一致。其三是对于一个大型应用，本身数据库各个数据表的数据容量，索引情况等也极大地影响到应用的访问性能。而一般性能测试时候也难以模拟出真实的数据库容量。
　　因此简单来说就是即使你做了性能测试，也很难确保你生产环境上线后就不出问题。
　　高可靠性演练本身和并发性能分离
　　其次就是高可靠性的演练和测试，注意这个测试往往和性能测试是分开的，也就是或我们在进行高可靠性测试的时候往往并不会说同时进行大并发的性能测试，仅仅是进行IT系统的高可靠性和冗余能力验证。
　　但是实际系统的高可用性往往和业务大并发量，大数据量访问密切相关。如果我们将两类测试进行了分离，本身又很难模拟真正的业务场景。
　　那么我们实际真正需要或观测的重点却是，在持续业务并发访问下，当整个IT应用出现某个资源节点或中间件故障的时候，整个应用本身的稳定性和容错能力。混沌工程希望解决的问题
　　简单来说混沌工程本身就是模拟节点故障，观测系统的稳定性，可靠性和可恢复性。
　　基于前面谈到的内容，我想强调下混沌工程的一些关键点。
　　其一就是混沌工程不是仅仅在测试环境做，而是在生产环境直接模拟。也就是说测试环境难以完全模拟生产环境，那么就需要在生产环境进行节点故障模拟，也确认整个IT架构在生产环境的稳定性。
　　其二就是真正融合了业务并发性能测试和可靠性测试两方面内容。而在传统测试中这两者往往是分离的，很难在测试环境中完全模拟。
　　其三就是故障模拟本身的不确定性，第一就是故障本身产生的不确定性和随机性，第二就是各种故障本身场景组合的不确定性。
　　我们可以回顾下传统大型业务系统在建设完成上线后的一些情况。
　　即当一个业务系统上线后，往往会持续系统内存溢出宕机，磁盘存储故障，中间件内存溢出，系统功能响应缓慢等各种情况。
　　而对于系统开发者来说往往处于一种被动的状态，即都是在整个系统出现了可靠性问题，或者严重的性能问题后，开发或运维人员才发现被动的进行处理，最后才发现在整个IT架构设计上有问题，或者程序代码需要优化等。
　　这些问题在测试阶段由于无法真实模拟生产并没有被观测到。那么我们为何不能在业务系统上线后，自己来模拟制造类似的故障提前发现这些问题，以便对系统及早地进行优化和改进呢？
　　实际上可以看到混沌工程的核心正是要来解决这个问题。
　　在传统的单体应用和非云化阶段，实际上整个IT基础设施部署架构，应用的逻辑架构，应用之间的接口交互等都相对简单，也更加容易进行测试和模拟验证。但是到了云原生和微服务阶段，分布式架构成为了主流。
　　一个微服务要运行起来，除了自身的中间件容器能力支撑外，还需要调用云平台的消息，缓存等各种技术服务能力，同时还需要和其它微服务模块协同。整个分布式架构下的集成和交互复杂度远远超过传统的单体应用。
　　如果要靠人工去进行各种故障模拟和演练，工作量巨大。而且还难以做到各种场景的完全覆盖。各种组合场景的验证等。
　　因此到了云原生和分布式架构阶段，混沌工程就更加重要。系统稳定性和可观测性
　　前面对混沌工程一些核心要素做了说明，那么对于在生产环境下执行各种故障模拟和演练，对系统高可用性和稳定性的验证究竟应该包括哪些内容。
　　注意生产环境的混沌工程一定不会再去模拟各种业务用户并发访问需求，而是直接使用真实的生产环境用户并发访问请求。
　　那么我们如何来验证不同并发场景下的系统稳定性呢?
　　类似一个电商平台，你完全可以在平日，周末或退出秒杀活动的各种场景来进行混沌工程模拟，自然就代表了不同的真实业务场景。
　　节点故障的模拟我们究竟需要观测哪些内容？
　　其一是需要观察节点出现故障后系统的稳定性，比如当我们对集群中的某个节点进行故障处理的时候，基于高可用性架构，这个时候不应该对用户业务访问有任何影响，即这种节点故障用户完全不应该有感知。这是基础的内部冗余要求。
　　其二是观察多节点出现故障后整个系统的容错能力，这个容错能力简单来说就是如何最大限度地对外提供服务。一个集群10个节点，如果8个节点都出现故障，那么这个时候整个系统的应用究竟应该如何？
　　因此真正只有2节点提供能力，那么2个节点承担的并发量急剧增加，如果没有进一步的跟进措施只能够使整个应用系统完全宕机。因此在这个时候需要需要的是基于SLA策略保证高优先级的SLA服务能力。
　　应用对外提供的服务实际可以划分为 功能+用户 两个维度。
　　当需要进行服务降级的时候你就需要考虑如何降级，是影响全部用户还是部分用户，是影响全部功能还是部分查询功能，这些都必须有明确的SLA设计规则。
　　其三是观测节点故障的可恢复性，即在模拟节点故障一段时间后，对节点重新进行恢复，这时候需要观察节点恢复后是否能够正常的挂接如集群中，如果是类似数据库等节点，还需要观察节点恢复后数据或状态能否正常的进行同步，最终达到集群中所有节点的数据和状态的一致性。
　　所以整个混沌工程的故障模拟实际本身又是一个系统工程。
　　这个模拟过程既是随机和不确定性的，同时又需要考虑多节点故障的组合，节点本身如何恢复。在大型的项目中，还需要故障爆炸半径，不能说是故障出现影响到所有资源，所有用户，那么这种故障模拟代价巨大。混沌工程开源项目
　　2018年，混沌工程（Chaos Engineering）成为CNCF的一个新的技术领域。
　　对于混沌工程部分CNCF基金会将其纳入到可观测性部分。在2020年8月完成了可观测性技术调查，最终用户社区的成员被问及他们评估、试验并随后采纳了哪些可观察性解决方案。对283个数据点进行排序和复查，确定最终位置。
　　PingCAP 团队-Chaos Mesh
　　云原生计算基金会 (CNCF) 宣布云原生的混沌工程 Chaos Mesh 正式进入 CNCF 沙箱托管项目，这是 CNCF 接纳的第二个由 PingCAP 团队设计并研发的项目。
　　Chaos Mesh 是一个云原生的混沌工程（Chaos Engineering）平台，可在 Kubernetes 环境中进行混沌测试，在各种复杂的环境下可使用混沌工程来保证系统能正常稳定运行。现阶段，组成部分包括：Chaos Operator：混沌编排的核心组件 —— 完全开源；
　　Chaos Dashboard：用于管理、设计、监控混沌实验的 Web UI —— 开发中。
　　可以看到到这个项目更多的是基于DB层面的。
　　阿里开源-ChaosBlade（该部分来自阿里开源资料摘录）
　　ChaosBlade 是阿里巴巴开源的一款遵循混沌实验模型的混沌实验执行工具，具有场景丰富度高、简单易用等特点，而且可以很方便地扩展实验场景，开源后不久就被加入到 CNCF Landspace 中，成为主流的一款混沌工具。
　　该实验工具支持 3 大系统平台，4 种编程语言应用，共涉及 200 多个实验场景，3000 多个实验参数，可以精细化地控制实验范围。混沌工程平台 chaosblade-box 支持实验工具托管，除已托管 chaosblade 外，还支持 Litmuschaos 实验工具。
　　目前支持的实验场景如下：基础资源场景：CPU 负载、内存占用、磁盘 IO 负载、磁盘占用、网络延迟、网络丢包、网络屏蔽、域名不可访问、shell 脚本篡改、杀进程、进程 Hang、机器重启等； 应用服务场景：支持 Java 应用和 C++ 应用内的实验场景。Java 的场景组件丰富，例如支持 Dubbo、RocketMQ、HttpClient、Servlet、Druid等，而且支持编写 Java 或 Groovy 脚本实现复杂的实验场景； 容器服务场景：支持 Kubernetes 和 Docker 服务，包含 node、pod 和 container 三种资源的实验场景，例如 Pod 网络延迟、丢包等。
　　混沌实验模型
　　该模型分四次，层层递进，很清晰地表达出对什么组件做实验，实验范围是什么，实验触发的匹配规则有哪些，执行什么实验。该模型简洁、通用，语言领域无关、易于实现。阿里集团内的 C++、NodeJS、Dart 应用以及容器平台的实验场景都基于此模型实现。此模型具有很重要的意义，依据此模型可以更精准地描述、更好地理解、更方便沉淀实验场景以及发掘更多的场景。依据此模型实现的工具更加规范、简洁，我们具体看下 ChaosBlade 基于此模型的架构设计。
　　架构设计
　　通过控制台页面可实现 chaosblade、litmuschaos 等已托管工具自动化部署，按照社区建立的混沌实验模型统一实验场景，根据主机、Kubernetes、应用来划分目标资源，通过目标管理器来控制，在实验创建页面，可以实现白屏化的目标资源选择。平台通过调用混沌实验执行来执行不同工具的实验场景，配合接入 prometheus 监控，可以观察实验 metric 指标，后续会提供丰富的实验报告。
　　ChaosBlade 支持目前主流的故障注入场景，相对其他几个故障注入工具，ChaosBlade 故障注入覆盖的场景最全，支持四大类、几十种常用的故障注入能力，并且提供了统一的 CLI 交互界面，学习成本相对较低，其技术栈与我行分布式体系和云计算体系兼容性也较好。总结
　　可以看到云原生下的分布式架构复杂度，引入混沌工程是一个必然趋势，就像我在前面谈云原生和微服务的时候谈到，引入ServiceMesh来进行微服务治理也是必然趋势。
　　混沌工程当前是一个蓬勃发展的技术领域，也越来越受到重视。也是当前应对分布式架构复杂度下提出的一套切实可行，严谨的工程实践原则，方法和工具。混沌工程基于反脆弱的思想，模拟故障只是手段，而核心目标仍然是提升系统的稳定性和可观测性，及早地发现各种风险，并进行优化解决。
　　任何一个生产的业务系统，都不应该是出现故障后的问题驱动，而应该是主动发现，主动防御的风险驱动机制。这就是混沌工程在云原生架构下的巨大价值和作用。