为什么在消息排队系统(例如MSMQ/RabbitMQ等)之上需要NService Bus/MassTransit之类的服务总线框架? [英] Why do we need service bus frameworks like NService Bus/MassTransit on top of message queuing systems like MSMQ/RabbitMQ etc?

问题描述

在分布式消息事务世界中，我试图了解开发分布式系统所涉及的不同部分.据我了解，您可以使用带有消息队列系统支持的企业总线来设计消息传递系统.为什么同时使用两者是一个好主意?通过仅对消息排队系统进行编程是否可以实现相同的目的?两者一起使用有什么好处?

In the distributed message transaction world, am trying to understand the different parts that are involved in developing distributed systems. From what I understand you can design messaging system using enterprise bus backed with a message queue system. Why is it a good idea to use both? Can the same be achieved by programming against just the message queuing system? What are the advantages of using both together?

推荐答案

您当然可以直接针对消息传递基础结构进行编码，并且会发现优缺点.每次运输.但是，在此过程中您需要做出许多决定，而这正是服务总线可以提供帮助的地方.

You certainly can code directly against the messaging infrastructure and you will find that there are pros and cons w.r.t. each transport. There are many decisions that you will need to make along the way, though, and this is where a service bus may assist.

直接针对排队系统进行开发将不可避免地导致您需要各种抽象来防止重复.

Developing directly against the queuing system will inevitably lead to various abstractions that you will require to prevent duplication.

服务总线将为以下方面提供意见/实施方式:

A service bus will provide opinions/implementations for:

• 消息传递
  • 完全一次(分布式事务-并非所有排队系统都支持分布式事务)
  • 至少一次(非交易)
  • 最多一次(可能需要进行一些事务处理，但您可以不进行分布式事务而摆脱困境)
  • Message delivery
    • exactly-once (distributed transactions - distributed transactions are not supported by all queuing systems)
    • at-least-once (non-transactional)
    • at-most-once (will probably require some transactional processing but you can get away with no distributed transactions)

    某些服务总线实现提供了用于实现流程管理器的框架(大多数情况下称为sagas).我目前的观点是，流程管理者必须像其他任何实体一样，都是一流的公民，但是这可能会改变:)

    Some service bus implementations provide a framework for implementing process managers (called sagas by most). My current opinion is that a process manager needs to be a first-class citizen as any other entity is but that may change :)

    无论如何，如果您仍在评估选项，还可以看看我的FOSS项目: http: //shuttle.github.io/shuttle-esb/

    Anyhow, if you as still evaluating options you could also take a look at my FOSS project: http://shuttle.github.io/shuttle-esb/

    因此，服务总线可能会给您带来很多开箱即用的功能，而直接针对队列进行编码可能会花费一些工作.

    So a service bus may buy you quite a bit out-of-the-box whereas coding against the queues directly may be a bit of work to get going.

    这篇关于为什么在消息排队系统(例如MSMQ/RabbitMQ等)之上需要NService Bus/MassTransit之类的服务总线框架?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！