我已经创建了一些使用触发器的Azure webjob,我刚刚学习了Azure函数。

根据我的理解,Azure函数似乎与Azure Webjob功能重叠,我很难理解什么时候在函数和Webjob之间做出选择:

Unlike Webjobs, Functions can only be triggered, it hasn't been designed to run continuous process (but you can write code to create a continuous function). You can write Webjobs and Functions using many languages (C#, node.js, python ...) but you can write your function from the Azure portal so it is easier and quicker to develop test and deploy a Function. Webjobs run as background processes in the context of an App Service web app, API app, or mobile app whereas Functions run using a Classic/Dynamic App Service Plan. Regarding the scaling, Functions seems to give more possibilities since you can use a dynamic app service plan and you can scale a single function whereas for a webjob you have to scale the whole web app.

所以肯定有价格差异,如果你有一个现有的web应用程序在运行,你可以用它来运行一个webjob,而没有任何额外的成本,但如果我没有一个现有的web应用程序,我必须写代码来触发一个队列,我应该使用webjob还是函数?

当你需要选择的时候,还有其他需要考虑的因素吗?


当前回答

在应用服务中有几个选项。我不会涉及Logic Apps或Azure Automation,它们也涉及这个领域。

Azure WebJobs

这篇文章是最好的解释,但我还是在这里总结一下。

即按需WebJobs。定时WebJobs。触发WebJobs

触发的webjob是当一个URL被调用或者schedule.job中有schedule属性时运行一次的webjob。Scheduled webjob就是一个创建了Azure Scheduler Job的webjob,用于在调度中调用我们的URL,但我们也支持schedule属性,如前所述。

简介:

+可执行/脚本按需 +计划执行 -必须通过.scm端点触发 -缩放是手动的 —始终需要使用虚拟机

连续WebJobs(非SDK)

这些作业将永远运行,当它们崩溃时,我们将唤醒它们。您需要启用Always On才能使这些工作,这意味着在基本层及以上层运行它们。

简介:

+可执行/脚本始终运行 -需要一直在-基本层及以上 —始终需要使用虚拟机

连续的WebJobs与WebJobs SDK

从“WebJobs的特性”的角度来看,这些都不是什么东西。从本质上讲,我们有这个针对WebJobs编写的甜美SDK,它允许你基于简单的触发器执行代码。稍后我将详细讨论这个问题。

简介:

+可执行/脚本始终运行 +更丰富的日志/仪表板 +触发器支持与长时间运行的任务 -需要一直在-基本层及以上 -缩放是手动设置 -开始可能有点烦人 —始终需要使用虚拟机

Azure WebJobs SDK

Azure WebJobs SDK是一个完全独立于WebJobs平台特性的SDK。它被设计为在WebJob中运行,但实际上可以在任何地方运行。我们有客户在worker角色上运行它们,甚至在prem或其他云上运行,尽管支持只是最好的努力。

SDK只是为了让运行一些响应事件的代码和绑定到服务等变得容易。一件容易的事。老实说,这在一些文档中是最好的,但它的核心是“事件”+“代码”的性质。我们还做了一些很酷的扩展工作,但那是次要的核心目的。

简介:

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

Azure的功能

Azure函数是关于WebJobs SDK的核心目的,将其作为服务托管,并使其易于使用其他语言。我们还在这里介绍了“无服务器”的概念,因为这样做很有意义——我们知道我们的SDK是如何扩展的,所以我们可以为你做智能的事情。

Azure Functions是一个非常严格管理的体验。我们不支持你自带宿主。目前,我们不支持自定义扩展,但我们正在研究。对于你能做什么,不能做什么,我们很有主见,但对于我们能实现的东西,它们很流畅,易于使用和管理。

不过,我们所做的大多数改进函数的“框架”工作都是通过WebJobs SDK完成的。例如,我们将为WebJobs上传一个新的NuGet,它真的大大提高了日志记录的速度,这对WebJobs SDK用户有巨大的性能优势。在将功能作为“WebJobs SDK即服务”发布的过程中,我们确实改进了很多体验问题。

+ Lots of languages supported + Fully managed, dynamic scaling + Easy to use portal w/ UX for managing connections/etc. - Host not customizable (yet) ~ Runs in a separate "app" which requires some configuration in your repo, but makes long term maintenance much easier. ~ No tooling (yet) Some tooling is now in alpha or preview - https://www.npmjs.com/package/azurefunctions (update Feb 2017: Visual Studio Tools for Azure Functions now available in preview: https://blogs.msdn.microsoft.com/webdev/2016/12/01/visual-studio-tools-for-azure-functions/)

我可能有偏见,因为函数是我们最新最好的,但请随意射击更多的缺点函数我的方式。

我可能最终会发表一篇博客来详细阐述,但我试图在这个论坛上保持尽可能简洁。

其他回答

我想谈谈两者之间的共同点和不同点 Azure功能构建在AppService和WebJobs SDK之上。WebJobs SDK将为您提供更多的自由,而Azure功能更加结构化,开发人员的责任更少。

两者都使用面向函数的编程模式, 绑定触发器/输入/输出,支持外部库,并可以在本地运行和调试Supportruntime盥洗工具。

差异

|-----------------------|------------------|
|      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|
--------------------------------------------

对于这个问题,我总能找到一个答案 你可以在Azure WebJobs中自定义主机,但你不能自定义Azure函数的主机。

一个例子是 在WebJob中,可以为外部系统的调用创建自定义重试策略。

这种策略不能在Azure函数中配置。

Azure函数是WebJobs的逻辑继承者。

很少有工作负载比Azure函数更适合WebJobs。例如,需要持续运行或启动成本高的应用程序,甚至那些可以在专用函数配置上运行的应用程序(通过使用持久函数)。

微软自己在这里声明:

Azure Functions offers more developer productivity than Azure App Service WebJobs does. It also offers more options for programming languages, development environments, Azure service integration, and pricing. For most scenarios, it's the best choice. Here are two scenarios for which WebJobs may be the best choice: You need more control over the code that listens for events, the JobHost object. Functions offers a limited number of ways to customize JobHost behavior in the host.json file. Sometimes you need to do things that can't be specified by a string in a JSON file. For example, only the WebJobs SDK lets you configure a custom retry policy for Azure Storage. You have an App Service app for which you want to run code snippets, and you want to manage them together in the same Azure DevOps environment. For other scenarios where you want to run code snippets for integrating Azure or third-party services, choose Azure Functions over WebJobs with the WebJobs SDK.

我想在上面那篇又长又旧的文章上再补充两点。如果在azure函数中选择消费计划,以下是限制

如果您想运行任何超过10分钟的作业,请选择webjobs。Azure函数,默认只运行5分钟,如果您的进程超过5分钟,则Azure函数抛出超时异常。在host.json中可以将超时时间增加到10分钟。

注意:如果您正在使用应用程序服务计划azure函数,则不存在超时问题。

区别对待的另一个原因是。如果使用azure函数,那么初始启动时间将较慢,因为机器(容器)是动态创建的,一旦使用就会销毁。

为了避免冷启动,azure函数应用程序发布了高级计划,其中一个实例将一直运行,根据负载,函数应用程序将开始缩放,您将根据消耗为一个实例和其他实例计费。

在应用服务中有几个选项。我不会涉及Logic Apps或Azure Automation,它们也涉及这个领域。

Azure WebJobs

这篇文章是最好的解释,但我还是在这里总结一下。

即按需WebJobs。定时WebJobs。触发WebJobs

触发的webjob是当一个URL被调用或者schedule.job中有schedule属性时运行一次的webjob。Scheduled webjob就是一个创建了Azure Scheduler Job的webjob,用于在调度中调用我们的URL,但我们也支持schedule属性,如前所述。

简介:

+可执行/脚本按需 +计划执行 -必须通过.scm端点触发 -缩放是手动的 —始终需要使用虚拟机

连续WebJobs(非SDK)

这些作业将永远运行,当它们崩溃时,我们将唤醒它们。您需要启用Always On才能使这些工作,这意味着在基本层及以上层运行它们。

简介:

+可执行/脚本始终运行 -需要一直在-基本层及以上 —始终需要使用虚拟机

连续的WebJobs与WebJobs SDK

从“WebJobs的特性”的角度来看,这些都不是什么东西。从本质上讲,我们有这个针对WebJobs编写的甜美SDK,它允许你基于简单的触发器执行代码。稍后我将详细讨论这个问题。

简介:

+可执行/脚本始终运行 +更丰富的日志/仪表板 +触发器支持与长时间运行的任务 -需要一直在-基本层及以上 -缩放是手动设置 -开始可能有点烦人 —始终需要使用虚拟机

Azure WebJobs SDK

Azure WebJobs SDK是一个完全独立于WebJobs平台特性的SDK。它被设计为在WebJob中运行,但实际上可以在任何地方运行。我们有客户在worker角色上运行它们,甚至在prem或其他云上运行,尽管支持只是最好的努力。

SDK只是为了让运行一些响应事件的代码和绑定到服务等变得容易。一件容易的事。老实说,这在一些文档中是最好的,但它的核心是“事件”+“代码”的性质。我们还做了一些很酷的扩展工作,但那是次要的核心目的。

简介:

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

Azure的功能

Azure函数是关于WebJobs SDK的核心目的,将其作为服务托管,并使其易于使用其他语言。我们还在这里介绍了“无服务器”的概念,因为这样做很有意义——我们知道我们的SDK是如何扩展的,所以我们可以为你做智能的事情。

Azure Functions是一个非常严格管理的体验。我们不支持你自带宿主。目前,我们不支持自定义扩展,但我们正在研究。对于你能做什么,不能做什么,我们很有主见,但对于我们能实现的东西,它们很流畅,易于使用和管理。

不过,我们所做的大多数改进函数的“框架”工作都是通过WebJobs SDK完成的。例如,我们将为WebJobs上传一个新的NuGet,它真的大大提高了日志记录的速度,这对WebJobs SDK用户有巨大的性能优势。在将功能作为“WebJobs SDK即服务”发布的过程中,我们确实改进了很多体验问题。

+ Lots of languages supported + Fully managed, dynamic scaling + Easy to use portal w/ UX for managing connections/etc. - Host not customizable (yet) ~ Runs in a separate "app" which requires some configuration in your repo, but makes long term maintenance much easier. ~ No tooling (yet) Some tooling is now in alpha or preview - https://www.npmjs.com/package/azurefunctions (update Feb 2017: Visual Studio Tools for Azure Functions now available in preview: https://blogs.msdn.microsoft.com/webdev/2016/12/01/visual-studio-tools-for-azure-functions/)

我可能有偏见,因为函数是我们最新最好的,但请随意射击更多的缺点函数我的方式。

我可能最终会发表一篇博客来详细阐述,但我试图在这个论坛上保持尽可能简洁。