背景
我正在尝试为 Azure 应用程序制定最佳结构。我的每个工人角色都会启动多个长期运行的工作。随着时间的推移,我可以将作业从一个实例转移到另一个实例,方法是在源实例上将它们切换到只读模式,在目标实例上旋转它们,然后在源实例上旋转原始实例。
如果我有太多工作,那么我可以告诉 Azure 启动额外的角色实例,并将它们用于新工作。相反,如果我的负载下降(例如在夜间),那么我可以将未完成的作业合并到几台机器上,并告诉 Azure 给我更少的实例。
问题是(据我了解)Azure 没有提供任何机制让我决定停止哪个实例。因此,我不知道要整合到哪些服务器上,并且我的一些作业会在它们的实例停止时终止,从而导致用户在我在幸存的实例上重新启动这些作业时出现延迟。
想法 1:我决定停止哪个实例,并从它的 Run() 返回。然后我告诉 Azure 将我的实例计数减少 1,并希望它得出结论,损坏的实例是一个很好的候选者。有没有人尝试过这样的事情?
想法2:我预先定义了一大堆不同的工人角色,具有相同的内容。我可以通过将它们的实例计数从零切换到一来单独停止和启动它们,然后再返回。我认为这个想法会奏效,但我不喜欢它,因为它似乎违背了 Azure 的自然做事方式,并且因为它涉及到我需要进行大量额外的簿记来管理额外的工作角色。
想法3:忍受它。
有更好的想法吗?