在应用服务中有几个选项。我不会涉及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 WebJobs中自定义主机，但你不能自定义Azure函数的主机。

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

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

我想谈谈两者之间的共同点和不同点 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没有的功能:

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

简单地说:Azure Functions是较新的动物。如果你还没有应用服务计划，我会选择函数服务，因为从长远来看，我不认为从WebJobs开始会更好(函数工具可能还没有那么稳定)。

作为基于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:)

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

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

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

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

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