分布式限流、熔断、降级与稳定性治理思维导图模板

🎯 一、认知篇：为什么需要稳定性治理

📖 1.1 分布式系统的脆弱性

单机的时代

所有代码在一个进程里，故障影响范围有限

一个模块挂了，整个应用挂，但范围可控

分布式的时代

一个请求跨几十个服务、上百台机器

任何一个环节都可能出问题：网络抖动、节点宕机、依赖变慢

故障会沿着调用链【级联传播】

级联故障（雪崩效应）

例：订单服务依赖库存服务

库存服务变慢 → 订单服务的线程都在等库存 → 订单服务线程池耗尽

订单服务也变慢 → 依赖订单服务的上层也变慢

最终：一个服务变慢，拖垮整个系统（雪崩）

核心认知：分布式系统的故障是【常态】，不是【意外】

📖 1.2 稳定性治理的目标

核心目标：在故障发生时，尽可能保证核心功能可用

三个层次的目标

第一层：不发生故障（预防）—— 容量、压测、变更管控

第二层：故障时不扩散（止损）—— 限流、熔断、隔离

第三层：故障时保核心（兜底）—— 降级、预案

量化目标

可用性（几个9）

核心接口的成功率

故障恢复时间（MTTR）

🧠 1.3 稳定性治理的核心思想

思想1：为失败做设计（Design for Failure）

假设一切都会失败

提前设计好失败时的应对

思想2：面向失败编程（而非只面向成功）

写代码时不仅考虑"成功路径"，更要考虑"失败路径"

每个外部调用都要想：超时了怎么办？失败了怎么办？

思想3：牺牲局部，保全整体

资源有限时，放弃非核心功能，保证核心功能

例：大促时关闭推荐，保住下单

思想4：快速失败，而非缓慢等待

下游故障时，快速返回失败，而不是傻等

避免线程被拖死

🗺️ 二、稳定性治理的全景框架

📖 2.1 稳定性治理的三个时间维度

事前（预防）

容量规划：评估系统能扛多少

全链路压测：提前发现瓶颈

变更管控：控制发布风险

预案准备：提前制定降级/限流方案

事中（止损）

限流：挡住超量流量

熔断：隔离故障依赖

降级：关闭非核心功能

应急：快速响应、切换预案

事后（改进）

故障复盘：找到根因

改进措施：修复问题、完善预案

沉淀经验：形成知识库

📖 2.2 稳定性治理的分层防护

接入层防护：网关限流、CDN 削峰

应用层防护：接口限流、熔断、降级、隔离

依赖层防护：超时、重试、缓存兜底

数据层防护：读写分离、限流保护数据库

核心认知：层层设防，纵深防御

📖 2.3 稳定性的核心指标（度量）

可用性（Availability）

系统正常运行的时间占比

几个9：99.9%（一年挂8.7小时）、99.99%（一年挂52分钟）

成功率

请求成功的比例

核心接口成功率是稳定性的直接体现

响应时间（RT）

不仅看平均，更要看 P99/P999（长尾）

容量水位

当前流量占系统容量的比例

水位过高是危险的信号

核心认知：无法度量，就无法治理

🚦 三、限流（Rate Limiting）：控制进来的流量 ★核心

📖 3.1 为什么需要限流

问题的本质

系统的处理能力是有限的

当流量超过系统容量时，如果不加控制，系统会被打垮

与其让系统崩溃（所有用户都失败），不如主动拒绝部分请求（部分用户失败）

限流的价值

保护系统：防止流量超过容量，避免雪崩

保护依赖：防止下游被打垮（如保护数据库）

平滑流量：把突刺流量削平

核心思想：宁可拒绝部分请求，也不能让整个系统崩溃

类比：餐厅排队，超过接待能力就不再接客，而不是硬塞导致服务质量崩溃

🎯 3.2 限流的维度（在哪里限、对什么限）

按位置分

网关层限流：在入口统一限流（保护整个系统）

应用层限流：在具体服务/接口限流（精细控制）

接入层限流：在负载均衡/防火墙层面（最粗粒度）

按对象分

总流量限流：限制系统总 QPS

接口限流：限制某个具体接口的 QPS

用户限流：限制单个用户的请求频率（防刷）

参数限流：针对某个参数限流（如某个商品、某个地区）

依赖限流：限制对下游的调用频率（保护下游）

架构师视角

限流要分层：网关做粗粒度，应用做细粒度

限流要有针对性：保护核心链路，限制非核心

🧮 3.3 限流算法详解（重点，必须掌握）

算法1：计数器算法（固定窗口）

原理

在一个固定时间窗口内（如1秒）计数

请求数超过阈值，则拒绝后续请求

窗口结束，计数清零，重新开始

优点：实现极其简单

致命缺点：临界问题（窗口边界突刺）

例：阈值100，第1个窗口最后100毫秒来100个，第2个窗口最初100毫秒又来100个

在200毫秒内通过了200个请求，超过阈值（瞬时2倍）

适用：精度要求不高的简单场景

算法2：滑动窗口算法

原理

把时间窗口细分成多个小格子（如1秒分成10个100毫秒）

窗口随时间滑动，始终统计"最近一段时间"的请求数

优点：解决固定窗口的临界问题，更平滑

缺点：实现稍复杂，需要维护多个格子

应用：Sentinel 默认使用滑动窗口

算法3：漏桶算法（Leaky Bucket）

原理

请求进入一个"桶"（缓冲区）

桶以【固定速率】往外"漏水"（处理请求）

桶满了，新请求被丢弃

优点：输出速率绝对恒定，流量绝对平滑

缺点：无法应对突发流量

即使系统当前很闲、有能力处理，漏桶也按固定速率处理

不适合"允许突发"的场景

适用：需要绝对平滑、保护下游的场景

算法4：令牌桶算法（Token Bucket）

原理

系统以【固定速率】往桶里放令牌

请求到来时，需要从桶里拿一个令牌才能通过

桶里有攒的令牌，可以一次通过多个请求

优点：允许一定程度的突发流量（桶里攒的令牌可一次用）

系统闲时攒令牌，忙时消耗，能应对突发

缺点：实现相对复杂

应用：最常用的限流算法

Guava RateLimiter 就是令牌桶

适合大多数场景

算法对比与选型

需要绝对平滑：漏桶

允许突发流量：令牌桶（推荐）

简单场景：计数器/滑动窗口

核心认知：令牌桶是"性能与平滑"的最佳平衡

🌐 3.4 分布式限流（单机限流的扩展）

为什么需要分布式限流

单机限流：每台机器各自限流

问题：如果有10台机器，每台限100，总限流是1000，不是100

要实现"全局总共限100"，需要分布式限流

实现方案

方案1：单机限流 + 均摊

全局限流值 / 机器数 = 单机限流值

优点：简单，无需中心化

缺点：要求流量均匀分布到各机器，否则不准

方案2：中心化限流（Redis）

用 Redis 统计全局请求数

每次请求都查 Redis 判断是否超限

优点：精确控制全局

缺点：所有请求都访问 Redis，Redis 成为热点和性能瓶颈

方案3：网关集中限流

在网关层统一限流（网关是统一入口）

网关可以维护全局计数

适用：网关限流场景

架构师建议

网关层做全局限流（集中、精确）

应用层做单机限流（兜底、高性能）

两者结合，分层限流

🛠️ 3.5 限流的实践要点

限流后的处理（被拒绝了怎么办）

直接返回错误（提示"系统繁忙"）

排队等待（进入队列，削峰）

降级处理（返回兜底数据）

核心：给用户友好的反馈，而非冷冰冰的错误

限流阈值的设置

基于压测数据：测出系统容量，限流值设为容量的 80%-90%

留有余量：不要设到极限

动态调整：支持运行时调整限流值（不重启）

限流的粒度

不要太粗（一刀切）：核心接口被非核心拖累

不要太细（难维护）：每个接口都配，管理成本高

建议：核心接口精细限流，非核心统一限流

避坑指南

坑1：限流值拍脑袋设置（应基于压测）

坑2：限流后无兜底（用户体验差）

坑3：只限入口不限依赖（下游还是被打垮）

坑4：分布式场景用单机限流（总量失控）

🔌 四、熔断（Circuit Breaker）：控制出去的调用 ★核心

📖 4.1 为什么需要熔断

问题的本质

下游服务故障（变慢、报错）时，如果调用方不断重试/等待

调用方的线程会被拖死（都在等下游响应）

最终调用方也被拖垮，故障级联

熔断的价值

下游故障时，快速失败，不再等待

释放调用方的资源（线程），保护自己

给下游恢复的时间（不再被请求轰炸）

核心思想：像电路的保险丝，电流过大时熔断，保护电路

类比：家里的保险丝，短路时保险丝熔断，切断电路，防止烧毁整个家电

🔄 4.2 熔断的状态机（核心原理）

三种状态

闭合（Closed）：正常状态，请求正常通过

打开（Open）：熔断状态，请求直接失败，不再调用下游

半开（Half-Open）：试探状态，放行少量请求试探下游是否恢复

状态流转

闭合 → 打开：

当失败率达到阈值（如错误率超过50%），熔断器打开

打开 → 半开：

熔断一段时间后（如10秒），进入半开状态

目的：试探下游是否恢复

半开 → 闭合：

试探的请求成功了，说明下游恢复，关闭熔断器

半开 → 打开：

试探的请求还是失败，说明下游还没恢复，继续熔断

核心认知：熔断不是永久的，会周期性试探恢复

📊 4.3 熔断的触发条件（怎么判断该熔断了）

基于错误率

统计一段时间内的失败比例

错误率超过阈值（如50%）则熔断

最常用

基于慢调用比例

统计慢调用（超过某个RT）的比例

慢调用比例超过阈值则熔断

适合"下游没挂但变慢"的场景

基于异常数

统计一段时间内的异常次数

超过阈值则熔断

关键参数

统计窗口：统计多长时间的数据（如10秒）

最小请求数：请求太少时不触发（避免误判）

阈值：错误率/慢调用比例的临界值

熔断时长：熔断持续多久

避坑：最小请求数很重要，否则1个请求失败就熔断（误判）

🧰 4.4 熔断的实现框架

Hystrix（Netflix，已停止维护）

熔断器模式的开创者

线程池隔离 + 熔断

现状：官方不再维护，新项目不建议

Sentinel（阿里，主流）

功能全面：限流、熔断、降级、系统保护

国内主流，与 Spring Cloud Alibaba 集成好

详见第八部分实战

Resilience4j（轻量，函数式）

轻量级，无侵入

适合轻量场景

选型建议

Spring Cloud Alibaba 生态：Sentinel

轻量需求：Resilience4j

🛠️ 4.5 熔断的实践要点

熔断后做什么（降级逻辑）

熔断只是"快速失败"，还需要"降级"来处理失败

例：推荐服务熔断 → 返回默认热门列表

熔断 + 降级 = 完整的容错

熔断的粒度

按接口熔断：某个接口故障，只熔断这个接口

按依赖熔断：某个下游服务故障，熔断对它的调用

建议：细粒度熔断，避免一个接口故障熔断整个服务

避坑指南

坑1：熔断后没有降级（只是报错，用户还是失败）

坑2：熔断阈值设置不合理（太敏感导致误熔断，太迟钝失去作用）

坑3：对所有依赖都熔断（非关键依赖没必要）

坑4：熔断粒度过粗（一个故障全部熔断）

📉 五、降级（Fallback）：提供兜底方案 ★核心

📖 5.1 为什么需要降级

问题的本质

当系统压力大、或依赖故障时，不可能所有功能都正常

资源有限，必须有所取舍

核心：牺牲非核心功能，保证核心功能可用

降级的价值

保护核心链路：把资源留给最重要的功能

提升可用性：即使部分功能降级，系统仍可用

给用户兜底：即使降级，也给用户一个可用的结果

核心思想：丢车保帅，牺牲局部保全整体

类比：飞机遇到紧急情况，抛掉货物保住乘客；停电时优先保障医院供电

🎯 5.2 降级的类型（降级什么）

按功能重要性分

核心功能：绝不降级（如下单、支付）

次核心功能：压力大时降级（如订单详情）

非核心功能：优先降级（如推荐、评论、积分）

按降级方式分

读降级：读操作降级

例：从缓存读降级为返回默认值

例：从实时计算降级为返回缓存的旧数据

写降级：写操作降级

例：同步写降级为异步写（先返回成功，异步处理）

例：写入失败降级为写入日志，后续补偿

功能降级：关闭整个功能

例：关闭推荐功能，返回默认列表

例：关闭评论功能

按降级程度分

完全降级：功能完全关闭

部分降级：功能简化（如返回简化版数据）

延迟降级：非实时操作延迟处理

🔘 5.3 降级的触发方式

自动降级

由系统自动触发

触发条件：熔断触发、错误率超阈值、系统负载过高

优点：响应快，无需人工

缺点：可能误降级

手动降级（开关）

通过配置开关，人工控制降级

场景：大促前主动关闭非核心功能

优点：可控，提前准备

缺点：需要人工操作，响应慢

架构师建议

两者结合：自动降级兜底，手动开关应对大促

降级开关要支持【动态生效】（不重启）

🧩 5.4 降级策略设计（怎么降级）

策略1：返回默认值

例：推荐降级 → 返回默认的热门榜单

适用：有合理的默认值可用

策略2：返回缓存数据

例：实时数据降级 → 返回缓存的旧数据

适用：能接受一定程度的数据滞后

策略3：简化处理

例：复杂计算降级 → 返回简化结果

适用：有简化版逻辑可用

策略4：异步化处理

例：同步发送短信降级 → 写入队列异步发送

适用：能接受延迟

策略5：直接拒绝/提示

例：返回"功能暂时不可用"

适用：无兜底方案时

核心原则：降级也要给用户"可用的体验"，而非报错

🛠️ 5.5 降级的实践要点

降级的分级

提前定义好降级级别（L1/L2/L3）

例：L1 关闭推荐，L2 关闭评论，L3 关闭积分

压力越大，降级级别越高

降级预案

提前梳理：哪些功能可以降级，降级后返回什么

提前开发好降级逻辑

提前演练：验证降级是否生效

大促降级

大促前主动降级非核心功能（手动开关）

释放资源给核心链路（下单、支付）

大促后恢复

避坑指南

坑1：没有降级预案（故障时手忙脚乱）

坑2：降级了核心功能（影响主流程）

坑3：降级后无兜底数据（返回空，体验差）

坑4：降级逻辑没测试过（真要用时不生效）

🧱 六、隔离（Bulkhead）：控制故障的扩散 ★核心

📖 6.1 为什么需要隔离

问题的本质

一个服务调用多个依赖（依赖A、依赖B、依赖C）

如果所有调用共享同一个线程池

依赖A变慢 → 线程都被A占用 → 没有线程处理B、C的调用

一个依赖的故障，拖垮了所有功能

隔离的价值

把不同的依赖/功能隔离开

一个出问题，不影响其他的

把故障控制在局部

核心思想：故障隔离，避免一损俱损

类比：船的舱壁（Bulkhead），一个船舱进水，隔板阻止水蔓延到其他舱，船不会沉

🎯 6.2 隔离的类型

线程池隔离（舱壁模式）

原理：为每个依赖分配独立的线程池

依赖A用线程池A，依赖B用线程池B

A变慢，只占满线程池A，不影响B

优点：隔离彻底

缺点：线程池多，资源开销大，上下文切换开销

代表：Hystrix 默认线程池隔离

信号量隔离

原理：用信号量控制并发数（不创建线程池）

限制对某个依赖的最大并发调用数

超过并发数的请求被拒绝

优点：轻量，无线程切换开销

缺点：不能超时控制（信号量只是限并发）

代表：Sentinel 的信号量隔离

服务分组隔离

原理：按业务/优先级把服务分组部署

核心链路一组，非核心链路一组

非核心挂了不影响核心

适用：重要程度差异大的场景

多机房隔离

原理：不同机房独立部署，故障时切换

属于更高层级的隔离（容灾）

🎯 6.3 隔离的粒度（隔离到什么程度）

按依赖隔离：每个外部依赖一个隔离单元

例：调用用户服务、订单服务、库存服务，各自独立

按业务隔离：按业务功能隔离

例：下单链路、查询链路分开

按优先级隔离：核心和非核心分开

例：核心交易独立部署，营销功能独立部署

架构师权衡

隔离粒度越细，隔离效果越好，但资源开销越大

要根据业务重要性选择隔离粒度

核心依赖重点隔离，非核心可以共享

🛠️ 6.4 隔离的实践要点

线程池参数设置

核心线程数：根据依赖的 RT 和 QPS 计算

队列大小：避免队列过长导致堆积

拒绝策略：满了怎么办（拒绝、降级）

并发数控制

信号量隔离时，设置合理的最大并发数

避免并发过高拖垮下游

避坑指南

坑1：所有依赖共享线程池（一个慢全拖垮）

坑2：隔离粒度过细（资源浪费）

坑3：隔离了但没设超时（线程还是会被拖死）

坑4：线程池队列无界（堆积导致 OOM）

⏱️ 七、超时与重试：稳定性的配套机制

📖 7.1 超时设计（第一道防线）

为什么必须设置超时

远程调用可能卡住（网络问题、下游卡死）

如果不设超时，调用方会无限等待

线程被耗尽，调用方被拖垮

核心原则：所有远程调用必须设置超时

超时时间的设置

太短：正常请求被误判为超时（误杀）

太长：拖慢系统，失去保护意义

建议：基于下游接口的 P99 响应时间设置（如 P99 的 1.5-2 倍）

超时的层次

连接超时：建立连接的超时

读超时：等待响应的超时

两者都要设置

超时传递

调用链的超时控制：上游的剩余时间要大于下游的超时

避免"上游已超时，下游还在执行"

🔁 7.2 重试机制（提升成功率）

为什么需要重试

网络抖动、瞬时故障导致的失败

重试一次可能就成功了

提升整体成功率

重试的前提：幂等

重试可能导致重复执行

只有幂等操作才能重试（如查询、设置值）

非幂等操作（如扣款）重试会导致重复扣款！

核心：非幂等操作不能盲目重试

重试策略

固定间隔重试：每次间隔相同

指数退避（Exponential Backoff）：间隔按 2 的幂次增长（1s→2s→4s→8s）

避免重试风暴

加抖动（Jitter）：在退避基础上加随机值

避免大量请求同时重试

重试次数限制

重试不能无限，设置最大次数（如3次）

超过后放弃，走降级/报错

重试风暴（警惕）

问题：下游故障时，大量请求失败，都触发重试

重试流量放大，进一步压垮下游，形成恶性循环

解决：重试要克制（限次数、加退避），配合熔断

🛠️ 7.3 超时与重试的组合

正确的组合

设置合理超时（快速发现失败）

幂等操作有限重试（提升成功率）

重试失败后熔断/降级（止损）

避坑指南

坑1：不设超时（线程被拖死）

坑2：非幂等操作重试（重复扣款）

坑3：无限重试（重试风暴）

坑4：重试不配合熔断（持续轰炸故障下游）

🛡️ 八、主流框架实战：Sentinel ★落地

📖 8.1 为什么选 Sentinel

Sentinel 是阿里开源的流量治理组件

功能全面：限流、熔断、降级、系统保护

国内主流，与 Spring Cloud Alibaba 深度集成

经过阿里双11验证

🏗️ 8.2 Sentinel 的核心架构

核心概念：资源（Resource）

被保护的代码/接口就是"资源"

可以用注解或 API 定义资源

核心概念：规则（Rule）

定义如何保护资源

流控规则、熔断规则、降级规则、系统规则

工作原理

资源被访问时，Sentinel 拦截

检查是否违反规则（限流、熔断）

违反则拒绝/降级

🚦 8.3 Sentinel 限流实战

定义资源

用 @SentinelResource 注解标记方法

或用 SphU.entry() API 手动定义

配置流控规则

阈值类型：QPS / 并发线程数

流控模式：

直接：直接限制当前资源

关联：当关联资源达到阈值，限制当前资源

链路：只统计指定链路的流量

流控效果：

快速失败：超过直接拒绝

Warm Up：预热（冷启动，缓慢增加阈值）

排队等待：漏桶，匀速处理

限流后的处理（blockHandler）

定义 blockHandler 方法，处理被限流的请求

返回友好提示或兜底数据

🔌 8.4 Sentinel 熔断实战

配置熔断规则

熔断策略：

慢调用比例：慢调用超过比例则熔断

异常比例：异常比例超过阈值则熔断

异常数：异常数超过阈值则熔断

关键参数：统计窗口、最小请求数、熔断时长

熔断后的处理（fallback）

定义 fallback 方法，处理熔断后的调用

返回降级数据

熔断状态查看

通过 Sentinel 控制台查看熔断状态

📉 8.5 Sentinel 降级实战

异常降级：方法抛异常时，走降级逻辑

熔断降级：熔断触发时，走降级逻辑

降级逻辑的实现

fallback 方法：处理业务异常

blockHandler 方法：处理限流/熔断

两者可以分别定义

🖥️ 8.6 Sentinel 控制台与规则持久化

Sentinel 控制台

可视化管理：查看资源、配置规则、监控数据

实时查看 QPS、RT、异常等

规则持久化（生产必备）

默认规则存在内存，重启丢失

生产环境要持久化到配置中心（Nacos、Apollo）

支持动态更新规则（不重启）

集群限流

Sentinel 支持集群流控（Token Server 统一管理）

实现全局精确限流

🔗 8.7 Sentinel 与 Spring Cloud 集成

引入依赖：spring-cloud-starter-alibaba-sentinel

配置：配置 Sentinel 控制台地址、规则持久化

与 OpenFeign 集成：Feign 调用自动接入 Sentinel

与 Gateway 集成：网关接入 Sentinel 做全局限流

🛠️ 8.8 Sentinel 落地避坑

坑1：规则不持久化（重启丢失）

坑2：没有配置降级逻辑（限流/熔断后直接报错）

坑3：阈值拍脑袋设置（应基于压测）

坑4：所有接口一刀切（应区分核心/非核心）

📊 九、稳定性治理体系：从单点到体系

📖 9.1 为什么需要体系化

单个技术（限流/熔断）只能解决局部问题

真正的稳定性需要体系化保障

体系 = 预防 + 发现 + 止损 + 恢复 + 改进

📈 9.2 监控告警（发现问题）

监控的层次

基础设施：CPU、内存、磁盘、网络

应用：QPS、RT、错误率、线程池

依赖：下游调用的成功率、RT

业务：订单量、支付成功率

告警设计

分级告警：紧急（电话）、重要（短信）、一般（IM）

告警收敛：避免告警风暴

告警准确性：减少误报

核心认知：发现问题的速度决定止损的速度

🏋️ 9.3 全链路压测（验证容量）

目的：验证系统能扛多少流量，发现瓶颈

全链路压测

在生产环境模拟真实流量

覆盖完整调用链

压测要点

压测数据隔离（影子表、影子库）

逐步加压，观察各层表现

找出瓶颈点

大促前必做全链路压测

🔥 9.4 混沌工程（主动注入故障）

思想：主动制造故障，验证系统的容错能力

常见故障注入

杀掉服务实例

增加网络延迟/丢包

让某个依赖变慢/报错

目的：验证限流、熔断、降级是否真的生效

核心认知：平时多演练，故障时不慌乱

🚨 9.5 应急预案与故障演练

应急预案

针对各类故障场景，预先制定处理方案

例：数据库挂了怎么办、缓存挂了怎么办、某依赖挂了怎么办

预案要包含：触发条件、操作步骤、责任人

故障演练

定期模拟故障，检验预案有效性

训练团队应急能力

故障复盘

每次故障后复盘

找根因（Root Cause）

制定改进措施

沉淀经验

🎯 9.6 稳定性治理的组织保障

稳定性是"一把手工程"

需要管理层重视和资源投入

建立稳定性文化

不指责文化（Blameless）：复盘对事不对人

鼓励暴露问题

值班与应急机制

7x24 值班

应急响应流程（发现→上报→处理→恢复→复盘）

🏗️ 十、稳定性保障的工程实践

📖 10.1 变更管控（故障的第一大来源）

认知：大部分故障是由变更引起的

变更三板斧：可灰度、可监控、可回滚

可灰度：先小范围发布，验证无问题再扩大

可监控：发布过程中实时监控指标

可回滚：出问题能快速回滚到上一版本

变更管控措施

发布窗口：避开业务高峰期

变更审批：重要变更需审批

变更观察：发布后观察一段时间再继续

🚀 10.2 灰度发布（降低变更风险）

灰度发布的思想

先让一小部分用户/流量使用新版本

验证无问题后，逐步扩大范围

有问题只影响小部分用户，可快速回滚

灰度的维度

按用户：先让内部用户/白名单用户用

按流量：先放1%流量，再10%、50%、100%

按地域：先在某地域上线

灰度的价值

把变更风险控制在最小范围

早发现、早回滚

📊 10.3 容量规划与弹性伸缩

容量规划

基于业务量评估系统容量

预留足够余量（冗余系数）

弹性伸缩

根据流量自动扩缩容

流量高峰自动扩容，低谷缩容

应对突发流量

大促容量准备

提前扩容

提前压测验证

准备降级预案

🧯 10.4 故障应急响应

应急响应流程

发现：监控告警发现异常

上报：快速上报，启动应急

止损：优先止损（限流、降级、切换），而非定位根因

恢复：恢复服务

复盘：事后复盘，找根因

止损优先原则

故障时第一目标是"恢复服务"

先止损，再定位根因

不要纠结于找原因而延误止损

应急工具

一键降级开关

一键限流

一键切换（主备切换、流量切换）

📝 10.5 稳定性度量与持续改进

稳定性指标

可用性、成功率、MTTR（平均恢复时间）

故障次数、故障等级

持续改进

定期回顾稳定性指标

针对薄弱环节改进

沉淀最佳实践

🧭 十一、架构师方法论：稳定性设计的思考

📖 11.1 稳定性设计的原则

原则1：为失败做设计

假设一切都会失败

每个外部依赖都要考虑：挂了怎么办？慢了怎么办？

原则2：分层防御

限流、熔断、降级、隔离层层设防

纵深防御，不依赖单一手段

原则3：快速失败

发现故障，快速失败，不拖累自己

避免"缓慢死亡"

原则4：牺牲局部，保全整体

资源有限时，保核心弃非核心

降级是常态

原则5：可观测

看不见就管不了

监控、告警、链路追踪是基础

⚖️ 11.2 稳定性设计的权衡

稳定性 vs 性能

限流、熔断会拒绝部分请求，影响"可用性"

但保护了系统整体，避免全部失败

权衡：宁可部分失败，不要全部失败

稳定性 vs 复杂度

稳定性方案增加系统复杂度

要根据业务重要性选择投入

核心系统重点投入，非核心适度

稳定性 vs 成本

冗余、多机房增加成本

根据业务价值决定投入

关键：算清楚"故障的代价"

强一致 vs 高可用

强一致性往往牺牲可用性

根据业务容忍度选择

🚫 11.3 避免过度设计

什么是稳定性过度设计

为不存在的故障场景设计复杂方案

非核心系统也搞全套多活

如何避免

从业务价值出发

核心系统重点保障，非核心适度

简单优先：能用简单方案的不用复杂方案

架构师自省

"这个稳定性投入，和业务价值匹配吗？"

🔄 11.4 稳定性的演进（循序渐进）

阶段1：基础防护

设置超时、基本的限流

核心：先有基本的防护意识

阶段2：容错能力

熔断、降级、隔离

引入 Sentinel 等框架

阶段3：可观测性

监控、告警、链路追踪

能发现问题、定位问题

阶段4：体系化

全链路压测、混沌工程、应急预案

稳定性成为体系能力

阶段5：智能化

自动扩缩容、智能告警、自愈

核心认知：稳定性是逐步演进出来的，不是一步到位