基于JMS的代理是解耦系统的非常有用的工具。然而，不变的是架构和膨胀之间的细线交叉。作为对经纪人有理论上理解的人，但没有实践经验，我可以给出什么建议来避免“膨胀”。应该注意哪些性能因素，设计考虑因素和系统特性，以便经纪人不会被误用。例如使用代理将事件推送到日志记录服务似乎是一种矫枉过正（我的一个朋友实际上几乎暗示了这一点）。另一个例子 - 在创建审计服务（审计多个后端系统）时，（异步）消息传递是一个很好的解决方案。利弊？
答案 0 :(得分：2)
这都是规模问题。
只要您的服务很少，所有服务都运行在同一个盒子上，或者可能只有几个盒子，但只是与数据库进行通信，那么消息传递并不能解决任何实际问题，只会增加复杂性。
一旦有许多服务，在多个服务器（可能还有多个数据中心）上运行，需要相互通信（而不仅仅是数据库），就需要进行消息传递。
另一种情况是您的服务有不同的发布计划，特别是当有很多并且由不同的团队开发时。它达到了同步版本以确保兼容性并最大限度地减少停机时间成为真正负担的程度。异步消息传递是那里解决方案的一部分。
最后，鉴于上述条件，将异步事件推送到日志服务确实有意义。如果您使用某些公司范围的日志记录服务在多个服务器上运行多个服务，那么日志队列就非常有意义。