微服务治理-含服务线上稳定性保障建设治理

微服务的概念

任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。 —— 康威定律

微服务是一种研发模式。换句话理解上面这句康威定律，就是说 一旦企业决定采用微服务架构，就必须在组织架构、管理策略、研发模式、测试、运维等领域都做出相应的调整，为微服务架构的落地创造合适的“土壤”。

微服务架构的特点：

1. 高内聚、低耦合
2. 独享资源
3. 同构还是异构
4. 架构治理 （服务架构中的架构腐化的表现）
   （1）单点依赖： 这类服务一旦出现问题，会导致服务应用出现大面积的故障
   （2）循环调用：服务A调用服务B，B调用C，C在特定条件下又调用A，这样A->B->C->A就形成了循环调用，就构成了一个隐患，这种循环关系被触发，就会导致业务异常
   （3）服务冗余

**如何发现和看到以上的架构问题，2种典型的手段：

1. 静态代码调用链路分析
2. 动态线上调用依赖关系分析**

服务质量
6. 服务开发质量度量
7. 服务测试质量度量
8. 服务运维质量度量
9. 服务线上性能度量

服务管控

1. 服务的内部管控
2. 服务生命周期管理

通过服务质量度量提供治理依据

微服务基础的度量指标：

1. 调用量
2. 调用延时
3. 异常

通过服务管控实现治理闭环

如何有针对性地进行服务的管控？

• 服务限流 （单点限流、集群限流）
• 服务集群容错
• 服务降级
• 服务降权

服务线上稳定性保障

1、应急预案

Google的公开经验，“通过实现预案并且将最佳方法记录在‘运维手册（palybook）’上通常可以使MTTR （故障平均恢复时间）降低3倍以上”

2、故障演练

（1）故障演练的目的

1. 验证应急预案的有效性
2. 锻炼研发的操作能力和危机意识

【最终目标】 建立一套有效的紧急故障管理流程，协调故障发生时的人（相关干系人，包含业务、运营、开发）、事（应对策略、事项）、物（故障主体、环境），以控制故障的影响并迅速恢复运营。

（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）实验后复盘