微服务的概念
任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。 —— 康威定律
微服务是一种研发模式。换句话理解上面这句康威定律，就是说 一旦企业决定采用微服务架构，就必须在组织架构、管理策略、研发模式、测试、运维等领域都做出相应的调整，为微服务架构的落地创造合适的“土壤”。
微服务架构的特点：
- 高内聚、低耦合
- 独享资源
- 同构还是异构
- 架构治理 （服务架构中的架构腐化的表现）
（1）单点依赖： 这类服务一旦出现问题，会导致服务应用出现大面积的故障
（2）循环调用：服务A调用服务B，B调用C，C在特定条件下又调用A，这样A->B->C->A就形成了循环调用，就构成了一个隐患，这种循环关系被触发，就会导致业务异常
（3）服务冗余
**如何发现和看到以上的架构问题，2种典型的手段：
- 静态代码调用链路分析
- 动态线上调用依赖关系分析**
服务质量
6. 服务开发质量度量
7. 服务测试质量度量
8. 服务运维质量度量
9. 服务线上性能度量
服务管控
- 服务的内部管控
- 服务生命周期管理
通过服务质量度量提供治理依据
微服务基础的度量指标：
- 调用量
- 调用延时
- 异常
通过服务管控实现治理闭环
如何有针对性地进行服务的管控？
服务线上稳定性保障
1、应急预案
Google的公开经验，“通过实现预案并且将最佳方法记录在‘运维手册（palybook）’上通常可以使MTTR （故障平均恢复时间）降低3倍以上”
2、故障演练
（1）故障演练的目的
- 验证应急预案的有效性
- 锻炼研发的操作能力和危机意识
【最终目标】 建立一套有效的紧急故障管理流程，协调故障发生时的人（相关干系人，包含业务、运营、开发）、事（应对策略、事项）、物（故障主体、环境），以控制故障的影响并迅速恢复运营。
（2）一个可实施的故障预案建设流程
（3）演练场景
- 基础资源类场景
场景 | 详细 | 目标 |
CPU类场景 | 1.CPU使用率负载 2.指定使用率满载 | 让CPU在特定负载下，验证服务质量、监控告警、流量调度、弹性伸缩等能力 |
网络类场景 | 1网络延迟 2.网络丢包 3.篡改域名解析 | 网络故障是时常会遇到的问题，需要提升系统在网络异常下的容错能力 |
- java
场景 |
虚拟机场景 |
代码逻辑场景 |
java注入动态脚本 |
- k8s场景
场景 |
node |
pod |
container |
- 其他
场景 |
服务依赖-强弱依赖演练 |
可观测性演练 |
故障恢复模式演练 |
（4）演练阶段
3、混沌工程
什么是混沌工程？
一门相对高级的系统稳定性治理方法论，提倡采用探索式的研究实验，发现生产环境中的各种风险，让人们建立对于复杂分布式系统在生产中抵御突发事件能力的信心。
混沌工程的本质
在不影响正常业务的前提下，在生产环境中有意识地注入一些异常和故障，探索系统潜在的脆弱点，并对这些脆弱点进行改进，从而增强系统的韧性，提高人们对系统健壮性的自信心的行为。
混沌工程的核心
混沌工程评估模型
（1）Netflix制定的混沌工程成熟度评估模型
（2）Netflix混沌工程实验的接纳指数
开展混沌工程的前提
不影响正常业务 & 线上系统具备完善的可观察性
混沌工程落地策略
（1）制定风险清单，确定实验项目 ：梳理业务相关链路
（2）确定实验指标：
比如“当Redis缓存服务出现故障时，服务保持正常”这个预期，就必须定义Redis缓存服务的故障标准是什么，以及服务正常的定义是什么。
（3）充分做好实验准备工作
根据实验项目清单制定尽可能完善的实验步骤计划及预案保障计划；准备实验数据；通知相关系统干系人，让核心岗位人员就绪，同时让业务人员提前知晓，防止造成不必要的恐慌。
（4）由点及面，逐步扩大实验范围
（5）实验后复盘
