【问题标题】：Do I need a service bus for simple asynchronous command handling?我需要服务总线来处理简单的异步命令吗？
【发布时间】：2012-07-26 14:57:10
【问题描述】：

我的系统使用带有单独处理程序的命令模式。我的命令在当前处理所有进程中的命令的 CommandService 上执行。

我有某些命令至少会执行以下其中一项操作缓慢的操作：

发送电子邮件
生成 PDF
发送传真
与第 3 方网络服务交互

我希望所有这些命令都在进程外处理，以便 UI 更加简洁。

我应该只为这些命令使用消息总线，还是应该让进程内命令处理程序调用BeginInvoke()？

编辑 - 附加信息

系统的用户数量很少（在繁忙的一天可能有 100 个并发用户），因此队列可能永远不会变得很长。这里的主要内容是减少发送带有附件 PDF（相关命令）的电子邮件时 UI 被阻止的时间。员工必须在一天内多次执行该命令。

考虑到整个情况，我想我现在会选择BeginInvoke()，原因有几个：

必须触摸所有 UI 交互，以确保它们的行为就像命令成功一样。 “您需要发送此文档”的提醒位于 UI 中的多个位置，并且在发送报告后会刷新整页。
我的客户正处于繁忙季节的中间（他们在夏季完成了超过 50% 的年度业务），因此在这个时候引入一个全新的基础设施对我来说似乎并不明智不熟悉管理。

但是知道我现在所知道的，在一个新系统上，我会从一开始就使用服务总线来处理任何慢速命令（实际上每个系统都需要发送电子邮件）并设计 UI 以便更容易地执行命令从同步处理切换到异步处理。在实现中，这基本上意味着每个 POST 都是 AJAX 并在 UI 中执行一个动作，就好像它成功了一样。（例如，查看 Facebook 如何处理 cmets。）

【问题讨论】：

时间耦合和相关问题，是你应该研究的。

标签： c#-4.0 domain-driven-design cqrs message-bus

【解决方案1】：

这可能更多是可靠性问题将您推向消息总线。您会看到，如果您的原始事务（执行 BeginInvoke 的事务）成功，然后在您调用的中途服务器崩溃，您的系统将没有内存，它仍然需要发送电子邮件或生成 PDF .

消息总线能够将第二个事务回滚到队列中，这样当服务器再次启动时，它会再次发送电子邮件。

【讨论】：

【解决方案2】：

两种解决方案各有利弊。

BeginInvoke 是非常简单的解决方案，其语义与直接通过命令调用处理程序相同。但此解决方案取决于线程基础架构：最大线程数、由于并发访问 IO 资源而导致的冻结线程等。
MessageBus 是非常灵活且功能强大的解决方案，您可以在其中控制命令处理过程的各个方面。但是它为您的应用程序引入了另一个抽象层，如果更简单意味着更好，这将是一种过度设计

我建议估计您的系统加载要求、这些后台任务的数量、增长因素等，并根据这些来做出决定。

但在我个人看来，引入适用于 80% 案例的总线解决方案。您可以引入一个简单的总线实现，如果需要，可以在下一次迭代中进行扩展。

【讨论】：