消息代理如何解耦发送者和接收者？
- 消息代理: 接收、校验、保存、路由和投递消息的中间服务，使生产者不必直接定位所有消费者;
- 异步边界: 生产者完成发送后不一定等待业务处理完成，接收者可以独立上线或扩容;
- 协议适配: 某些代理可以连接不同消息协议，但“代理”不意味着支持任意协议转换;
- 可靠性条件: 需要明确持久化、确认、重试和故障恢复设置，不能只因经过代理就宣称不会丢消息;
- 模式: 任务分配使用 消息队列，一份事件供多方处理使用 发布订阅;
- 原文示例: NATS、Kafka、RabbitMQ、ActiveMQ，产品可同时支持多个消息模式;
事件流与传统队列的保留方式有何区别？
| 维度 | 常见任务队列 | 常见事件日志 |
|---|
| 处理进度 | 确认任务完成 | 消费者保存读取位置 |
| 数据生命周期 | 完成后可删除 | 按保留时间或容量保存 |
| 重新读取 | 取决于产品 | 可从历史位置重放 |
| 独立消费者 | 竞争消费常见 | 不同消费组各有进度 |
- 事件流用途: 高吞吐事件记录、流式处理与重放，按主题及分区组织数据;
- 原文修正: 事件流平台并非无法跟踪消费者或提供投递保证；例如 Kafka 使用消费偏移和可配置确认机制;
- 保证依据: 参见 Kafka 设计文档，端到端结果还取决于消费提交与外部副作用;
ESB 如何集中整合企业应用？
- ESB: 企业服务总线，在中央集成层执行协议转换、数据模型映射、路由和请求组合;
- 收益: 现有集成可复用，某个应用改变实现时可通过适配层隔离其他应用;
- 适用条件: 已有异构系统较多，统一集成的收益足以覆盖总线本身的治理成本;
- 原文示例: IBM App Connect、Apache Camel、Fuse，以及 Azure Service Bus 相关集成能力，具体功能并不完全等价;
为什么集中总线可能变成瓶颈？
- 单点: 集成都依赖同一总线时，总线故障可能影响大面积通信;
- 变更耦合: 一条共享转换规则更新可能影响多个使用方，需要回归验证;
- 组织成本: 所有团队等待中央配置与发布，可能抵消服务独立开发的收益;
- 与轻量代理比较: 简单消息交换通常不需要完整中央业务编排，按实际集成责任选择最小机制;