我已经创建了一些使用触发器的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:)
作为基于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|
--------------------------------------------
我意识到我很晚才得到这个答案，但由于这仍然是谷歌上的一个热门搜索结果，我想严格从成本的角度对这个话题提供一些指导，因为似乎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云服务的博客文章。
