限流降级熔断与可观测

0. 元信息

• 主题路径：docs/topics/system-design/subtopics/reliability-and-observability/README.md
• 父主题：system-design
• 主分类：工程技术
• 辅助分类：安全与可靠性
• 适合对象：写过 RPC / HTTP handler、做过线上告警的后端与 SRE 工程师
• 建议周期：1～2 周（每周 6~10 小时，重点是 SLO 文档与混沌演练）
• 前置知识：capacity-and-architecture、caching-and-data-layer、consistency-and-messaging；会用 OpenTelemetry SDK
• 最终目标：能为一个核心服务写出 SLI / SLO 文档与告警规则；用 Redis Lua 写令牌桶限流；用 Resilience4j 配熔断 / 降级 / Bulkhead；能在预发环境做一次混沌演练并写 retrospective

1. 学习路线

限流三件套（令牌桶 / 漏桶 / 滑动窗口）
  → 隔离与熔断（Bulkhead / Circuit Breaker / Retry / Timeout）
  → 降级策略（功能裁剪 / 静态兜底 / 异步化）
  → 可观测三件套（Metrics / Logs / Traces）
  → SLI / SLO / 错误预算
  → 告警分级（Info / Warn / Critical / Page）
  → 混沌工程（ChaosBlade / Litmus / Chaos Mesh）
  → SRE 实践（On-Call / Runbook / Postmortem）

每一步都对应一次故障演练：先在预发做，再到生产低风险。

2. 阶段周数分配

精简子主题不固定周数。按 §3 顺序完成。

3. 九阶段表

4. 第一周任务

精简版省略固定日程。先完成阶段 1~4：限流 + 熔断 + 降级 + 三件套串联。

5. 阶段通用验收

精简版省略；每个产出保留脚本、配置、演练记录、版本。

6. 最终验收

精简版省略；以 §3 第 9 阶段和 §9.4 问题口述检查为准。

7. 综合项目

精简版省略；成果并入父主题百万 QPS 短链项目（限流 + 熔断 + SLO 仪表盘 + 混沌演练）。

本主题贡献

• 在父主题 system-design 的综合项目「百万 QPS 短链」中，本主题（限流降级熔断与可观测）负责 边界保护 + 三件套 + SLO + 混沌演练：用 Redis Lua 令牌桶、Resilience4j 4 状态、OTel traceid 串联、SLI / SLO 文档、ChaosBlade / Litmus / Chaos Mesh 演练把系统变成「可生产运维」形态。
• 工程动作：用 Redis Lua 原子扣减实现令牌桶（容量 + 速率 + 取 token）；用 Resilience4j 写 Circuit Breaker 4 状态（CLOSED / OPEN / HALF_OPEN / DISABLED）演示状态机；用 OTel SDK 自动注入到网关与业务，traceid 串联 logs / metrics / traces；用 AlertManager 分级（1× / 2× / 10× 错误预算燃烧速率）告警；在预发跑 Chaos Mesh 节点下线 + 网络 200 ms 延迟演练。
• 与 system-design 其它子主题对接：给 caching-and-data-layer 提供限流 SLI 指标；给 consistency-and-messaging 暴露 traceid 进 MQ headers；给 capacity-and-architecture 提供 P99 压测数据驱动容量表。

交付物清单：

1. reliability/token_bucket.lua：Redis Lua 令牌桶，含单元测试 6 条（含容量耗尽、并发重置、令牌回补）；
2. resilience4j/：Circuit Breaker + Retry + Bulkhead 完整配置 + 4 状态转换示例压测脚本（Java / Go 任一语言 pseudo-code + 真实 config yaml）；
3. slo/service_slo.md：核心短链服务的 SLI（可用性、延迟、正确性）、SLO（99.95% / 100 ms）、4 个 9 错误预算（30 天 = 21.6 分钟）+ 燃烧速率 1× / 2× / 10× 告警规则；
4. chaos/gameday.md + chaos/runbook.md：ChaosBlade / Litmus / Chaos Mesh 预发演练复盘（节点下线、网络 200 ms 延迟、Redis 重启）与 blameless Postmortem 模板（含 DRI + deadline）。

验收标准：

• 令牌桶在 5 万 QPS 下误差 ≤ 1%、Redis CPU ≤ 40%；
• Circuit Breaker 4 状态在 100% 失败注入后能在 ≤ 30 s 内从 OPEN → HALF_OPEN → CLOSED；
• SLO 文档含错误预算燃烧速率告警 + on-call runbook，新人 ≤ 15 分钟接管；
• 预发演练后写 1 篇 blameless Postmortem，含时间线、根因、影响、行动项、每个行动项 DRI；
• OTel traceid 在 gateway → service → cache → db 4 跳全程串联（含 Kafka / Webhook headers）。

8. 推荐资料

精简版省略；使用 §9.3 和 §9.6 Source。

9. 学习资料汇聚（v0.3 自包含）

9.1 背景与动机

可靠性与可观测是「系统设计能否上线」的最后一道关。Michael Nygard 2007 年出 Release It!，把稳定性的 9 类反模式（集成点是 #1）写进工程界；Netflix 2012 年开源 Hystrix，把熔断、隔离舱、超时、舱壁模式工程化；2018 年 Hystrix 停更，Resilience4j 接棒。

可观测上，Google 2010 年内部 SRE 流程公开，2016 年 Site Reliability Engineering 出书，把 SLI / SLO / 错误预算写进工业实践。2017~2020 年 OpenTelemetry（合并 OpenTracing + OpenCensus）成为跨语言标准。混沌工程上，Netflix 2010 年 Chaos Monkey 公开，2015 年 Chaos Engineering 书出版，ChaosBlade / Litmus / Chaos Mesh 推动混沌工程民主化。

9.2 概念地图

flowchart TB
  Client[请求] --> Limit[限流]
  Limit --> Bulkhead[隔离舱]
  Bulkhead --> CB[Circuit Breaker]
  CB --> Retry[重试 + Timeout]
  Retry --> App[业务]
  App --> Cache
  App --> DB
  App -.信号.-> Metrics[Metrics]
  App -.信号.-> Logs[Logs]
  App -.信号.-> Traces[Traces]
  Metrics --> SLO[SLI/SLO]
  SLO --> Alert[告警分级]
  SLO --> Budget[错误预算]
  Budget --> Chaos[混沌工程]
  Chaos -.验证.-> CB
  Chaos -.验证.-> Limit
  SLO --> Postmortem[故障复盘]

关系说明：限流 / 熔断 / 降级是边界保护；三件套是可观测的「信号源」；SLI / SLO 把信号变成可衡量目标；错误预算决定发布节奏；混沌工程验证边界保护是否真的有效；故障复盘把教训沉淀到下次设计。

9.3 基础知识讲解

9.3.1 论文 / 规范

• Nygard, Release It!（2nd ed., Pragmatic Bookshelf 2018）。
• Hystrix wiki（Netflix 2012，已弃用但模式仍标准）。
• Beyer et al., Site Reliability Engineering（O’Reilly 2016）。
• Jones, Production-Ready Microservices（O’Reilly 2017）。
• Rosenthal et al., Chaos Engineering（O’Reilly 2017）。
• Majors, Observability Engineering（O’Reilly 2022）。
• OpenTelemetry 规范（opentelemetry.io）。
• Google SRE Workbook 第 2~5 章：SLO、错误预算、on-call。
• AWS Well-Architected Reliability Pillar 白皮书。

9.3.2 书

• Michael Nygard, Release It!（2nd ed., 2018）。
• Google SRE Book + SRE Workbook（O’Reilly 2016/2018）。
• Charity Majors, Observability Engineering（O’Reilly 2022）。
• Rob Ewaschuk, Implementing Service Level Objectives（O’Reilly 2020）。
• Brendan Gregg, Systems Performance（2nd ed., 2020）第 12 章。
• Thomas Limoncelli, Time Management for System Administrators（O’Reilly 2005）：on-call 文化。

9.3.3 博客 / 文档

• Netflix Tech Blog: Hystrix / Resilience4j。
• Resilience4j 文档。
• OpenTelemetry 文档。
• Prometheus 文档。
• Grafana 文档。
• Brendan Gregg: USE Method。
• Google SRE Book 全文。
• Charity Majors: Observability。
• Cloudflare SRE 博客。

9.3.4 人物

• Michael Nygard：Release It!。
• Adrian Cockcroft：Netflix 混沌工程，AWS VP。
• Betsy Beyer：Google SRE 主编。
• Niall Murphy：Google SRE 欧洲负责人。
• Charity Majors：Honeycomb CTO，可观测布道师。
• Rob Ewaschuk：SLO 实践者。
• Brendan Gregg：性能 / 观测。
• Dave Rensin：AWS SRE 高级总监。

9.3.5 方法

• Token bucket 默认：允许突发；用 Redis Lua 原子扣减。
• Circuit Breaker 4 状态：CLOSED / OPEN / HALF_OPEN / DISABLED。
• Bulkhead：用线程池或信号量隔离慢依赖。
• SLI first：先选指标（延迟 / 错误率 / 饱和度），再算 SLO。
• 错误预算燃烧速率：>1× 告警；>2× page。
• 混沌工程 5 步：稳态假设 → 实验范围 → 注入故障 → 观察 → 复盘。
• Blameless postmortem：行动项必须有 DRI + deadline + 验证方法。
• Trace-as-contract：traceid 进日志 / 告警 / 工单 / 用户反馈。

9.4 经典问题与经典案例

9.5 学习难点

• 概念难点：熔断 4 状态转换。卡点来自只看「开/关」；用状态机图 + Resilience4j 实际跑 4 状态。
• 思维难点：错误预算燃烧速率。卡点来自把告警阈值设成 P99；用预算燃烧速率（1× / 2× / 10×）作为分级告警依据。
• 工程难点：混沌工程落地。卡点来自生产不敢做；用 ChaosBlade / Litmus / Chaos Mesh 在预发先做，再用游戏日（Gameday）扩展到生产低风险。

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• 限流 / 熔断 / 降级是边界保护，不替代业务异常处理。
• Metrics / Logs / Traces 是三件套，缺一不可。
• SLI / SLO 是把「可观测」变成「可衡量」。
• 混沌工程是「边界保护是否真的有效」的验证手段。
• Postmortem 是「故障复盘」的结构化文档。

9.6.3 Structure

• 令牌桶：容量 + 速率 + Lua 原子。
• 熔断：失败率阈值 + 等待时间 + 半开状态。
• 隔离舱：线程池 / 信号量。
• 重试：指数退避 + jitter + 最大重试。
• SLI：可用性 + 延迟 + 正确性。
• SLO：目标百分比 + 时间窗口。
• 错误预算：Budget = (1 - SLO) × 时间窗口。
• OTel：trace / span / context propagation。

9.6.4 Ecosystem

• 限流：Sentinel / Resilience4j / Redis Lua。
• 可观测：Prometheus / Grafana / OTel / Jaeger / Tempo / Loki / Datadog / Honeycomb。
• 告警：AlertManager / PagerDuty / Opsgenie。
• 混沌：ChaosBlade / Litmus / Chaos Mesh / Gremlin。

9.6.5 Depth Tiers

本计划目标：L3。

9.6.6 Source

• Google SRE Book。
• Resilience4j 文档。
• OpenTelemetry 文档。
• Chaos Mesh 文档。
• 引用快照：2026-07-30。

10. 常见误区

• 限流只在网关做
• 熔断只设开/关，不设半开
• 重试无指数退避 + jitter
• 降级永远返「服务暂不可用」
• Metrics / Logs / Traces 各做一套 traceid
• SLI 选「CPU 使用率」这种不反映用户
• SLO 100% 不可能
• 告警阈值随手设
• 错误预算从不燃烧
• 混沌工程只在测试环境做
• Postmortem 写完不跟进
• 行动项无 DRI
• on-call 永远同一批人
• Runbook 是 5 年前的。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：工程技术 主 + 安全与可靠性 辅。