背景
我正在尝试为Azure应用程序设计出最佳结构。我的每个工作角色都会启动多个长期工作。随着时间的推移，我可以将作业从一个实例转移到另一个实例，方法是将它们切换到源实例上的只读模式，在目标实例上将它们旋转，然后在源实例上将原始文件向下旋转。
如果我有太多工作，那么我可以告诉Azure启动额外的角色实例，并将它们用于新的工作。相反，如果我的负载下降（例如在夜间），那么我可以将未完成的工作合并到一些机器上，并告诉Azure给我更少的实例。
麻烦在于（据我所知）Azure没有提供任何机制来允许我决定停止哪个实例。因此，我无法知道要合并到哪些服务器，并且当我的实例停止时，我的一些作业将会死亡，导致用户在生存的实例上重新启动这些作业时会出现延迟。
创意1 ：我决定停止哪个实例，并从Run（）返回。然后我告诉Azure将我的实例数减少一个，并希望它得出结论，破坏的实例是一个很好的候选者。有人试过这样的事吗？
想法2 ：我预定了一大堆不同的工作者角色，内容相同。我可以通过将实例计数从零切换到一个然后再返回来单独停止并启动它们。我认为这个想法会起作用，但我不喜欢它，因为它似乎违背了自然的Azure做事方式，而且因为它涉及我很多额外的簿记来管理额外的工人角色。
创意3 ：与之共存。
有更好的想法吗？
答案 0 :(得分：1)
你是对的 - 你无法选择要停止的实例。通常，您在每个辅助角色实例上运行相同的作业，其中每个实例都监视相同的队列（或者可能是多个线程或多个队列中的作业）。
如果您确实需要在一个实例（例如调度程序）上运行作业，请考虑使用blob leases作为约束它的方法。创建blob作为互斥锁。然后，当每个实例旋转时，调度程序作业尝试获取该blob上的写入租约。如果成功，它就会运行。如果它失败了，它只是睡觉（可能一分钟）并再次尝试。在将来的某个时刻，当您在实例计数中缩小时，假设运行调度程序的实例被终止。一分钟后（或您选择的任何时间跨度），另一个实例尝试获取租约，成功，然后运行调度程序代码。
答案 1 :(得分：1)
回应您的想法
想法1：我没有尝试过你正在描述的内容，但根据我的经验，您的第一个实例的名称以_0结尾，下一个_1，我相信你可以猜到其余的。当您减少实例计数时，它会从具有最大数字后缀的实例中删除。如果它考虑到任何特定实例的状态，我会感到惊讶。
想法2：正如我认为你暗示的那样，这会造成管理问题。每个托管服务只能有5个不同的工作人员，因此您需要为希望能够扩展到的5个角色的每个组提供服务。此外，当您部署更新时，您必须上传X次以上的服务，其中X是您当前支持的最大实例数。
创意3：技术上最简单。在做一些澄清之前，这可能就是我现在要做的事情。为了减少此选项的缺点，可能需要研究更快地加载数据的方法。通常有一个Goldilocks级别（不太多，不是太少）的并行性有助于此。