在我们精美的 ESB 中，每个请求的日志记录都是通过基于 JMS 日志记录的通用基础设施完成的。简而言之，发生的事情如下：
- 服务获取请求服务
- 在 LogData 中准备一些数据
- 对象服务调用数据库
- LogData 对象中捕获数据库交互所花费的时间
- 服务已准备好发送响应
- LogData 对象被发送到消息传递目的地
- 服务发送响应
非常玫瑰色！对于纸质建筑师来说是的。
这是实际的问题：
JMS 服务提供者有时会由于系统级错误或软件崩溃而变得不可用。然后，服务在必须建立 JMS 连接以发送 LogData 对象的步骤（步骤 6）处等待。导致响应延迟，从而导致性能和用户体验不佳。
所以这就是很多开发者网站所吹捧的“使用JMS进行分布式日志记录”的最大缺点。另请注意，LogData 的存在是一种关键的非功能性需求。这意味着消息以持久模式发送，导致需要等待，直到 JMS 提供者确认收到发送者（本例中的服务）消息 - 这应该归咎于什么呢？设计不成熟？有没有实施类似的成功案例?
同步地在 db/jms/socket/etc 中进行任何日志记录都会带来很多问题。
通过登录内存和异步来实现它。转储到 file/jms（取决于 JMS 是否可用）。单个后台线程应该可以满足您的需要。有同步。日志记录可能会在应用程序的完全意外且无害的部分造成很多麻烦。
我想不出任何可能的同步成功案例。记录。
编辑。最好使用 ConcurrentLinkedQueue 之类的来保留 LogData （我的意思是避免任何阻塞，如果可能的话提高性能/吞吐量）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
