以编程方式管理工作者角色的缩放

时间:2015-04-21 13:45:59

标签: azure azure-worker-roles

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

当研究另一种扩展方法时,一个想法是使用工作者角色。我们可以使用Service Bus将带有相关数据的消息传递给Worker Role实例,而不是在当前要求我们使用相当昂贵的定价层的Web应用程序上进行处理,这将执行此处理并发回结果

似乎最经济有效的方法是为每个登录的用户创建一个辅助工作者角色的小实例,这个实例将专门处理他们的请求(例如,使用以后命名的队列)用户的ID),然后在用户会话结束时销毁。

我有代码来确定何时启动实例,如何来回传递这些消息以及何时关闭实例,但是我很难找到任何允许我的方法或API调用的文档很容易做到这一点。我可以找到最接近删除实例的here,但我找不到任何用于创建它们的内容。

在Azure上上下旋转实例的最佳方法是什么?我有哪些替代方案?我也很高兴听到关于如何设计这个问题的其他建议。

2 个答案:

答案 0 :(得分:4)

  

这样做最具成本效益的方法似乎是创建一个   登录的每个用户的辅助角色的小实例,其中   将专门处理他们的请求(例如,使用a   队列以用户的ID命名)然后在用户的时候被销毁   会议结束。

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

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

可能的解决方案

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

答案 1 :(得分:1)

为每个用户使用专用实例并不是一个好主意。利用率较低,成本较高,默认情况下每个订阅的上限为20个CPU核心,因此您必须首先要求支持人员增加配额。

更好的方法是combine the web and worker role into one - 一旦有更多的负载,你就可以扩展它。您仍然可以使用任何方便的方式来存储用户请求 - 队列或其他任何内容。因此角色的IIS将推送数据,“无限循环”部分(角色enrty point Run())将处理数据并存储结果,然后Web服务器将获取结果并将其反馈给用户。