我正在考虑使用 MSMQ 作为在我即将进行的项目中执行异步执行的解决方案。我想知道使用 WCF 和 MassTransit 等框架甚至手写 MSMQ 客户端来放置/读取 MSMQ 任务之间的区别。
基本上，应用程序将是几个网站（内部通过 LAN 或外部通过 Internet）通过服务层（无论是 WCF 还是普通 Web 服务）读取/写入数据。然后这个服务层将做以下两件事之一： 1. 将数据写入数据库 2. 和/或通过将消息放入队列来触发后台进程。3.显然它也可以从数据库中检索数据。队列另一端的小代理（一个windows服务）会监控队列并根据任务命令执行。
与 RPC 或分布式执行等相比，这种架构将非常容易扩展（添加更多队列和代理）并且易于实现。并且代理处理不需要是实时的。并且代理和服务层是独立的应用程序，除了它们共享公共域对象和存储库等。
你怎么看？欢迎针对上述要求提出架构建议。谢谢！
WCF 添加了对 MSMQ 的抽象。事实上，一旦你定义了兼容的合约（操作必须是 OneWay），你就可以在配置中透明地切换 MSMQ。（例如，您可以切换到普通的 HttpWS 或 NetTcp 绑定。）
您应该评估其他 WCF 优势，例如安全性等，以了解这些优势如何满足您的需求。同样，它们应该对您在下面使用 MSMQ 的事实相当透明。例如，添加 SOAP 安全性等应该“正常工作”，与使用 MSMQ 无关。
（尽管，IIRC，您仍然需要使用将使用 MSMQ 的服务帐户登录到每台使用 MSMQ 的机器上的桌面，以在机器本地配置文件中生成证书。然后，它不能很好地从IIS6，因为没有加载用户配置文件。一般来说真的很痛苦，但与 WCF 无关。）
除此之外：
你看过 SQL Server 服务代理吗？使用 MSMQ + WCF 和 SSSB 后，我认为 SSSB更易于配置和管理。SSSB 可以在任何 SQL 客户端上使用 T-SQL 命令（我在 Mono 上使用它，在 Linux 上使用事务）。它还将为您提供事务性发送/接收，甚至是远程的（我认为 MSMQ 4 现在允许这样做）。消息队列确实减轻了很多痛苦，如果您已经在使用 SQL Server...
SSSB 经常被忽视，因为 SQL Management Studio 没有所有的 GUI 设计器，但它并不难，而且是一个不错的选择。一个缺点是，如果您想要本地发送功能（即，当网络中断时排队消息），您将需要运行本地 SQL Express 实例。
您的架构看起来合理且合理。但是，您应该考虑使用 WCF 网络 MSMQ 传输而不是手动编码的 MSMQ 类。WCF 将这个通用功能包装成一个很好的编程模型。此外，我相信 wcf 使用的协议与基本 System.Messaging 相比有一些改进
看看普通 MSMQ 的增值：
http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html
总而言之，您会在使用 MassTransit 的 API 中清楚地呈现很多消息传递概念；如果您手动编码或使用 WCF，您将不会有这样的程度。