在使用Service Bus实现时,您是否将日志记录作为单独的服务?

时间:2013-04-10 08:22:51

标签: architecture soa nservicebus servicebus

使用服务总线实现。 当特定用户阅读电子邮件时,我们会提出已阅读电子邮件的事件。 我们有一个订阅者,然后在它被引发时接收此事件。 阅读电子邮件时,我们要执行操作,然后记录电子邮件已在数据库中读取。

我的问题是: - 你会 a)提出另一个事件,然后由日志服务订阅,该服务将监听为此系统和其他系统引发的所有日志记录事件? b)让订阅者收听电子邮件已读取的电子邮件读取事件日志吗? c)做点什么吗?

4 个答案:

答案 0 :(得分:0)

这完全取决于您是否希望将日志记录执行作为当前事务的一部分。随着系统数量的增长,您可能会发现优化是将消息发送到另一个端点以完成日志记录。我不打扰日志记录中的pub / sub,你应该能够使用一个简单的点对点通信。

答案 1 :(得分:0)

如何在订阅者上设置审核队列?然后,您可以使用单独的处理程序从审计队列中提取消息并记录您感兴趣的事件(在这种情况下,电子邮件已被读取事件)。

答案 2 :(得分:0)

如果我了解你,你说,

  

我们举起了一封电子邮件已被阅读的活动。我们有一个订阅者,然后在它被引发时接收此事件。阅读电子邮件时,我们要执行操作,然后记录电子邮件已在数据库中读取。

因此,您举起“电子邮件阅读”事件,订阅者将其选中并执行操作。目前,执行操作后,不会进行任何记录。

您可以让相同的订阅者在执行操作后执行日志记录,或者与操作并行执行日志记录,或者您可以让第二个订阅者收听“电子邮件读取”事件并执行日志记录。

这取决于日志记录是针对“操作”进行事务处理,日志记录是否必须可靠以及其他此类注意事项。当然,可维护性,管理,审计等都有正常的考虑因素。

换句话说,“它取决于”。

答案 3 :(得分:0)

您是否遵循DDD原则,如果是这样,您为什么要提供服务才能记录?

如果“日志记录”是业务需求的一部分,这意味着您的存储库中的状态更改,那么它需要成为事务的一部分,该事务会引发用户阅读电子邮件后引发的事件,而不是反过来说,但在我看来,从DDD的角度来看,只有一个单独的服务只是为了记录不是最好的方法,如果你有一个处理系统中所有消息的中央服务,那么关键是首先是一个分布式系统?

“你愿意吗?”提出另一个事件,然后由日志服务订阅,该服务将监听为此系统和其他系统提出的所有日志记录事件?“

我认为你不应该这样做,因为事件处理程序不应该发布另一个事件而应该提交命令。

另一方面,为什么不能在提升事件的服务中完成日志?因为那是行动发生的地方。