1

事实证明，我需要在我的系统中执行一些定期任务，这些任务在 Windows Azure 工作者角色下运行。我想强调的是，它可能是任何平台 Azure、亚马逊、内部解决方案。就通常的系统而言，如何完成任务不是问题，但由于我们在云中，并且我的角色可能有多个实例，因此在某些时候可能会出现问题。

所以这里有几个我能想到的方法：

  1. 通常的计时器，它们是同步的，比如通过天蓝色存储，这样就不会多次运行任务。例如，您可以自己实现它或从 Lokad 获取一个。您可以在计时器事件上内联执行任务，也可以将命令发送到队列中。

    优点：

    • 常用方法，每个人都知道计时器以及如何烹饪它们
    • 不需要有状态。实例启动后，计时器也会启动并运行

    缺点：

    • 在主要部分旁边还有初始化计时器和执行它们的附加逻辑，主要部分仅负责处理来自队列的命令和事件。

  2. 一旦我得到启动任务的命令，我就会发送一个命令 StartTask（30 秒）。一旦命令处理程序收到它，它确实需要完成工作，然后以 30 秒的延迟重新抛出相同的命令。

    优点：

    • 完美契合 CQRS 设计
    • 没有与定时器相关的额外逻辑，纯反应器

    缺点：

    • 打破范式，CQRS 本身从一开始就很难治疗和使用。人们倾向于使用已知技术（通常的计时器），即使它不符合设计（cqrs 方法），结果我们有混乱的融合。
    • 另一个破碎的范式。系统重启时是无状态的还是有状态的？我会说状态存储在代理消息传递环境中。您需要做的就是遵循消息处理规则。

我对此的看法：

就个人而言，我确实赞成第二种方法，它的所有缺点都应该转移到 Pros 部分。

问题：

这里的最佳做法是什么？我错过了什么吗？

4

4 回答 4

1

使用Windows Mobile Services的调度程序或Aditi的 Windows Azure Store Scheduler 应用程序怎么样？它们可以用来启动几乎任何东西，你可以让它们向你的系统发送命令。

如果您选择了选项 1，那么是的，您必须处理同步，但其中内置了冗余。如果您执行了选项 2 并且处理命令的实例出现故障，请确保任务不会停止。这将取决于您如何设置命令重试。

于 2013-04-06T12:06:18.690 回答
1

如果您使用 azure servicebus 作为代理，则可以使用它的延迟消息功能将命令的发送延迟到需要接收的时间。http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-ccc4f879

于 2013-04-06T15:49:01.903 回答
1

我的建议是选择另一个组件来负责执行期间任务。通过这种方式，您可以决定它的行为方式，并将其与 CQRS 工作人员分开扩展。

如果您希望有 1 个实例在 Azure 中处理这两个任务（定期和 CQRS），您可以将它们转换为 Windows 服务并将您的 Worker 角色用作安装程序和观察者。我在这里有一个使用我的解决方案构建的示例。

顺便说一句，如果您使用 Lokad.Cqrs，那么如果它与主要组件分开，您的第二种方法听起来不错。

于 2013-04-07T18:20:55.970 回答
0

预定的时间流逝是一个事件 - 所以我有一个过程来创建像“ScheduleElapsedEvent”这样的事件。然后，您可以在必要时实现创建/调度命令的处理程序。

您可以将事件时间表保存在支持某种原子更新的数据存储中。那可能是 SQL 或 NoSQL，比如 MongoDB。即使使用副本集和分片进行横向扩展，您仍然可以使用 Mongo 检查和更新记录。所以工作进程可以每个检查这个时间表。

于 2015-03-25T11:32:02.273 回答