即时和计划的业务事务-MSMQ/NServiceBus/MS Sql Service Broker/Windows任务计划程序？

我有这个场景，伙计们-

典型的大规模CMS应用程序，其中出现以下业务事务：

• 用户立即发布内容
• 用户计划要发布的内容
• 自动过程以10分钟的间隔运行，收集计划的和准备的（BO的状态）内容并将其发送到发布

这是对实际系统的过于简单的描述。我所说的发布是指一个由4个子系统组成的复杂过程：构建调用参数、通过运行另一个web应用程序（asp.net）生成html内容、提交事务方以及向用户发送发布结果的信号。因此，系统失去了在单个大型事务中运行整个流程的能力，也就是说，从可伸缩性/性能的角度来看，这是可能的，但并不实际

子系统之间有几个相互通信的选项，比如使用MSMQ、SQL Service Broker、NServiceBus和一系列简单的WCF单向调用（目前已实现）。所以，伙计们，我正在寻找一些可能更可靠、更可扩展的解决方案，用于此处理，因为看起来随着用户数量的增加，系统将变得更加繁忙，因此，将生成更多的内容。特别是，一旦客户端请求移动版本的支持

我考虑的一个问题是使用MSMQ将所有用户即时请求排队，其中专用WCF服务将在内容生成模块（web app）旁边发送这些请求。windows计划的任务也是如此。我看不出这些消息传递平台是如何有用的，但在html生成之前，它们并不存在。这真让我困惑

---

我自己无法确定哪种技术最适合于此。任何帮助、注意事项、分享您的经验都将帮助我，伙计们。

您可以使用NServiceBus中的saga功能来建模发布过程，包括计划部分，因为它能够在一定的延迟后可靠地执行操作，几乎没有开销

---

如果您很乐意将用户的即时请求排队，那么您可以轻松地使用NServiceBus作为API，而不是自己将MSMQ、WCF和Windows计划任务拼凑在一起。

如果所有参与者都是SQL Server实例（或有SQL Server实例支持），则Service Broker具有很大的优势。由于集成在SQL引擎中，这意味着当您必须在数据库和消息存储之间进行本地分布式事务时（即，每次您将消息排队或出列），所有这些时间都将成为普通的简单事务，因为数据库就是消息存储。当您考虑备份/恢复时，这也会带来好处，因为您可以为数据和消息提供一致的备份（数据库备份包含所有消息的备份），您只需要一个高可用性/灾难可恢复性的解决方案：数据库解决方案（群集、镜像）也是消息HA/DR的故事，因为数据库是消息存储。内置激活消除了配置外部激活机制的需要（更重要的是，在HA/DR故障切换情况下进行监视和故障切换）。更不用说内置的激活没有延迟，同时它也能适应尖峰，外部调度的激活可能会遇到问题（外部任务必须池化，并且必须平衡池的频率与期望的延迟，并考虑尖峰）

你肯定需要一些业务过程处理。 您的即时请求将转换为命令消息。处理命令后，您可以发布事件消息，以便流程中的下一步继续处理。所以你甚至不需要安排时间

我做了类似的事情：

电子邮件->内容引擎->文档转换->工作流引擎->索引->工作流引擎

没有涉及日程安排。要完成某项工作，请发送一个命令，当命令处理完成时，端点将发布和事件，无论哪个端点订阅了该事件，都将收到一个副本并知道如何继续。我有一个简单的表结构，跟踪流程的数据以及相应的状态

对于系统的某些部分，您可能需要更直接的处理。当您遇到这种情况时，您可以多次安装端点服务，并让其中一个充当“优先级”端点。举个例子。在文档转换器端点中，我们必须转换每个电子邮件正文。因为我们每天都会收到数以千计的邮件，所以他们会排很多队。这是在后台完成的，没有真正关心它发生的时间。另一方面，索引web应用程序的用户需要立即从web站点转换某些文档。发送到同一个convert端点会导致临时转换在数千个其他转换请求之后等待。因此，没有收到回复。解决方案是简单地安装另一个转换器实例（相同的二进制文件）并为端点配置单独的队列，然后让所有来自web服务器的转换请求消息路由到临时端点。问题已解决：）

附带说明：即使您使用web服务接口或WCF，也最好将其放在服务总线端点后面，因为端点会为您带来很多好处（重试/毒药队列等）

由于您似乎处于评估阶段，您可能想看看我的FOSS服务总线：

这是我们在所描述的系统上使用的。如果有必要，有一个单独的调度器组件（尽管我们