服务治理

微服务拆分带来了灵活性，但也带来了复杂性。

• 服务多了，怎么知道谁在调用谁？
• 下游服务挂了，上游怎么不被拖垮？
• 流量突然增大，怎么保护系统不被冲垮？

服务治理，就是来解决这些问题的。

模块速览

服务治理分为两大类：基础设施治理和安全保障。

章节	篇数	核心内容
服务发现与负载均衡	4 篇	服务发现、负载均衡策略、客户端 vs 服务端
容错与保护	7 篇	熔断、降级、限流、超时、重试、幂等、安全

治理全景图

服务治理
│
├── 服务发现
│   ├── 客户端发现 vs 服务端发现
│   ├── 健康检查与故障剔除
│   └── 服务注册与注销
│
├── 负载均衡
│   ├── 策略：轮询、随机、哈希、最小连接
│   └── 客户端 LB vs 服务端 LB
│
├── 容错保护
│   ├── 熔断：断路器模式
│   ├── 降级：多级降级策略
│   ├── 限流：单机 + 分布式限流
│   └── 超时：超时传递与最佳实践
│
└── 安全与幂等
    ├── 重试：退避算法
    ├── 幂等：接口幂等实现
    └── 接口安全：签名、认证、校验

核心问题：如何保护系统

分布式系统的故障传播，往往是灾难性的：

用户请求 → 服务 A → 服务 B → 服务 C
                          ↓
                     C 突然变慢
                          ↓
                     B 等待超时
                          ↓
                     B 资源耗尽
                          ↓
                     A 也挂了
                          ↓
                     系统崩溃

这就是「雪崩效应」

保护系统的核心思路：

1. 熔断：当下游持续失败，切断调用，保护自己
2. 降级：核心功能优先，非核心功能降级
3. 限流：控制进入系统的流量，不超过系统容量
4. 超时：避免无限等待，及时释放资源

面试高频问题

Q1：熔断和降级的区别？

「熔断是保护自己，降级是保护系统。 熔断当下游持续失败时，直接短路，不再调用下游。 降级是牺牲部分功能，保证核心功能可用。 两者配合：熔断触发 → 降级方案生效。」

Q2：令牌桶和漏桶的区别？

「漏桶以恒定速率处理请求，流量完全平滑。 令牌桶按固定速率生成令牌，请求必须拿到令牌才能处理。 令牌桶允许突发流量（桶容量内），漏桶不允许。 令牌桶适合「允许突发但有上限」的场景，漏桶适合「流量必须完全平稳」的场景。」

Q3：如何保证接口幂等？

「接口幂等的本质是：同一操作执行一次和执行多次，效果相同。 四种实现方案：

1. Token + Redis：请求前获取 Token，提交时验证
2. 唯一键约束：数据库主键 / 唯一索引
3. 状态机：订单状态只能正向流转
4. 分布式锁：锁住业务 ID 关键是要选择与业务匹配的方案，不是越多越好。」

延伸阅读

服务治理是微服务架构的「基础设施」。

建议的学习顺序：

1. 服务发现与健康检查（理解服务感知）
2. 负载均衡（理解流量分配）
3. 熔断与降级（理解系统保护）
4. 限流与超时（理解流量控制）
5. 重试与幂等（理解容错机制）

记住：好的服务治理，让系统在故障面前「稳如泰山」。