1. 什么是混沌工程
1.1 混沌工程的开始
2014年，Netflix团队创建了一种新的角色，叫作混沌工程师（Chaos Enigneer），并开始向工程社区推广。项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。
多元化的业务场景、规模化的服务节点及高度复杂的系统架构，每天都会遇到各式各样的故障。这些故障信息就是最真实的混沌工程变量。为了能够更体感、有效率地描述故障，优先分析了P1和P2的故障，提出一些通用的故障场景并按照IaaS层、PaaS层、SaaS层的角度绘制了故障画像。
1.2. 混沌工程是什么
根据 Netflix 的解释，混沌工程师通过应用一些经验探索的原则，来学习观察系统是如何反应的。这就跟科学家做实验去学习物理定律一样，混沌工程师通过做实验去了解系统。
上图就是混沌工程的典型代表 - 猴子。拜 Netflix 所赐，现在大部分的混沌工程项目都叫做 Monkey，也就是一只讨厌的猴子，在你的系统里面上蹦下窜，不停捣乱，直到搞挂你的系统。
然后，我们需要知道，为什么需要混沌工程。应用混沌工程能提升整个系统的弹性。通过设计并且进行混沌实验，我们可以了解到系统脆弱的一面，在还没出现对用户造成伤害之前，我们就能主动发现这些问题。
“在分布式系统上进行实验的学科，目的是建立对系统承受生产环境中湍流条件能力的信心。
Chaos Engineering is the discipline of experimenting on a systemin order to build confidence in the system’s capabilityto withstand turbulent conditions in production.
1.3 混沌工程师和测试工程师区别
混沌工程其实是很重要的，但我之前一直以为混沌工程就是测试，但它们还是有区别的。虽然混沌工程跟传统测试通常都会共用很多测试工具的，譬如都会使用错误注入工具，但混沌工程是通过实践对系统有更新的认知，而传统测试则是使用特定方式对某一块进行特定测试。譬如在传统测试里面，我们可以写一个断言，我们给定特定的条件，产生一个特定的输出，如果不满足断言条件，测试就出错了，这个其实是具有很明确的特性。但混沌工程是试验，而试验会有怎样的新信息生成，我们是不确定的。譬如我们可以进行下面的这些试验：
- 模拟整个 IDC 当掉
- 选择一部分网络连连接注入特定时间的延迟
- 随机让一些函数抛出异常
- 强制 NTP 时间不同步
- 生成 IO 错误
- 榨干 CPU
这些试验到底会有什么样的结果，有些我们可以预料，但有些可能我们就不会预先知道，只有发生了，才会恍然大悟，有一种『喔，这也会出现！』的感叹。
2. 开源混沌工程
2012年，Netflix开源了Chaos Monkey。
项目地址：https://github.com/Netflix/chaosmonkey
2021年，阿里巴巴开源了ChaosBlade。
项目地址：https://github.com/chaosblade-io/chaosblade
其他开源工具及对比：
3. 阿里混沌工程试用
3.1 创建应用
- 点击右侧 图标，切换到远程桌面操作界面。
- 双击打开虚拟桌面的Firefox ESR浏览器，在RAM用户登录框中点击“下一步”，复制云产品资源列表中子用户密码，粘按CTRL+V把密码粘贴到密码输区，登陆子账户（后续在远程桌面里的粘贴操作均使用CTRL + V快捷键）。
- 复制容器服务ACK控制台地址，在FireFox浏览器打开新页签，粘贴并访问容器服务ACK控制台。
https://cs.console.aliyun.com/
- 在集群页面，单击详情。
- 在左侧导航栏，单击无状态。
- 在无状态页面，单击使用YAML创建资源。
- 在创建页面，复制以下代码并粘贴到模板框中，然后单击创建。
apiVersion: apps/v1 kind: Deployment metadata: name: nacos-server-app spec: selector: matchLabels: app: nacos-server-app template: metadata: labels: app: nacos-server-app spec: containers: - name: nacos-standalone image: registry.cn-beijing.aliyuncs.com/ahas_demo/nacos:1.0.0 ports: - containerPort: 8848 env: - name: PREFER_HOST_MODE value: "hostname" - name: MODE value: "standalone" resources: limits: cpu: 1 memory: 2048Mi requests: cpu: 200m memory: 512Mi --- apiVersion: v1 kind: Service metadata: name: nacos-server-app spec: type: ClusterIP selector: app: nacos-server-app ports: - name: http port: 8848 targetPort: 8848 --- apiVersion: apps/v1 kind: Deployment metadata: name: cart-redis spec: selector: matchLabels: app: cart-redis replicas: 1 template: metadata: labels: app: cart-redis spec: containers: - name: cart-redis image: redis:alpine imagePullPolicy: IfNotPresent ports: - containerPort: 6379 resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: v1 kind: Service metadata: labels: app: cart-redis name: cart-redis spec: ports: - port: 6379 targetPort: 6379 selector: app: cart-redis --- apiVersion: apps/v1 kind: Deployment metadata: name: cartservice-app spec: selector: matchLabels: app: cartservice-app template: metadata: labels: app: cartservice-app spec: containers: - name: cartservice-app image: registry.cn-beijing.aliyuncs.com/ahas_demo/cartservice:1.0.0 imagePullPolicy: Always env: - name: dubbo.registry.address value: "nacos://nacos-server-app:8848" - name: spring.cloud.nacos.discovery.server-addr value: "nacos-server-app:8848" - name: spring.cloud.nacos.config.server-addr value: "nacos-server-app:8848" resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: apps/v1 kind: Deployment metadata: name: recommendation-service spec: selector: matchLabels: app: recommendation-service template: metadata: labels: app: recommendation-service version: 1.0.0-SNAPSHOT spec: containers: - name: recommendation-service image: registry.cn-beijing.aliyuncs.com/ahas_demo/recomendationservice:1.0.0 # imagePullPolicy: Always env: - name: dubbo.registry.address value: "nacos://nacos-server-app:8848" - name: spring.cloud.nacos.discovery.server-addr value: "nacos-server-app:8848" - name: spring.cloud.nacos.config.server-addr value: "nacos-server-app:8848" resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: apps/v1 kind: Deployment metadata: name: product-mysql spec: selector: matchLabels: app: product-mysql replicas: 1 strategy: type: Recreate template: metadata: labels: app: product-mysql spec: containers: - args: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci env: - name: MYSQL_DATABASE value: product - name: MYSQL_ROOT_PASSWORD value: productservice image: mysql:5.6 name: product-mysql ports: - containerPort: 3306 resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: v1 kind: Service metadata: labels: app: product-mysql name: product-mysql spec: ports: - port: 3306 targetPort: 3306 selector: app: product-mysql --- apiVersion: apps/v1 kind: Deployment metadata: name: product-service spec: selector: matchLabels: app: product-service template: metadata: labels: app: product-service version: 1.0.0-SNAPSHOT spec: containers: - name: product-service image: registry.cn-beijing.aliyuncs.com/ahas_demo/productservice:1.0.0 imagePullPolicy: Always env: - name: dubbo.registry.address value: "nacos://nacos-server-app:8848" - name: spring.cloud.nacos.discovery.server-addr value: "nacos-server-app:8848" - name: spring.cloud.nacos.config.server-addr value: "nacos-server-app:8848" resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: apps/v1 kind: Deployment metadata: name: checkout-mysql spec: selector: matchLabels: app: checkout-mysql replicas: 1 strategy: type: Recreate template: metadata: labels: app: checkout-mysql spec: containers: - args: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci env: - name: MYSQL_DATABASE value: checkout - name: MYSQL_ROOT_PASSWORD value: checkoutservice image: mysql:5.6 name: checkout-mysql ports: - containerPort: 3306 resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi --- apiVersion: v1 kind: Service metadata: labels: app: checkout-mysql name: checkout-mysql spec: ports: - port: 3306 targetPort: 3306 selector: app: checkout-mysql --- apiVersion: apps/v1 kind: Deployment metadata: name: checkout-service spec: selector: matchLabels: app: checkout-service template: metadata: labels: app: checkout-service spec: containers: - name: checkout-service image: registry.cn-beijing.aliyuncs.com/ahas_demo/checkoutservice:health imagePullPolicy: Always ports: - name: liveness-port containerPort: 8080 protocol: TCP env: - name: dubbo.registry.address value: "nacos://nacos-server-app:8848" - name: spring.cloud.nacos.discovery.server-addr value: "nacos-server-app:8848" - name: spring.cloud.nacos.config.server-addr value: "nacos-server-app:8848" resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi livenessProbe: failureThreshold: 3 httpGet: path: /health port: liveness-port scheme: HTTP initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 startupProbe: failureThreshold: 3 httpGet: path: /health port: liveness-port scheme: HTTP initialDelaySeconds: 40 periodSeconds: 5 successThreshold: 1 --- apiVersion: apps/v1 kind: Deployment metadata: name: front-end spec: selector: matchLabels: app: front-end template: metadata: labels: app: front-end spec: containers: - name: front-end image: registry.cn-beijing.aliyuncs.com/ahas_demo/frontend:async-test imagePullPolicy: Always ports: - name: liveness-port containerPort: 8080 protocol: TCP env: - name: dubbo.registry.address value: "nacos://nacos-server-app:8848" - name: spring.cloud.nacos.discovery.server-addr value: "nacos-server-app:8848" - name: spring.cloud.nacos.config.server-addr value: "nacos-server-app:8848" resources: limits: cpu: 1 memory: 512Mi requests: cpu: 200m memory: 128Mi livenessProbe: failureThreshold: 3 httpGet: path: /health port: liveness-port scheme: HTTP initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 startupProbe: failureThreshold: 3 httpGet: path: /health port: liveness-port scheme: HTTP initialDelaySeconds: 60 periodSeconds: 5 successThreshold: 1 --- apiVersion: v1 kind: Service metadata: name: front-end spec: type: ClusterIP selector: app: front-end ports: - name: http port: 8080 targetPort: 8080 --- apiVersion: v1 kind: Service metadata: name: frontend-external spec: type: LoadBalancer selector: app: front-end ports: - name: http port: 8080 targetPort: 8080
- 在左侧导航栏，单击无状态。
- 在无状态页面，等待几分钟，单击刷新，容器组数量全部为1/1之后，表示应用部署完成。
注意 ：
如果出现某服务无法正常启动的情况，您只需单击目标服务右侧操作列表下的更多>重新部署即可。如果遇到frontend无法正常启动的情况，此时您需要先将checkoutservice重新部署后，再将frontend重新部署即可。
- 在无状态页面，单击frontend。
- 在frontend服务页面，单击访问方式页签。
- 在frontend服务的访问方式页签，单击frontend-external服务的外部端点。
若返回如下页面，表示应用部署成功。
- 在商品概览页面，单击任意商品，例如Air Jordan Legacy 312。
- 在商品详情页面，单击添加购物车。
- 在购物车页面，单击确认订单。
若返回如下页面，表示订单支付成功。
3.2 安装探针
- 回到容器服务控制台页面，单击左侧导航栏上方的 图标。
- 在集群列表页面的左侧导航栏中，单击应用目录。
- 在应用目录页面，单击ack-ahas-pilot。
- 在ack-ahas-pilot的详情页面，单击创建。
返回如下页面，表示探针已经部署完成。
3.3 通过架构感知查看系统整体架构
- 复制应用高可用服务控制台地址，在Firefox浏览器打开新页签，粘贴并访问容器服务应用高可用服务控制台。
https://chaos.console.aliyun.com/
- 在概览页面顶部，选择资源所在地域。例如下图中，地域切换为华东1（杭州）。
- 在左侧导航栏，单击故障演练>架构感知。
- 在架构地图页面，单击Kubernetes监控视图卡片中的查看视图。
- 在架构地图页面，打开Kubernetes监控视图下拉列表，选择命令空间为default，然后单击确定即可查看实验资源的Kubernetes监控视图。
3.4 自动恢复场景演练
在分布式系统设计中有一种容错策略是故障恢复（failback），通过健康检查等机制，能在机器或者应用出现问题时自动的进行重新部署。我们利用Chaos进行故障演练，测试我们的系统是否具有这样的能力
- 进行稳态假设。定义一个稳态指标，来评估系统的健康状态并且在实施混沌过程当中进行监控和处理。
我们将稳态定义为 能访问我们的frontend界面，并正常使用各种购物车、下单等功能。
- 模拟真实事件。
2.1 切换回应用高可用服务控制台。在左侧导航栏中，单击我的空间。
2.2 在演练场景页面，单击JAVA应用并选择容器内Java延迟，然后单击创建演练。
2.3 在演练配置页面，完成以下操作：
（1）设置演练名称。
（2）在演练对象配置向导中，演练应用选择frontend，应用分组选择frontend-group，机器列表选择任意一台机器，单击添加演练内容。
（3）在演练配置页面，单击容器内Java延迟。
（4）在容器内Java延迟面板中，依次输入类的全限定名、方法名、进程关键字和目标容器名称，单击关闭。
- 类的全限定名：输入com.alibabacloud.hipstershop.web.HealthController。
- 方法名：输入health。
- 进程关键字：输入java。
- 目标容器名称：选择frontend。
（5）在演练内容区域中，单击保存。
（6）单击下一步。
（7）在全局配置的监控策略区域，单击新增策略。
（8）在新增策略对话框中，选择业务监控>业务状态观察（Http），单击确定。
（9）在业务状态观察（Http）面板中，请求类型选择get，URL输入http:///。
说明 ：
frontend的外部端点在容器服务ACK控制台frontend服务的访问方式页签中获取。
（10）在全局配置配置向导中，单击下一步。
（11）在成功对话框中，单击演练详情。
2.4 在演练详情页面，单击演练。
2.5 在开始执行演练对话框中，单击确认。
- 检测实验影响。
3.1 在演练记录详情页面，查看业务状态观测（Http）时序图。您可以看到health接口的调用在遇到故障之后，先降低，然后马上自动恢复至正常状态，说明我们的设计奏效了。
3.2 切换回容器服务ACK控制台，在frontend服务页面，单击事件页签。
您可以看到frontend自动的进行了扩容。
- 终止实验。
4.1 切换回应用高可用服务控制台。在演练记录详情页面中，单击终止。
4.2 在停止演练对话框中，单击确定。
4.3 等待演练场景终止之后，在结果反馈对话框中，单击确定。
3.5 强弱依赖场景演练
在微服务架构中，各个服务之间存在许多依赖关系。但是当一个不重要的弱依赖宕机时，一个健壮的系统应该仍然能够正常的运行。我们利用Chaos进行故障演练，测试我们的系统处理强弱依赖的能力如何。
- 进行稳态假设。
1.1 切换回容器服务ACK控制台，单击frontend的外部端点。
1.2 在Hipster Shop页面，多次刷新页面。您可以看到页面商品的排序每一次都不一样。您可以理解为商品推荐服务会根据个性化进行推荐，使产品存在优先级。因此我们将稳态定义为，每次刷新页面，商品的排序不同。
- 模拟真实事件。
2.1 切换回应用高可用服务控制台。在左侧导航栏，单击我的空间。
2.2 在演练场景页面，单击JAVA应用并选择容器内Java延迟，然后单击创建演练。
2.3 在演练配置页面，完成以下操作：
（1）设置演练名称。
（2）在演练对象配置向导中，演练应用选择recommendationservice，应用分组选择recommendationservice-group，机器列表选择机器，单击添加演练内容。
（3）在演练内容区域中，单击容器内Java延迟。
（4）在容器内Java延迟面板中，依次输入类的全限定名、方法名、进程关键字和目标容器名称，单击关闭。
- 类的全限定名：输入com.alibabacloud.hipstershop.recomendationservice.service.RecommendationServiceImpl。
- 方法名：输入sortProduct。
- 进程关键字：输入java。
- 目标容器名称：选择recommendationservice。
（5）在演练对象中，单击保存。
（6）单击下一步。
（7）在全局配置中，单击下一步。
（8）在成功对话框中，单击演练详情。
2.4 在演练详情页面，单击演练。
2.5 在开始执行演练对话框中，单击确认。
- 检测实验影响。
3.1 切换回容器服务ACK控制台。在无状态页面，单击frontend。
3.2 在frontend页面，单击访问方式页签，然后单击frontend的外部端点。
3.3 在Hipster Shop页面，多次刷新页面。您可以发现每次刷新，产品顺序不会改变。说明推荐服务宕机，但并没有影响别的服务。
- 终止实验。
4.1 切换至应用高可用服务控制台，在演练记录详情页面，单击终止。
4.2 在停止演练对话框中，单击确定。
4.3 在结果反馈对话框中，单击确定。
3.6. 失败重试场景演练
在微服务架构中，一个大系统被拆分成多个小服务，小服务之间存在大量RPC调用，经常可能因为网络抖动等原因导致RPC调用失败，这时候使用重试机制可以提高请求的最终成功率，减少故障影响，让系统运行更稳定。我们通过利用Chaos，给系统注入失败，看看系统失败重试的性能如何。
- 进行稳态假设。
1.1 切换回容器服务ACK控制台，在无状态页面，单击cartservice。
1.2 在cartservice页面，单击伸缩。
1.3 在伸缩对话框中，将所需容器组数量更改为2，单击确定。
待状态变为Running，表示容器组扩容成功。
1.4 切换至Hispter Shop页面，单击购物车。
返回如下页面，表示购物车服务正常。因此我们将稳态定义为，能够正常使用frontend的购物车功能。
- 模拟真实事件。
2.1 切换回应用高可用服务控制台，在左侧导航栏，单击我的空间。
2.2 在我的空间页面，在新建演练下拉列表中单击新建空白演练。
2.3 在演练配置页面，完成以下操作：
（1）设置演练名称。
（2）在演练对象中，演练应用选择cartservice，应用分组选择cartservice-group，机器列表选择任意一台机器，单击添加演练内容。
（3）在选择演练故障对话框中， 选择JAVA应用>抛异常>容器内Java延迟抛出自定义异常，单击确定。
（4）在演练内容区域中，单击容器内Java延迟抛出自定义异常。
（5）在容器内Java延迟抛出自定义异常面板中，依次输入方法名、类的全限定名、异常、进程关键字和目标容器名称，单击关闭。
- 方法名：输入viewCart。
- 类的全限定名：输入com.alibabacloud.hipstershop.cartserviceprovider.service.CartServiceImpl。
- 异常：输入java.lang.Exception。
- 进程关键字：输入java。
- 目标容器名称：选择cartservice。
（6）在演练对象中，单击保存。
（7）单击下一步。
（8）在全局配置中，单击下一步。
（9）在成功对话框中，单击演练详情。
2.4 在演练详情页面，单击演练。
2.5 在开始执行演练对话框中，单击确认。
- 检测实验影响。
3.1 切换至Hispter Shop页面，单击购物车。
返回如下页面，您发现无法访问购物车。这是因为流量并没有切换到没有宕机的那台机器，同时 说明我们的系统并没有失败重试的能力，或者是一开始就没有设计，或者是没有生效。通过这次故障注入，我们发现了系统的缺陷。
3.2 切换至应用高可用服务控制台，在演练记录详情页面，单击终止。
3.3 在停止演练对话框中，单击确定。
3.4 在结果反馈对话框中，单击确定。
返回如下页面，表示演练结束。
3.7. 微服务演练
在体验了上述三个场景演练之后，我们对混沌工程有了初步的了解，也掌握了应用高可用服务的基本功能。但是这样手动部署参数的过程还是比较繁琐的。接下来我们体验一下更为方便快捷的强弱依赖治理。
- 切换至应用高可用服务控制台。在左侧导航栏中，单击微服务演练。
并选择强弱依赖治理页面。
- 在强弱依赖治理页面中，单击创建治理方案。
- 在创建治理方案的配置向导页面，完成以下操作。
3.1 在应用接入中，自定义方案名称，治理应用选择frontend，单击下一步。
3.2 在强弱依赖治理以30天为治理周期对话框中，单击确认。
3.3 在依赖分析中，等待分析完成，单击下一步。
3.4 在依赖预判中，自行选择依赖对象的强弱依赖预判，例如nacos-standalone和checkoutservice的强弱依赖预判可选择强依赖，其他依赖对象默认弱依赖，然后单击下一步。
3.5 在依赖验证中，选择任意用例进行验证。例如选择frontend与nacos-standalone强弱依赖验证用例，单击去验证。
3.6 在去验证前的参数确认对话框中，单击确定验证。
注意：
如果窗口没有跳转，请注意跳转是否被拦截，请手动解除
- 在演练详情页面中，单击演练。
- 在开始执行演练对话框中，单击确认。
- 切换至Hipster Shop页面，单击网页的任意功能。您可以发现Hipster Shop网页和相关功能均可以正常访问，说明frontend服务与nacos-standalone服务是弱依赖关系。
- 切换至应用高可用服务控制台，在演练记录详情页面，单击终止。
- 在停止演练对话框中，单击确定。
- 在结果反馈对话框中，结论选择不符合预期，验证结果选择弱依赖，单击确定，返回强弱依赖治理。
- 在依赖验证中，您可以验证其他用例，验证完成后，单击方案归档。
- 在您确定要归档此方案吗对话框中，单击确认归档。
返回如下页面，表示归档完毕。
您还可以通过使用MSHA快速体验异地、同城多活容灾。动手实验室地址：https://developer.aliyun.com/adc/scenario/998a993afe624e3eadcf5f8f6b791064
参考：
混沌工程(Chaos Engineering) 到底是什么? - 云+社区 - 腾讯云 (tencent.com)
浩鲸科技基于ChaosBlade的混沌工程实践 (qq.com)
