我创建了一些使用触发器的Azure Webjobs，而且我刚刚了解了Azure Functions。
据我了解，Azure Functions 似乎与 Azure Webjobs 功能重叠，我很难理解何时在 Function 和 Webjob 之间进行选择：
与 Webjobs 不同，函数只能被触发，它没有被设计为运行连续的过程（但你可以编写代码来创建一个连续的函数）。
您可以使用多种语言（C#、node.js、python …）编写 Web 作业和函数，但您可以从 Azure 门户编写函数，以便更轻松、更快速地开发测试和部署函数。
Web 作业在应用服务 Web 应用、API 应用或移动应用的上下文中作为后台进程运行，而函数使用经典/动态应用服务计划运行。
关于缩放，Functions 似乎提供了更多可能性，因为您可以使用动态应用服务计划并且可以缩放单个功能，而对于 Web 作业，您必须缩放整个 Web 应用。
因此，肯定存在定价差异，如果您正在运行现有的 Web 应用程序，您可以使用它来运行 Web 作业而无需任何额外费用，但如果我没有现有的 Web 应用程序并且我必须编写代码来触发队列我应该使用网络作业还是函数？
当您需要选择时，是否还有其他需要注意的事项？
应用服务中有几个选项。我不会涉及逻辑应用或 Azure 自动化，它们也涉及这个领域。
这篇文章老实说是最好的解释，但我会在这里总结一下。
触发的 WebJobs 是在调用 URL 或schedule 属性存在于 schedule.job时运行一次的 WebJobs 。Scheduled WebJobs 只是创建了 Azure Scheduler Job 以按计划调用我们的 URL 的 WebJobs，但我们也支持 schedule 属性，如前所述。
概括：
+
-
这些作业永远运行，当它们崩溃时我们会唤醒它们。您需要启用 Always On 才能使它们正常工作，这意味着在基本层及更高层中运行它们。
从“WebJobs 功能”的角度来看，这些都不是什么东西。本质上，我们有一个针对 WebJobs 编写的甜蜜 SDK，它允许您基于简单的触发器执行代码。我稍后会更多地谈论这个。
Azure WebJobs SDK 是一个完全独立于 WebJobs 平台功能的 SDK。它被设计为在 WebJob 中运行，但实际上可以在任何地方运行。我们有客户以工人角色甚至在本地或其他云上运行它们，尽管支持只是最大的努力。
SDK 只是为了让运行一些代码以响应某些事件并绑定到服务/等变得容易。简单的。老实说，这在某些文档中得到了最好的介绍，但它的核心是“事件”+“代码”的性质。我们还做了一些很酷的可扩展性工作，但这是次要的核心目的。
Azure Functions 就是为了实现 WebJobs SDK 的核心目的，将其作为服务托管，并使其易于开始使用其他语言。我们还在这里介绍了“无服务器”的概念，因为这样做很有意义——我们知道我们的 SDK 是如何扩展的，所以我们可以为您做智能的事情。
Azure Functions 是一种非常受管理的体验。我们不支持自带主机。目前，我们不支持自定义扩展，但我们正在调查它。对于您能做什么和不能做什么，我们固执己见，但对于我们启用的功能，它们很流畅，易于使用和管理。
不过，我们为改进 Functions 所做的大部分“框架”工作都是通过 WebJobs SDK 完成的。例如，我们将为 WebJobs 上传一个新的 NuGet，它可以极大地提高日志记录的速度，这对 WebJobs SDK 用户来说具有巨大的性能优势。在将 Functions 作为“WebJobs SDK as a Service”发布时，我们确实改善了很多体验问题。
~
我可能有偏见，因为 Functions 是我们最新最好的，但请随意以我的方式为 Functions 拍摄更多缺点。
我可能最终会发布一个详细说明的博客，但我试图让这个论坛尽可能简洁。
