发布订阅

用一个可运行的 Go 版本基础消息代理，讲透发布订阅、重试语义、失败契约、吞吐与积压估算，以及从朴素实现到工程可用实现的关键取舍。

副标题 / 摘要 发布/订阅架构提升了解耦与扩展性，但也带来一致性、可观测性与调试成本。本文给出其缺点与应对。 目标读者 设计事件驱动系统的工程师 需要评估架构代价的团队 关注一致性与可观测性的开发者 背景 / 动机 发布/订阅系统在大规模系统中常见，但“规模”并不等于“容易维护”。 随着订阅者增多，系统复杂度急剧上升。 核心概念 解耦：发布者与订阅者隔离 一致性延迟：事件传播需要时间 可观测性难度：链路难追踪 幂等：重复消费的处理 实践指南 / 步骤 明确事件语义与顺序保证 建立消费监控与失败重试 定义幂等与补偿策略 限制事件级联传播 建立追踪链路 可运行示例 # 简化事件订阅模型 subscribers = [] def subscribe(fn): subscribers.append(fn) def publish(evt): for fn in subscribers: fn(evt) def handler(evt): print("got", evt) subscribe(handler) publish({"type": "created", "id": 1}) 解释与原理 发布/订阅的扩展性来自解耦，但也引入了“传播延迟”和“调试不透明”。 当事件链路复杂时，错误很难定位。 常见问题与注意事项 订阅者越多越好吗？ 不一定，链路复杂度会显著上升。 一致性如何保证？ 通常只能做到最终一致。 为什么调试困难？ 因为事件是异步的，缺乏完整调用链。 最佳实践与建议 给事件加唯一 ID 与追踪上下文 对关键事件建立 SLA 控制事件风暴与级联 小结 / 结论 发布/订阅不是免费午餐。 它带来扩展性，同时带来一致性与可观测性成本。 ...