基于JMS的代理是解耦系统的非常有用的工具。然而，架构和膨胀之间的界限总是被跨越。作为一个对经纪人有理论了解，但没有实际经验的人，我能得到什么建议来避免"膨胀"?应该注意哪些性能因素、设计考虑因素和系统特性，以免误用代理。例如，使用代理将事件推送到日志服务似乎是一种过度的行为(我的一个朋友实际上几乎建议这样做)。另一个例子是，在创建审计服务(针对多个后端系统进行审计)时，(异步)消息传递是否是一个好的解决方案。利与弊?
这都是规模的问题。
只要你有几个服务，都在同一个机器上运行，或者可能是几个机器，但都只与数据库通信，那么消息传递不能解决任何实际问题，只会增加复杂性。
一旦有许多服务运行在多个服务器(可能还有多个数据中心)上，并且需要相互通信(而不仅仅是与数据库通信)，那么消息传递就变得必要了。
另一种情况是，当你的服务有不同的发布时间表，特别是当有很多，他们是由不同的团队开发。在这种情况下，同步版本以确保兼容性和最小化停机时间成为一种真正的负担。异步消息传递是解决方案的一部分。
最后，考虑到上面提到的条件，将异步事件推送到日志服务是有意义的。如果您有多个服务在多个服务器上运行，使用一些公司范围的日志服务，那么日志队列是非常有意义的。