我已经创建了一些使用触发器的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还是函数?
当你需要选择的时候，还有其他需要考虑的因素吗?
我想在上面那篇又长又旧的文章上再补充两点。如果在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.
我想谈谈两者之间的共同点和不同点
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云服务的博客文章。
我想在上面那篇又长又旧的文章上再补充两点。如果在azure函数中选择消费计划，以下是限制
如果您想运行任何超过10分钟的作业，请选择webjobs。Azure函数，默认只运行5分钟，如果您的进程超过5分钟，则Azure函数抛出超时异常。在host.json中可以将超时时间增加到10分钟。
注意:如果您正在使用应用程序服务计划azure函数，则不存在超时问题。
区别对待的另一个原因是。如果使用azure函数，那么初始启动时间将较慢，因为机器(容器)是动态创建的，一旦使用就会销毁。
为了避免冷启动，azure函数应用程序发布了高级计划，其中一个实例将一直运行，根据负载，函数应用程序将开始缩放，您将根据消耗为一个实例和其他实例计费。
