在微服务架构的演进中，消息队列几乎被奉为解耦的银弹。
但绝大多数团队在引入消息队列后，却发现故障率不降反升。
这并非工具不好，而是我们常常忽略了消息队列的本质：它只是将服务间的直接依赖，转化为对消息系统的隐性依赖。
当同步调用变成异步投递，控制流便不再属于任何一个服务，而是交给了那个永远需要守护的“中间人”。
于是，解耦的喜悦很快被新的技术债淹没。
消息队列的第一个暗面，是语义的模糊化。
生产端发送成功，并不代表消费端处理成功，这中间横着超时、重试、幂等、死信等一系列新契约。
第二个暗面，是顺序性被无情打碎，分区并行与全局有序成为不可兼得的鱼和熊掌。
第三，运维复杂度呈指数级上升，从集群监控、高可用切换，到积压处理、消费位移管理，每一样都足以让团队疲于奔命。
对比Kafka，它通过分区与副本复制换来了高吞吐，却把一致性责任推给了生产者与消费者；而RabbitMQ用更优雅的路由模型换来了灵活，却在性能与扩展性上设置了天花板。
两种设计都在“解耦”的外衣下，隐藏了截然不同的复杂度转移路径。
我们是否真的需要一个庞大的消息基础设施？
我认为，更好的架构应当遵循“最少消息队列原则”。
也就是，只有当你需要跨越信任边界（例如不同业务域或外部系统）进行事件传播时，才考虑使用消息队列；而同一域内的异步处理，应优先选用本地事件流（如带日志的事务性发件箱）。
这个观点的核心在于：将消息队列从架构的中心位置挪到边缘，让它成为领域之间有限的“口岸”，而不是全局依赖的“总线”。
这样，系统的核心逻辑仍然可以通过同步调用与本地存储保持可预测性，消息队列的副作用被限制在最小的半径内。
真正的解耦，不是把问题扔给消息，而是让每个组件拥有独立的生命周期和恢复能力。
消息队列不是敌人，但它也绝不是救世主。
每一次引入消息队列，都应当视为一次对系统容错能力的投资，而不是对问题本身的免罪符。
架构师需要清醒地衡量：消息队列带来了多少业务灵活性，又偷走了多少可调试性与因果确定性。
如果你不能回答“消息丢失了怎么办”与“消息重复了怎么办”，那么解耦只会让故障的幽灵在每一个节点间游荡。
在分布式系统里，没有银弹，只有权衡；而我坚持认为，最好的解耦是减少不必要的耦合，而不是增加一个复杂的调解者。
让我们把消息队列请下神坛，把它放回工具箱，而不是整个架构的基石。
