Azure Webjobs与Azure功能:如何选择

Question

我创建了一些使用触发器的Azure Webjobs,我刚刚学习了Azure Functions.

根据我的理解,Azure Functions似乎与Azure Webjobs功能重叠,我有一些难以理解何时在Function和Webjob之间进行选择:

• 与Webjobs不同,函数只能被触发,它不是为了运行连续过程而设计的(但您可以编写代码来创建连续函数).

• 您可以使用多种语言编写Webjobs和函数(C#,node.js,python ...),但您可以从Azure门户编写函数,以便更容易,更快地开发测试和部署函数.

• Webjobs在App Service Web应用程序,API应用程序或移动应用程序的上下文中作为后台进程运行,而Function则使用Classic/Dynamic App Service Plan运行.

• 关于缩放,函数似乎提供了更多的可能性,因为您可以使用动态应用程序服务计划,并且您可以扩展单个函数,而对于webjob,您必须扩展整个Web应用程序.

因此,确定存在价格差异,如果您运行现有的Web应用程序,您可以使用它来运行webjob而无需任何额外费用但是如果我没有现有的Web应用程序而且我必须编写代码来触发队列我应该使用webjob还是函数？

您需要选择时还需要记住其他注意事项吗？

Answer 1

App Service中有几个选项.我不会涉及逻辑应用程序或Azure自动化,它也触及这个领域.

Azure WebJobs

这篇文章老实说是最好的解释,但我会在这里总结一下.

随需应变WebJobs又名.预定的WebJobs又名.触发WebJobs

触发的WebJobs是WebJobs,它在调用URL或schedule.job中存在schedule属性时运行一次.计划的WebJobs只是WebJobs,它已创建Azure Scheduler作业以按计划调用我们的URL,但我们也支持schedule属性,如前所述.

摘要:

• + 按需执行/脚本
• + 预定的执行
• - 必须通过.scm端点触发
• - 缩放是手动的
• - 始终需要VM

连续WebJobs(非SDK)

这些工作永远存在,我们会在他们崩溃时将他们唤醒.您需要启用Always On才能使这些工作正常,这意味着在Basic tier及更高版本中运行它们.

摘要:

• + 可执行文件/脚本始终运行
• - 需要始终打开 - 基本级别及以上级别
• - 始终需要VM

使用WebJobs SDK的连续WebJobs

这些都不是"WebJobs特征"的观点.从本质上讲,我们有一个针对WebJobs编写的甜蜜SDK,它允许您基于简单的触发器执行代码.我稍后会谈到这个.

摘要:

• + 可执行文件/脚本始终运行
• + 更丰富的日志/仪表板
• + 支持触发器以及长时间运行的任务
• - 需要始终打开 - 基本级别及以上级别
• - 缩放是手动设置
• - 入门可能有点令人厌烦
• - 始终需要VM

Azure WebJobs SDK

Azure WebJobs SDK是一个与WebJobs完全独立的SDK平台功能.它被设计为在WebJob中运行,但可以在任何地方运行.我们有客户在工作角色甚至是在前台或其他云上运行它们,尽管支持只是尽力而为.

SDK只是简单地运行一些代码以响应某些事件并对服务/等进行绑定.简单.在一些文档中,这实际上是最好的,但它的核心是"事件"+"代码"性质.我们还做了一些很酷的可扩展性工作,但这是次要的核心目的.

摘要:

• 其中大部分都在上面提到过
• +你可以扩展和运行你想要的任何东西.完全控制.
• - HTTP的东西有点不稳定,但它的工作原理

Azure功能

Azure Functions完全是为了实现WebJobs SDK的核心目的,将其作为服务托管,并使其易于使用其他语言.我们还在这里介绍了"无服务器"概念,因为这样做很有意义 - 我们知道我们的SDK如何扩展,因此我们可以为您做智能化的事情.

Azure Functions是一种管理非常丰富的体验.我们不支持自带主机.目前,我们不支持自定义扩展,但我们正在研究它.我们对你能做什么和不能做什么持有不同看法,但对于我们所启用的东西,它们很灵活,易于使用和管理.

但是,我们为改进函数所做的大部分"框架"工作都是通过WebJobs SDK完成的.例如,我们将上传一个新的NuGet for WebJobs,它真正大大提高了日志记录的速度,这对WebJobs SDK用户来说具有巨大的优势.在将功能作为"WebJobs SDK即服务"发布时,我们确实改进了许多体验问题.

• + 支持很多语言
• + 完全管理,动态扩展
• + 易于使用的门户网站,用于管理连接等.
• - 主机无法自定义(尚未)
• ~ 在一个单独的"应用程序"中运行,需要在您的仓库中进行一些配置,但使长期维护更容易.
• ~ 没有工具(还)有些工具现在是alpha或预览 - https://www.npmjs.com/package/azurefunctions(2017年 2月更新:Azure功能的Visual Studio工具现在可用于预览:https://blogs.msdn .microsoft.com/webdev/2016/12/01/visual-studio-tools-for-azure-functions /)

我可能有偏见,因为功能是我们最新和最伟大的,但我可以自由地为我的方式拍摄更多功能.

我可能最终会发布一篇详细阐述的博客,但我试图在这个论坛上尽可能简洁.

Answer 2

作为基于WebJobs SDK的Azure功能,它们提供了WebJobs中已有的大部分功能,但具有一些新的酷炫功能.

在触发器方面,除了已经可用于WebJobs的那些(例如服务总线,存储队列,存储Blob,CRON计划,WebHook,EventHub和文件云存储提供程序)之外,Azure功能可以作为API触发.HTTP调用不需要kudu凭据,但可以通过Azure AD和第三方身份提供程序进行身份验证.

关于输出,唯一的区别是函数可以在通过HTTP调用时返回响应.

两者都支持多种语言,包括:bash(.sh),batch(.bat/.cmd),C#,F#,Node.Js,PHP,PowerShell和Python.

作为目前处于预览状态的功能,工具仍然不理想.但微软正在努力.希望我们在本地开发和测试函数具有相同的灵活性,就像我们目前使用Visual Studio进行WebJobs一样.

通过功能带来的最显著和冷静的优点是具有的替代动态服务计划以"无服务器"的模式,在此我们并不需要管理虚拟机实例或结垢; 这一切都是为我们管理的.此外,由于没有专用实例,我们只需支付实际使用的资源.

这两者之间的比较更详细:https: //blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

Answer 3

根据文档 Azure功能具有以下WebJobs不:

• 自动缩放(CPU和内存根据运行时确定的需求进行缩放)
• 按使用付费定价(消费计划代替应用服务计划)
• 更多触发事件(如WebHooks)
• 浏览器内开发(Visual Studio仍然可以)
• F#支持

简单地说:Azure Functions是更新的动物.如果您还没有App Service计划,我会使用函数,因为从长远来看,我没有看到任何理由为什么从WebJobs开始会更好(尽管函数工具可能不是已经稳定).

Answer 4

我想再补充两点以上的长篇小帖.如果您在天蓝色功能中选择消费计划,则以下是限制

如果您想运行任何超过10分钟的工作,请选择webjobs.Azure函数默认情况下仅运行5分钟,如果您的进程超过5分钟,则azure函数会抛出超时异常.您可以增加超时到在host.json10分钟.

注意:如果您使用的是应用服务计划azure功能,则没有超时问题.

区分的另一个原因是.如果你使用azure函数,那么你的初始启动时间会很慢,因为机器(容器)是动态创建的,一旦使用它就会被销毁.

Answer 5

我知道我要回答这个问题已经很晚了，但是由于这仍然是Google上的热门搜索结果，因此我希望严格从成本角度为该主题提供一些指导，因为操作人员似乎对成本有所担忧。这里已经有一些很棒的答案，它们讨论了技术局限性以及每种服务的工作方式的详细信息，因此，我不再赘述这些答案。

如果您绝对需要一些可以“免费”运行的东西（例如，无需为已经为Web应用程序支付的额外费用），那么您有两种选择：

1. Webjobs-与现有Web应用程序一起部署，并使用与Web应用程序相同的资源。使用Webjobs没有额外的金钱成本，但是如上所述，存在一些限制，这些限制可能导致您的Web应用程序出现性能成本。
2. 功能-使用消费计划时，会分配一定数量的免费执行。在撰写本文时，这个数字实际上是很高的，有100万次免费执行。但是，一百万个执行限制不是可能给您带来麻烦的限制；这是400K GB-s（千兆字节秒）。这基本上是对函数使用的内存量乘以其运行的秒数的计算（请参见定价页面上的官方计算）。您会惊讶于此免费分配很快用完。

如果您担心成本，但不仅限于成本，那么您还有更多选择。

1. 功能-您可以以相对便宜的价格在消费计划或应用服务计划中运行。不过请记住，GB的计费模式。如果您正在使用消费计划并且经常进行“繁重的”工作-您可能会为巨额账单感到惊讶。
2. 云服务-尚未讨论此选项的替代方法，主要是因为OP并未对此进行询问。但这也是一个可行的选择。云服务最终只是在云中运行的VM，因此您可以在其上运行所需的任何后台作业，并且它们可以很好地扩展/缩小（尽管您必须连接自己的执行触发器，与webjob /功能相比，这带来了一些不便）。它们具有更多的相关初始成本（因为无论是否使用实例，您都要按实例付费），但是如果您有需要持续运行的工作并且需要进行大量“繁重”的工作，那么云服务可能是一个更好的选择我认为这是因为管理/监视定价固定的VM比执行和千兆字节秒更容易。

如果您有兴趣阅读一些特定的场景，以及为什么我会选择其中一个（webjobs，functions，cloud services），那么我最近写了一篇关于webjobs vs functions vs cloud services的博客文章。

Answer 6

我想介绍一下构建在 AppService 和 WebJobs SDK 之上的两个 Azure 功能之间的共同点和差异。WebJobs SDK 将为您提供更多的使用自由，而 Azure 功能更加结构化，开发人员的责任更少。

当你看一下共同点时，两者都使用面向函数的编程模式、触发器/输入/输出的绑定、支持外部库并且可以在本地运行和调试Supportruntime Appliances。

差异

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------