我正在考虑重组我正在努力的应用程序,以找到一种可以降低成本并为我们提供更多可扩展性空间的方法。从本质上讲,该应用程序目前作为一个大型Web应用程序托管在Azure上,用户可以登录,对Web应用程序内存中存储的数据执行一些计算成本高昂的工作,然后最终注销。
当研究另一种扩展方法时,一个想法是使用工作者角色。我们可以使用Service Bus将带有相关数据的消息传递给Worker Role实例,而不是在当前要求我们使用相当昂贵的定价层的Web应用程序上进行处理,这将执行此处理并发回结果
似乎最经济有效的方法是为每个登录的用户创建一个辅助工作者角色的小实例,这个实例将专门处理他们的请求(例如,使用以后命名的队列)用户的ID),然后在用户会话结束时销毁。
我有代码来确定何时启动实例,如何来回传递这些消息以及何时关闭实例,但是我很难找到任何允许我的方法或API调用的文档很容易做到这一点。我可以找到最接近删除实例的here,但我找不到任何用于创建它们的内容。
在Azure上上下旋转实例的最佳方法是什么?我有哪些替代方案?我也很高兴听到关于如何设计这个问题的其他建议。
答案 0 :(得分:4)
这样做最具成本效益的方法似乎是创建一个 登录的每个用户的辅助角色的小实例,其中 将专门处理他们的请求(例如,使用a 队列以用户的ID命名)然后在用户的时候被销毁 会议结束。
我不推荐这种方法。以下是我的理由:
可能的解决方案
我可以建议您查看缩放选项,而不是旋转新的辅助角色实例。基本上,这个想法是从一个工作者角色实例的共享池开始。当用户登录并启动任务时,Web角色会在Service Bus队列中写入一条消息,该消息由工作者角色实例出列,该实例执行工作并返回结果。设置工作者角色可以处理的最大任务数。如果超过该计数,请剥离新的辅助角色实例。您可以查看Azure管理门户中提供的自动扩展功能,或查看可以为您执行此扩展的某些第三方服务。
答案 1 :(得分:1)
为每个用户使用专用实例并不是一个好主意。利用率较低,成本较高,默认情况下每个订阅的上限为20个CPU核心,因此您必须首先要求支持人员增加配额。
更好的方法是combine the web and worker role into one - 一旦有更多的负载,你就可以扩展它。您仍然可以使用任何方便的方式来存储用户请求 - 队列或其他任何内容。因此角色的IIS将推送数据,“无限循环”部分(角色enrty point Run()
)将处理数据并存储结果,然后Web服务器将获取结果并将其反馈给用户。