4

I have this scenario, guys-

A typical large-scale CMS application in which the following business transactions appear:

  • Users publish content immediately.
  • Users schedule content to be published.
  • Automatic process runs ,say, in 10 minutes interval, collects scheduled and ready (simply a status of the BO)content and sends it to publishing.

This is oversimplified description of the actual system. By saying publishing I mean a complex process consisting of 4 main sub-systems: building invocation arguments, generating html content by running another web app(asp.net), committing the transactional parties, and signaling the users about the publishing results. So the system looses ability to run the whole process in a single Mega-transaction, i.e. it's possible but not practical from the scalability/performance points of view.

There are several options for the sub-systems to communicate each other, like making use of MSMQ, SQL Service Broker, NServiceBus, and a chain of plain WCF one-way invocations (which is currently implemented). So, guys, I'm looking for some possibly more reliable and scalable solution for this processing because looks like the system will be getting more busy with growing number of users and , therefore, more content to be generated. Especially, once, mobile versions' support is requested by the clients.

One of my considerations is to queue all the users immediate requests using MSMQ where a dedicated WCF service will dispatch them next to the content generation module (web app). And so will do the windows scheduled task. I can't see how these messaging platforms could be useful but not residing them before the html generation. This really confuses me.

Can't figure out what technology will fit best for this on my own.Any help, considerations, sharing your experience will help me, guys.

4

3 回答 3

3

您肯定需要一些业务流程处理。

您的即时请求将转化为命令消息。处理完命令后，您可以发布事件消息，您的流程中的下一步可以选择这些事件消息以继续该流程。因此，您甚至可能不需要调度。

我做过类似的事情：

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

不涉及调度。要完成某件事，您发送一个命令，当命令处理完成时，端点发布和事件以及订阅该事件的任何端点都将收到副本并知道如何继续。我有一个简单的表结构来跟踪流程的数据以及适当的状态。

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

附带说明：即使您确实使用了 Web 服务接口或 WCF，将其放在服务总线端点之后也是一个好主意，因为端点会为您购买很多东西（重试/毒队列等）

由于您似乎处于评估阶段，您可能想看看我的 FOSS 服务总线：http ://shuttle.codeplex.com/

这就是我们在所描述的系统上使用的。如果有必要，有一个单独的调度程序组件（尽管我们没有在项目中使用它）。

于 2012-11-27T04:28:21.953 回答
3

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

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

于 2012-11-23T15:01:13.727 回答
3

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

于 2012-11-25T17:21:01.040 回答