何时消息传递（基于JMS的经纪人/队列）过度杀伤？
基于JMS的经纪人是解除系统的非常有用的工具。但是，建筑和膨胀之间的细线不断变化。作为对经纪人有理论上理解的人，但是如果没有实践经验，我可以提供什么建议来避免“膨胀”。哪些性能因素，设计考虑因素和系统特征应注意，以免经纪人被误用。例如，使用经纪人将事件推向伐木服务似乎是过分的杀伤力（我的一个朋友实际上几乎暗示了这一点）。另一个示例 - 创建审核服务（对多个后端系统进行审核）时，（异步）消息传递一个好的解决方案。优点和缺点？
JMS based brokers are a very useful tool to decouple systems. However, invariantly the thin line between architecture and bloat is crossed. As someone with theoretical understanding of brokers, but without the practical experience, what advice can I be given to avoid "bloat". What are the performance factors, design considerations and systems characteristics should one be aware so that brokers are not mis-used. e.g. using brokers for pushing events to a logging service seems an overkill (one of my friends actually almost suggested that). Another example - when creating an auditing service (auditing for multiple backend systems), is (asynchronous) messaging a good solution. pros and cons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这都是规模问题。
只要您几乎没有服务，都在同一框上或几个框上运行，但都只能与数据库进行通信，那么消息传递并不能解决任何真正的问题，而只会增加复杂性。
一旦拥有许多服务，就需要在多个服务器（可能是多个数据中心）上运行，这些服务需要相互通信（不仅与数据库进行通信），因此有必要。
另一种情况是，当您的服务具有不同的发布时间表时，尤其是当有很多人的发布时，并且由不同的团队开发。它达到了同步发行的地步，以确保兼容性并最大程度地减少停机时间成为真正的负担。异步消息是那里解决方案的一部分。
最后，考虑到上述条件，将异步事件推向伐木服务确实是有道理的。如果您使用某些公司范围的日志记录服务在多个服务器上运行多个服务，则日志队列很有意义。
It's all a question of scale.
As long as you have few services, all running on the same box, or maybe several boxes but all communicating just with a database, then messaging doesn't solve any real problem and only adds complexity.
Once you have many services, running on multiple servers (and possibly multiple data centers), that need to communicate with each other (and not just with a database), messaging becomes necessary.
Another case is when your services have different release schedules, especially when there are many and they're developed by different teams. It gets to a point where synchronize releases to ensure compatibility and minimize down-time becomes a real burden. Asynchronous messaging is part of the solution there.
Finally, pushing asynchronous events to a logging service does make sense, given the conditions mentioned above. If you have multiple services running on multiple servers using some company-wide logging service, then a log queue makes perfect sense.