配置、发现与协调：多实例系统的现实对齐¶
在单机系统中，现实是静态的（配置文件/环境变量）。在分布式系统中，现实是流动的视图。配置中心、注册发现与协调服务，本质上是在解决：如何让分散的实例对“当前状态”达成共识。
1. 三种核心视图的边界¶
不要把它们混成一谈。分不清边界，就会在 etcd 里存 GB 级配置，或用 Redis 做强一致选主。
- 配置中心 (Configuration)：解决“按什么参数跑”。它关注变更的实时分发（Watch）与回滚能力。
- 注册发现 (Service Discovery)：解决“哪些实例活着”。它关注活跃实例清单（Registry）与存活证明（Heartbeat）。
- 分布式协调 (Coordination)：解决“谁有执行权”。它关注互斥性（Lock）、顺序性与主从关系（Leader Election）。
2. Watch 与 Lease：状态转移的动力¶
这是分布式系统的两条生命线：
- Watch (变更订阅)：消灭轮询。实例订阅某个 Key，变更即推。关键风险：Watch 链路中断（如网络分区）会导致实例陷入“视图陈旧（Stale View）”，即使中心配置改了，本地依然拿着旧参数跑。
- Lease (租约机制)：赋予现实一个“保质期”。实例说自己是 Leader 或 Alive，必须通过持续续约（Keep-Alive）来证明。一旦续约停了，现实便自然失效。没有 Lease 的锁是危险的，因为它会导致挂掉的实例永久占坑。
3. 选主与锁：执行权的原子化¶
- Leader Election：适合长周期的职责。例如“只有一台机器负责索引重建调度”。
- Distributed Lock：适合短周期的资源争抢。例如“同一时刻只有一个 Worker 处理该 PDF 任务”。
- 隔离心智：拿到锁不代表万事大吉，必须考虑锁续约失败后的退出逻辑。如果 Lease 丢了，业务逻辑必须立即中断（Fence），否则就会出现双主（Split-brain）并发改数据。
4. 工程直觉：View Drift (视图漂移)¶
当系统表现异常时，第一反应应是：谁的视图漂移了？
- 配置漂移：同一个模型路由，为什么 A 实例切了，B 实例没切？（查 Watch 状态）。
- 发现漂移：调用方为什么还在往已经下线的实例发请求？（查 Registry 摘除延迟与客户端 Cache 策略）。
- 执行漂移：为什么有两个 cron 在跑同一个任务？（查 选主状态与 Lease 过期判定）。
5. 排查顺序：从一致性到网络¶
- 核对集群共识：在 etcd/Consul/Nacos 侧，当前 Key/Service/Leader 的真实状态是什么？
- 检查通知链：实例的 Watch 是否有效？是否收到了
Event？ - 校验租约活性：Heartbeat 是否在正常打？是否因为 GC 停顿或 CPU 满载导致了意外掉线？
- 查网络分区：是否存在局部隔离，导致一部分节点只能看到旧现实？
结论： 分布式系统不追求绝对的“真理”，只追求受控的共识。好的架构必须假设视图会漂移，并通过 Watch 补齐实时性，通过 Lease 兜底失效性。