1

背景

我正在尝试为 Azure 应用程序制定最佳结构。我的每个工人角色都会启动多个长期运行的工作。随着时间的推移，我可以将作业从一个实例转移到另一个实例，方法是在源实例上将它们切换到只读模式，在目标实例上旋转它们，然后在源实例上旋转原始实例。

如果我有太多工作，那么我可以告诉 Azure 启动额外的角色实例，并将它们用于新工作。相反，如果我的负载下降（例如在夜间），那么我可以将未完成的作业合并到几台机器上，并告诉 Azure 给我更少的实例。

问题是（据我了解）Azure 没有提供任何机制让我决定停止哪个实例。因此，我不知道要整合到哪些服务器上，并且我的一些作业会在它们的实例停止时终止，从而导致用户在我在幸存的实例上重新启动这些作业时出现延迟。

想法 1：我决定停止哪个实例，并从它的 Run() 返回。然后我告诉 Azure 将我的实例计数减少 1，并希望它得出结论，损坏的实例是一个很好的候选者。有没有人尝试过这样的事情？

想法2：我预先定义了一大堆不同的工人角色，具有相同的内容。我可以通过将它们的实例计数从零切换到一来单独停止和启动它们，然后再返回。我认为这个想法会奏效，但我不喜欢它，因为它似乎违背了 Azure 的自然做事方式，并且因为它涉及到我需要进行大量额外的簿记来管理额外的工作角色。

想法3：忍受它。

有更好的想法吗？

4

2 回答 2

1

你是对的 - 你不能选择停止哪个实例。通常，您会在每个工作角色实例上运行相同的作业，其中每个实例监视相同的队列（或者可能是多个线程或监视多个队列的作业）。

如果您确实需要在一个实例（例如调度程序）上运行作业，请考虑使用 blob 租约作为限制它的方法。创建一个 blob 作为互斥体。然后，随着每个实例的启动，调度程序作业会尝试获取对该 blob 的写入租约。如果成功，它就会运行。如果失败，它只是休眠（也许一分钟）并再次尝试。在未来的某个时候，当您缩减实例数量时，假设运行调度程序的实例被终止。一分钟后（或您选择的任何时间跨度），另一个实例尝试获取租约，成功，现在运行调度程序代码。

于 2011-03-17T23:41:12.607 回答
1

回应你的想法

想法1： 我没有尝试完全按照您的描述进行操作，但是根据我的经验，您的第一个实例的名称以_0 结尾，下一个_1 ，我相信您可以猜到其余的。当您减少实例计数时，它会丢弃具有最高数字后缀的实例。如果它考虑到任何特定实例的状态，我会感到惊讶。

想法2： 正如我认为你暗示的那样，这将产生管理问题。每个托管服务只能有 5 个不同的工作人员，因此您需要为希望能够扩展到的每组 5 个角色提供一个服务。此外，当您部署更新时，您必须上传 X 倍以上的服务，其中 X 是您当前支持的最大实例数。

Idea 3: Technically the easiest. Pending some clarification, this is probably what I'd be doing for now. To reduce the downsides of this option it may pay to investigate ways of loading the data faster. There is usually a Goldilocks level (not too much, not too little) of parallelism that helps with this.

于 2011-03-18T01:33:19.697 回答