以编程方式管理工作人员角色的扩展答案

【问题标题】：Manage Scaling of Worker Role Programmatically以编程方式管理工作人员角色的扩展
【发布时间】：2015-06-28 17:19:57
【问题描述】：

我正在研究重组我正在开发的应用程序，以找到一种可以降低成本并为我们提供更多可扩展性空间的方法。从本质上讲，该应用程序目前作为一个大型 Web 应用程序托管在 Azure 上，用户可以登录该应用程序，对存储在 Web 应用程序内存中的数据执行一些计算成本高昂的工作，然后最终注销。

在寻找另一种扩展方式时，一个想法是使用 Worker Roles。我们可以使用 Service Bus 将带有相关数据的消息传递给 Worker Role 实例，而不是在 Web 应用程序上进行处理，这目前需要我们使用相当昂贵的定价层，该实例将执行此处理并发回结果.

看起来最具成本效益的方法是为每个登录的用户创建一个工作角色的小实例，该实例将专门处理他们的请求（例如，使用以用户 ID），然后在用户会话结束时销毁。

我有代码来确定何时启动实例、如何来回传递这些消息以及何时关闭实例，但我很难找到任何允许我使用的方法或 API 调用的文档轻松做到这一点。我能找到的最接近删除实例的描述是 here，但我找不到任何可以创建它们的东西。

在 Azure 上启动和关闭实例的最佳方式是什么？我可以使用哪些替代方案？我也很高兴听到有关如何构建它的替代建议。

【问题讨论】：

标签： azure azure-worker-roles

【解决方案1】：

看起来最经济有效的方法是创建一个每个登录用户的 Worker Role 的小实例，其中将专门处理他们的请求（例如，使用以用户 ID 命名的队列），然后在用户 ID 时销毁会话结束。

我不会推荐这种方法。以下是我的理由：

订阅中的虚拟机内核数量受到限制。想象一个场景，您有 1000 名用户登录到您的应用程序。 Azure 不允许创建 1000 个工作角色实例。您需要获得 Microsoft 的特别许可才能执行此操作。
启动 VM 需要时间。当您为用户创建新的 Worker Role 部署时，它不是即时的。根据您角色的复杂性，启动一个新的 Worker Role 实例可能需要 5 到 10 分钟。
这不是一种有效的方法。您的基本想法是在用户登录时创建一个新的 Worker Role 实例，这是基于用户将执行一些计算密集型任务的假设。如果用户不想执行这个密集的任务怎么办（我在这里可能错了，因为我对您的应用程序了解不多）。然后在这种情况下，您创建了一个无用的 VM 实例。同样，您的假设是用户将始终注销。如果用户只是关闭浏览器怎么办？您将如何检测到该用户已离开您的应用程序并且您需要终止您为该用户创建的辅助角色实例。
这不是一种有效的方法。云计算的整个前提是围绕共享资源构建的。让用户专用的虚拟机听起来不是一种有效的方法。

可能的解决方案

我建议您看一下扩展选项，而不是旋转新的工作角色实例。基本上，这个想法是从 Worker Role 实例的共享池开始。当用户登录并启动任务时，Web 角色会在服务总线队列中写入一条消息，该消息由执行工作并返回结果的工作角色实例出列。设置工作人员角色可以处理的最大任务数。如果您超过该数量，请分拆一个新的工作者角色实例。您可以查看 Azure 管理门户中提供的自动缩放功能，或者查看一些可以为您执行此缩放的第三方服务。

【讨论】：

感谢您提供如此全面的答案。我怀疑由于某些原因这可能不起作用，感谢您对此进行了澄清。所以我对工作角色数量有限的问题是这些工作需要立即开始，这些工作的持续时间可能从几毫秒到几分钟不等。我担心的是，由于单核工作者角色数量有限（试图降低成本），如果同时运行多个长时间运行的作业，其他用户将被有效阻止。抱歉没有更具体地介绍应用程序。
Dan，这就是为什么推荐使用缩放方法的原因。随着越来越多的客户端推送需要由您的工作角色实例完成的工作，队列中将会有更多消息。可以根据消息的数量触发自动缩放。如果消息多于阈值（由您决定），则表明您将需要更多工作角色实例，然后可以相应地扩展您的实例。如果您的任务不是处理密集型的，您可能希望查看 XS 实例而不是小型实例。上次我检查过，您可以以 1 个小型实例的价格拥有 6 个 XS 实例。
XS 节点，您是否引用了此处详述的 A0 节点？ azure.microsoft.com/en-us/pricing/details/cloud-services 如果是这样，我认为每个工作角色至少需要一个专用核心，但最好更多（一些工作将从多线程中受益，而且都是相当密集的过程）。以下听起来是不是一种可行的方法：2 个队列，一个用于发送作业，另一个用于发送结果。工作角色将作业从队列中取出，启动一个任务（未等待）并将消息标记为完成，然后通过事件处理程序在完成时发回消息？
By XS nodes, are you referencing the A0 nodes detailed here? azure.microsoft.com/en-us/pricing/details/cloud-services - 是的。关于你的方法，我认为这是有道理的。在出队时将消息标记为完成可能会很棘手，因为您可能会在处理之间遇到错误，并且该消息永远不会被另一个工作者角色接收。如果我使用的是存储队列，我会将消息隐藏足够长的时间（处理作业所需的时间），然后在作业完成后删除该消息。

【解决方案2】：

为每个用户使用专用实例并不是一个好主意。利用率会很低，成本会很高，并且每个订阅默认有 20 个 CPU 内核的上限，因此您必须首先请求支持以增加配额。

更好的方法是combine the web and worker role into one - 一旦有更多负载进入，您只需将其扩展。您仍然可以使用任何方便的东西来存储用户请求 - 队列或其他任何东西。因此，角色的 IIS 将在那里推送数据，“无限循环”部分（角色 enrty 点 Run()）将处理数据并存储结果，然后 Web 服务器将获取结果并将其反馈给用户。

【讨论】：