架构落地的治理模式：分布式锁与边车模式

架构治理如果只靠会议和评审，很容易变成阻力。更有效的方式是把反复出现的问题沉淀成模式，并明确它们适用和不适用的边界。

核心概念

分布式锁解决多节点竞争同一资源的问题；边车模式把日志、代理、鉴权、观测等横切能力放到主进程旁边。

flowchart TD
    A["治理问题"] --> B{是否是资源竞争?}
    B -->|是| C["分布式锁"]
    B -->|否| D{是否是横切能力?}
    D -->|是| E["Sidecar"]
    D -->|否| F["库 / 平台能力 / 设计约束"]

实际工程场景

定时任务多实例部署时，分布式锁可以避免重复执行；服务网格或日志采集场景中，sidecar 可以让业务进程少关心通信和观测细节。

常见误区

• 用分布式锁掩盖错误的领域模型。
• 把所有能力都塞进 sidecar，导致排查链路变长。
• 只有模式名，没有模板、监控和退出机制。

最佳实践

• 给每个模式写清适用边界。
• 提供可复制的示例和默认配置。
• 监控锁等待、超时、sidecar 健康状态。
• 定期用事故复盘修正治理规则。