我已经创建了一些使用触发器的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还是函数?
当你需要选择的时候，还有其他需要考虑的因素吗?
作为基于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功能构建在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函数中选择消费计划，以下是限制
如果您想运行任何超过10分钟的作业，请选择webjobs。Azure函数，默认只运行5分钟，如果您的进程超过5分钟，则Azure函数抛出超时异常。在host.json中可以将超时时间增加到10分钟。
注意:如果您正在使用应用程序服务计划azure函数，则不存在超时问题。
区别对待的另一个原因是。如果使用azure函数，那么初始启动时间将较慢，因为机器(容器)是动态创建的，一旦使用就会销毁。
为了避免冷启动，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.
