我有这个场景，伙计们 -
典型的大型CMS应用程序，其中显示以下业务事务：
这是对实际系统的过度简化描述。通过说发布，我指的是一个由4个主要子系统组成的复杂过程：构建调用参数，通过运行另一个Web应用程序（asp.net）生成html内容，提交事务方，以及发信号通知用户关于出版结果。因此，系统失去了在单个Mega事务中运行整个过程的能力，即从可扩展性/性能的角度来看，它可能但不实用。
子系统可以通过多种方式相互通信，例如使用MSMQ，SQL Service Broker，NServiceBus和一系列普通的WCF单向调用（目前已实现）。所以，伙计们，我正在为这种处理寻找一些可靠且可扩展的解决方案，因为看起来系统将越来越忙于越来越多的用户，因此需要生成更多内容。特别是，一旦客户要求移动版本的支持。
我的一个考虑因素是使用MSMQ对所有用户立即请求进行排队，其中专用WCF服务将在内容生成模块（Web应用程序）旁边调度它们。 Windows计划任务也是如此。我看不出这些消息传递平台如何有用，但在html生成之前没有驻留它们。这真让我困惑。
无法弄清楚哪种技术最适合我自己。任何帮助，注意事项，分享你的经验都会对我有所帮助。
答案 0 :(得分：3)
您可以使用NServiceBus中的saga功能来模拟发布过程，包括调度部分，因为它能够在一定延迟后可靠地执行操作，几乎没有开销。
如果您对将用户立即请求排队的感到满意，那么您可以轻松地使用NServiceBus作为您的API，而不是使用MSMQ，WCF和Windows计划任务自行拼凑一些东西。
答案 1 :(得分：3)
如果所有播放器都是SQL Server实例（或由此支持），那么Service Broker具有很大的优势。正如在SQL引擎中集成的那样，这意味着当您必须在数据库和消息存储库之间进行本地分布式事务时（即，每次您将消息入队或出列）时，所有这些时间都成为一个普通的简单事务，因为数据库是邮件存储。当您考虑备份/恢复时，这也会带来优势，因为您可以为数据和提供一致的备份（数据库备份包含所有消息的备份），您只需要一个解决方案高可用性/灾难恢复性：数据库解决方案（群集，镜像）也是消息传递HA / DR故事，因为数据库 是消息存储。内置激活消除了在外部激活机制中配置（更重要的是，在HA / DR故障转移情况下监视和故障转移）的需要。更不用说内置激活没有延迟，而它也可以适应尖峰，外部计划激活可能会遇到问题（外部任务必须集中并且必须平衡池的频率与所需的延迟并考虑尖峰）
答案 2 :(得分：3)
您肯定需要一些业务流程处理。
您的立即请求将转换为命令消息。处理完命令后，您可以发布事件消息，以便您的流程中的下一步可以继续执行该过程。所以你甚至可能不需要安排。
我做了类似的事情：
电子邮件 - ＆gt;内容引擎 - ＆gt;文档转换 - ＆gt;工作流引擎 - ＆gt;索引 - ＆gt;工作流引擎
不涉及任何时间安排。要完成某项任务，请发送命令，当命令处理完成时，端点发布和事件，订阅该事件的任何端点都将收到副本并知道如何继续。我有一个简单的表结构，跟踪进程的数据以及适当的状态。
对于系统的某些部分，您可能需要更多立即处理。当您遇到此问题时，您可以多次安装端点服务，并将其作为“优先级”端点。举个例子。在我们的文档转换器端点中，我们必须转换每个电子邮件正文。由于我们每天收到数千人，他们会排队很多。这是在后台完成的，没有真正关心它何时发生。另一方面，索引Web应用程序的用户需要立即从网站转换某些文档。发送到相同的转换端点会导致临时转换有时等待数千个其他转换请求。所以没有回应。解决方案是简单地安装另一个转换器实例（相同的二进制文件）并为端点配置单独的队列，然后让来自Web服务器的所有转换请求消息路由到ad-hoc端点。问题解决了:)）
作为旁注：即使您使用Web服务接口或WCF，也可以将置于服务总线端点之后，因为端点会为您购买（重试/毒药队列等）
由于您似乎处于评估阶段，您可能需要查看我的FOSS服务总线：http://shuttle.codeplex.com/
这是我们在所描述的系统中使用的。如果需要，有一个单独的调度程序组件（虽然我们没有在项目中使用它）。