我想谈谈两者之间的共同点和不同点 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函数中配置。

我意识到我很晚才得到这个答案，但由于这仍然是谷歌上的一个热门搜索结果，我想严格从成本的角度对这个话题提供一些指导，因为似乎OP对成本有一些担忧。这里已经有一些关于技术限制和每个服务如何工作的细节的很好的答案，所以我不打算重复这些答案。

如果你确实需要“免费”运行的内容(游戏邦注:即在你已经为网页应用支付的基础上不需要额外费用)，那么你有两个选择:

Webjobs - deployed alongside your existing web app and uses the same resources as your web app. There is no additional monetary cost to use webjobs but there are some limitations as already mentioned that can lead to performance costs on your web app. Functions - When using the consumption plan, you are allotted a certain amount of free executions. The number at the time of this writing is actually quite high, 1 million free executions. However, the 1 million execution limit is not the limit that is likely to give you trouble; it's the 400K GB-s (gigabyte seconds). This is basically a calculation of the amount of memory your function uses multiplied by the number of seconds it runs (see the official calculation on the pricing page here). You will be surprised how quickly this free allotment gets used up.

如果你关心成本，但不局限于完全没有成本，那么你有更多的选择。

Functions - You can run either in the consumption plan or the app service plan for a relatively inexpensive price. Keep in mind though, the GB-s billing model. If you are using the consumption plan and are doing frequent, "heavy" work - you might be surprised with a big bill. Cloud Services - This options hasn't been discussed as an alternative, mainly because the OP didn't ask about it. But this is also a viable option. Cloud services are ultimately just VMs running in the cloud so you can run whatever background jobs you need on them and they scale up/down pretty well (although you have to wire up your own triggers for execution, a slight inconvenience compared to webjobs/functions). They have more initial cost associated with them (because you pay per instance whether you use it or not) but if you have jobs that need to run constantly and are doing a lot of "heavy" lifting, then cloud services might be a better choice because it is easier to manage/monitor a fixed priced VM than executions and gigabyte seconds, in my opinion. The other nice thing about cloud services is that you never have to worry about timeouts or some of the other limitations mentioned in previous answers.

如果你有兴趣阅读一些特定的场景，以及为什么我会选择一个(webjob，函数，云服务)而不是另一个，我最近刚刚写了一篇关于webjob vs函数vs云服务的博客文章。

作为基于WebJobs SDK的Azure函数，它们提供了WebJobs中已有的大部分功能，但还增加了一些很酷的新功能。

在触发器方面，除了那些已经用于webjob的触发器(例如服务总线、存储队列、存储Blobs、CRON调度、WebHooks、eventub和文件云存储提供商)，Azure函数可以作为api被触发。HTTP调用不需要kudu凭据，但可以通过Azure AD和第三方身份提供者进行身份验证。

关于输出，唯一的区别是function在通过HTTP调用时可以返回响应。

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

由于函数目前处于预览状态，工具仍然不理想。但微软正在努力。希望我们能像目前用Visual Studio开发WebJobs一样，在本地灵活地开发和测试函数。

函数带来的最重要和最酷的优势是具有“无服务器”模型的动态服务计划的替代方案，在这种模型中，我们不需要管理VM实例或扩展;一切都为我们安排好了。此外，由于没有专用实例，我们只需为实际使用的资源付费。

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

HTH:)

在应用服务中有几个选项。我不会涉及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函数中选择消费计划，以下是限制

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

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

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

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