稳定性¶

稳定性治理的核心目标是：在部分组件故障时，系统整体仍能提供可接受的服务。本质上是通过一系列防御性设计，将故障的影响范围控制在最小，并尽快恢复。

服务降级¶

当系统负载过高或下游依赖不可用时，主动放弃部分非核心功能，保障核心链路的可用性。

降级策略¶

降级级别¶

L0（正常）→ L1（轻度降级：关闭非核心功能）→ L2（中度降级：返回兜底数据）→ L3（重度降级：仅保留核心写入链路）

熔断¶

熔断是对下游服务的保护机制。当下游持续异常时，调用方主动切断请求，防止故障扩散和资源耗尽（如线程池被大量超时请求占满）。

熔断状态机¶

  ┌──── 失败率 < 阈值 ────┐
  │                     │
  ▼                     │
Closed ──失败率≥阈值──► Open ──冷却时间到──► Half-Open
  ▲                                          │
  │                                          │
  └───── 探测请求成功 ─────────────────────────┘
                探测请求失败 → 回到 Open

• Closed（关闭） — 正常状态，所有请求放行，持续统计失败率
• Open（打开） — 熔断触发，所有请求直接返回 fallback，不再调用下游
• Half-Open（半开） — 冷却期结束后，放行少量探测请求。成功则恢复为 Closed，失败则回到 Open

熔断参数¶

限流¶

限流是对自身服务的保护机制。通过控制单位时间内的请求数量，防止系统被突发流量压垮。

限流算法对比¶

令牌桶算法¶

           固定速率放入令牌
                │
                ▼
请求到达 ──► [获取令牌] ──有令牌──► 放行处理
                  │
                  └──无令牌──► 拒绝 / 排队

令牌桶是最常用的限流算法，兼顾了平滑限流和突发容忍：

• 桶容量（burst）决定了允许的最大突发量
• 生成速率（rate）决定了稳态下的最大 QPS

限流维度¶

限流不仅仅是全局 QPS 限制，应按多维度精细化控制：

• 接口级限流 — 按 API 路径限流，核心接口单独配置
• 用户级限流 — 按用户 ID 限流，防止单个用户刷接口
• IP 级限流 — 防爬虫、防 DDoS
• 服务级限流 — 按调用方服务限流，防止某个下游拖垮自己

分布式限流¶

单机限流只能保护单个实例。在微服务场景下，需要分布式限流来控制整个服务集群的总流量：

请求 → API Gateway / Sidecar → Redis（集中式计数 / 令牌桶） → 后端服务

常见方案：

• Redis + Lua — 使用 Lua 脚本保证计数的原子性，适合大多数场景
• Sentinel — 阿里开源的流量治理组件，支持集群限流、热点参数限流
• API Gateway 限流 — 在网关层统一限流（如 Kong、APISIX）

超时重试¶

超时设置¶

每一次跨服务调用都必须设置超时时间，否则调用方线程 / 协程会被阻塞，导致资源耗尽。

超时设置原则：

• 超时时间应略大于下游的 P99 延迟（如下游 P99 = 200ms，超时设为 500ms）
• 不同操作设置不同超时：读操作超时 < 写操作超时
• 链路超时递减：上游超时 > 下游超时（如 Gateway 3s → Service A 2s → Service B 1s），避免下游超时后上游仍在等待

重试策略¶

重试间隔 = min(base * 2^attempt + random(0, jitter), max_interval)

重试的注意事项¶

负载均衡¶

负载均衡将请求分散到多个服务实例上，避免单点过载。

常见算法¶

健康检查¶

负载均衡需要配合健康检查，及时摘除异常实例：

• 主动健康检查 — 负载均衡器定期向实例发送探测请求（HTTP / TCP）
• 被动健康检查 — 根据实际请求的响应状态判断（连续 N 次失败则摘除）
• 优雅下线 — 服务主动通知注册中心下线，等待存量请求处理完毕后再停止

故障隔离¶

故障隔离的原则是：一个组件的故障不应影响其他组件。通过隔离手段将故障限制在最小范围内。

隔离维度¶

舱壁模式（Bulkhead）¶

借鉴船舶的水密舱设计：船体被隔板分为多个独立舱室，即使一个舱室进水，也不会影响其他舱室。

                   ┌─────── 线程池 A（支付） ───────┐
                   │  最大 20 线程 | 队列 50        │
请求 ──► 路由分发 ──►├─────── 线程池 B（推荐） ───────┤
                   │  最大 10 线程 | 队列 20        │
                   ├─────── 线程池 C（通知） ───────┤
                   │  最大  5 线程 | 队列 10        │
                   └──────────────────────────────┘

灰度发布¶

灰度发布（又称渐进式发布）是指将新版本逐步推送给一小部分用户，验证无误后再全量上线，从而降低发布风险。

发布策略对比¶

灰度流量路由¶

灰度发布的关键是精确的流量路由，常见的路由维度：

• 按比例 — 5% → 20% → 50% → 100% 逐步放量
• 按用户 ID — 指定测试用户或按 ID 尾号分流
• 按地域 — 先在某个城市灰度
• 按请求头 / Cookie — 内部员工携带特定标识，优先使用新版本

灰度验证指标¶

灰度期间必须持续监控以下指标，确保新版本表现正常：

• 错误率：新版本的错误率不应高于旧版本
• 延迟：P50 / P99 延迟不应有明显劣化
• 业务指标：转化率、下单量等核心业务数据
• 资源消耗：CPU、内存是否异常上涨

异地多活/容灾¶

异地多活是稳定性的终极保障，确保单个数据中心故障时业务不中断。

容灾架构模式¶

RPO（Recovery Point Objective）：可容忍的最大数据丢失量

RTO（Recovery Time Objective）：从故障到恢复服务的最大时间

异地多活的核心挑战¶

数据一致性是多活架构最难解决的问题。跨数据中心的数据同步不可避免地面临延迟，需要在一致性和可用性之间权衡：

• 单元化（Set-based） — 按用户维度（如 UID 尾号）将数据和流量划分到不同单元，每个单元内部自治。跨单元调用走专线，单元故障时将其流量切换到其他单元
• 数据同步方案 — 基于 Binlog 的异步复制（如 Canal + Kafka），或使用数据库原生的多主复制
• 冲突处理 — 多个机房同时写入同一条数据时的冲突解决策略（Last Write Wins、业务合并等）

容灾切换¶

正常状态                              故障切换
┌────────┐    ┌────────┐           ┌────────┐    ┌────────┐
│ 机房 A  │◄──►│ 机房 B  │    ──►   │ 机房 A  │    │ 机房 B  │
│ (活跃)  │    │ (活跃)  │          │ (故障)  │    │ (接管)  │
└────────┘    └────────┘           └────────┘    └────────┘
         DNS / GSLB                        DNS 切换 / 流量调度

切换机制：

• DNS 切换 — 修改 DNS 解析指向，生效时间取决于 TTL（通常 30s~5min）
• GSLB（全局负载均衡） — 基于健康检查自动切换流量，秒级生效
• API Gateway 路由 — 在网关层直接切换后端集群

评论