工作者角色与Web作业

atr*_*eon 66 azure azure-worker-roles azure-webjobs

根据我的理解,在云中运行小的可重复任务.

我可以选择哪种原因以及在什么情况下选择其中一种?

kwi*_*ill 81

一些基本信息:

WebJobs适用于轻量级工作项,它们不需要对它们运行的​​环境进行任何自定义,也不会占用太多资源.它们也非常适合只需要定期运行,计划或触发的任务.它们便宜且易于设置/运行.它们在您的网站环境中运行,这意味着您获得与您的网站运行相同的环境,并且他们使用的任何资源都是您的网站无法使用的资源.

工作者角色适用于更多资源密集型工作负载,或者您需要修改运行它们的环境(即特定的.NET框架版本或安装到操作系统中的某些内容).工作者角色更昂贵,设置和运行稍微困难,但它们提供更多的功率.

一般情况下,我会从WebJobs开始,如果您发现您的工作负载需要的工作量超过WebJobs可以提供的数量,那么请转到工作者角色.

  • 很高兴知道......即使我处理云服务(Web角色),我也可以从webjob开始进行后台处理(轻量级),然后根据需要切换到workerrole.WorkerRole不一定总是默认选择.由于工作者角色与云服务模板一起出现,并且Web作业是另一回事(从模板角度来看),这可能不是太明显.谢谢! (2认同)

Jai*_*osa 21

如果我们要将"功率"测量为计算能力,那么在虚拟环境中,这将转化为物理机器(金属)顶部有多少层.虚拟机上的用户代码运行在管理物理机的管理程序之上.这是最厚的一层.只要有可能,管理程序就会尝试简单地作为金属的传递.

WebJobs的开销基本上很小.它是沙盒,操作系统维护,并有服务和模块,以确保它运行.但是应用程序代码基本上与工作者角色中的金属一样接近,因为它们使用相同的管理程序.

如果您想要衡量的是"灵活性",那么使用工作者角色,因为它不是托管或沙盒,它更灵活.您可以使用更多套接字,定义自己的环境,安装更多软件包等.

如果您想要的是"功能",那么WebJobs具有完整的功能.包括虚拟网络到本地资源,登台环境,远程调试,触发,调度,轻松连接到存储和服务总线等......

大多数人都希望专注于解决他们的问题,而不是在基础设施上投入时间.为此,您使用WebJobs.如果您确实发现需要更多灵活性,或者安全沙箱阻止您执行任何其他方式无法完成的操作,请转到"工作者角色".

甚至可以构建混合解决方案,其中某些部分在WebJobs中完成,而其他部分在工作者角色中完成,但这不在本问题的范围内.(提示:WebJobs SDK)


Kar*_*sen 11

选择使用Web作业或工作者角色时要记住的事项:

  • 工作者角色自托管在专用VM上,Web作业托管在Web App容器中.

  • 工作者角色将独立扩展,Web作业将与Web App容器一起扩展.

Web Jobs非常适合轮询RSS提要,检查和处理消息以及发送通知,它们比工作者角色更轻便,但功能更低.