MSMQ与SQL Server Service Broker

Question

我有一个由三个部分组成的应用程序：

• 是一个面向终端用户和业务合作伙伴的前端网络商店
• ，一个处理订单的订单管理系统
• ，一个技术数据库系统，用于处理订购

的所有产品和服务的所有技术细节。

今天，这些系统(在不同的服务器上，由不同的团队开发)使用WCF WCF服务进行互操作。

只要所有服务器都启动，这个设置就能正常工作。但他们并不是-反正也不总是这样。

因此，我已经开始考虑使用MSMQ或SQL Server Service Broker来处理这些系统之间的通信--至少当涉及到将订单存储到订单管理系统中的web商店时，或者使用订单管理系统将技术数据发送到技术数据库系统时。

我希望在整个系统中实现更高的可靠性--即使订单管理后端暂时不可用，用户仍然可以下订单，而且不会丢失订单。

但最大的问题是: MSMQ还是Service？？这三个系统都是基于Windows和.NET的，并且已经在三个单独的服务器上使用Server。

有没有人有确凿的、真实的事实来支持(或反对)这两种技术之一？你对这两套技术的真实体验是什么？赞成与反对。如果你可以从头开始-你会选择哪一个？或者你会选别的东西(什么？)完全是吗？

Answer 1

在不同的情况下，我都用得很好。我的偏好非常基本:如果从数据库事件触发消息发送事件，则使用Service；如果事件在代码中，则使用message。该首选项的基础是在触发事件的同一个平台上更容易设置。