跳至主要內容

依赖治理、雪崩防护与团队门禁：可靠性怎样成为持续工程

高谷深陵大约 6 分钟约 1724 字
依赖治理、雪崩防护与团队门禁：可靠性怎样成为持续工程
依赖治理、雪崩防护与团队门禁：可靠性怎样成为持续工程高清原图

局部重试和共享资源会把一个故障放大成系统性崩溃。

Amazon Builders' Library 的 Minimizing correlated failures 建议用 jitter 降低同步重试、刷新和模式切换造成的相关失败。

失效现场：局部保护为什么仍会放大故障

入口 100 RPS 扇出四个依赖，每层三次重试把叶子请求放大到 1200 RPS；共享连接池和线程池使无关功能一同饥饿。 先保存请求时间线、依赖状态、资源水位和权威业务结果，区分产品失败、保护拒绝、基础设施失败和结果未知。

权威语义与量化预算

依赖目录记录 owner、SLO、超时、幂等、重试 owner、并发/速率容量、降级和数据新鲜度；调用图用于计算 fan-out 与最坏放大。 PR 门禁检查新增依赖、无界等待、多层重试、共享资源和未测试降级；例外有精确范围、风险 owner、补偿控制、到期和自动阻断。 正向路径证明承诺成立，反向路径注入慢、拒绝、断连、强杀和恢复，禁止用自动重跑覆盖首次现场。

六段可靠性主链

Dependency graph

在 Dependency graph 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

Failure contract

在 Failure contract 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

Amplification

在 Amplification 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

Shared resource

在 Shared resource 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

Policy gate

在 Policy gate 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

Incident feedback

在 Incident feedback 阶段声明 owner、输入、状态、截止时间、容量、失败码和下一动作。正向实验产生唯一权威结果，反向实验越过边界并断言拒绝、隔离或恢复可见；任何后台工作都必须在请求结束、超时或停机后拥有明确归宿。

可靠性从失败语义开始，而不是从组件清单开始

deadline 必须穿过线程、连接、网络和重试

重试必须有单一 owner、放大预算和幂等账本

熔断、隔离、限流和降级解决不同问题

健康、就绪和停机必须对应平台动作

故障注入用权威状态计算 RTO、RPO 和爆炸半径

可靠性指标必须区分产品失败与保护动作

告警采用多窗口和最小流量，避免低样本打开熔断或触发全体摘流。恢复告警不能仅依赖错误率下降：入口可能已无流量，或重试已经耗尽；还要看到探针成功、实际业务成功、队列与积压下降、连接/线程水位回落和对账差异归零。保护状态迁移本身记录原因、配置版本和 owner，避免手工 forced-open 长期遗留。

故障实验需要证明机制确实接管

依赖治理把事故经验变成门禁

依赖目录不是静态表格，而是可计算调用图：fan-out、同步/异步、超时、重试 owner、幂等、容量、共享资源、降级、新鲜度、owner 和数据等级。新增同步依赖、扩大重试、共享线程/连接池或移除降级都触发可靠性评审与故障实验。关键依赖至少有 N-1 容量或明确停止接流策略。

两个 Java 17 模型固定故障见证

离线模型只压缩状态机和量化判据，真实工程再用 Resilience4j、Spring Boot、数据库、消息系统与平台生命周期验证同一不变量。

javac --release 17 -Xlint:all -Werror examples/backend-development/reliability/dependency-avalanche-governance/RetryStormDemo.java examples/backend-development/reliability/dependency-avalanche-governance/DependencyGateDemo.java
java -cp examples/backend-development/reliability/dependency-avalanche-governance RetryStormDemo
java -cp examples/backend-development/reliability/dependency-avalanche-governance DependencyGateDemo
entryRps=100 fanout=4 retryFactor=3 leafRps=1200 leafCapacity=500 overload=700 avalanche=true
dependencies=6 owned=6 timeoutBounded=6 retrySingleOwner=5 degradeTested=5 expiredExceptions=1 releaseAllowed=false

发布、回滚与恢复门禁

围绕“每条关键依赖拥有失败契约、容量与 owner，变更门禁能计算放大效应并验证降级、恢复和例外到期”保存配置版本、依赖图、基线、故障时间线、权威数据差异、RTO/RPO 和停止条件。发布必须在正常、慢、失败、结果未知和恢复五阶段通过；恢复后还要证明积压归零、重复被吸收、保护状态稳定且没有第二波流量冲击。

跳到正文