Azure Webjobs 与 Azure Functions:如何选择 [英] Azure Webjobs vs Azure Functions : How to choose

问题描述

我创建了一些使用触发器的 Azure Webjobs，我刚刚了解了 Azure 函数.

I've created some Azure Webjobs that use triggers and I've just learnt about Azure Functions.

据我所知，Azure Functions 似乎与 Azure Webjobs 功能重叠，我很难理解何时在 Function 和 Webjob 之间进行选择:

From what I understand Azure Functions seem to overlap with Azure Webjobs features and I have some difficulty to understand when to choose between Function and Webjob:

• 与 Webjobs 不同，Functions 只能被触发，它没有被设计为运行连续过程(但您可以编写代码来创建连续函数).

• 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).

您可以使用多种语言(C#、node.js、python ...)编写 Webjobs 和函数，但您可以从 Azure 门户编写函数，以便更轻松、更快速地开发测试和部署函数.

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 在应用服务 Web 应用、API 应用或移动应用的上下文中作为后台进程运行，而 Functions 使用经典/动态应用服务计划运行.

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.

关于扩展，Functions 似乎提供了更多的可能性，因为您可以使用动态应用服务计划并且您可以扩展单个功能，而对于网络作业，您必须扩展整个 Web 应用.

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.

所以肯定有价格差异，如果你有一个现有的网络应用程序运行，你可以使用它来运行一个网络作业而无需任何额外费用，但如果我没有一个现有的网络应用程序并且我必须编写代码来我应该使用网络作业还是函数来触发队列?

So for sure there is a pricing difference, if you have an existing web app running you can use it to run a webjob without any additional cost but if I don't have an existing web app and I have to write code to trigger a queue should I use a webjob or a Function ?

当您需要选择时，还有其他需要注意的事项吗?

Is there any other considerations to keep in mind when you need to choose ?

推荐答案

在应用服务中有几个选项.我不会涉及逻辑应用或 Azure 自动化，它们也涉及这个领域.

There are a couple options here within App Service. I won't touch on Logic Apps or Azure Automation, which also touch this space.

这篇文章是老实说是最好的解释，但我会在这里总结一下.

This article is honestly the best explanation, but I'll summarize here.

触发的 WebJobs 是在调用 URL 或 schedule 属性存在于 schedule.job 中.Scheduled WebJobs 只是创建了 Azure Scheduler Job 以按计划调用 URL 的 WebJobs，但我们也支持 schedule 属性，如前所述.

Triggered WebJobs are WebJobs which are run once when a URL is called or when the schedule property is present in schedule.job. Scheduled WebJobs are just WebJobs which have had an Azure Scheduler Job created to call our URL on a schedule, but we also support the schedule property, as mentioned previously.

总结:

• + 按需执行/脚本
• + 预定执行
• - 必须通过 .scm 端点触发
• - 缩放是手动的
• - 虚拟机总是需要的

• + Executable/Script on demand
• + Scheduled executions
• - Have to trigger via .scm endpoint
• - Scaling is manual
• - VM is always required

这些作业永远运行，我们会在它们崩溃时唤醒它们.您需要启用 Always On 才能使它们正常工作，这意味着在基本层及更高层中运行它们.

These jobs run forever and we will wake them up when they crash. You need to enable Always On for these to work, which means running them in Basic tier and above.

总结:

• + 可执行文件/脚本始终运行
• - 需要始终开启 - 基本层及以上
• - 虚拟机总是需要的

• + Executable/Script always running
• - Requires always on - Basic tier and above
• - VM is always required

从WebJobs 功能"的角度来看，这些都不算什么.本质上，我们有这个针对 WebJobs 编写的甜蜜 SDK，它可以让您基于简单的触发器执行代码.稍后我会详细讨论这个.

These aren't anything from a "WebJobs the feature" point of view. Essentially, we have this sweet SDK we wrote targeting WebJobs which lets you execute code based on simple triggers. I'll talk about this more later on.

总结:

• + 可执行文件/脚本始终运行
• + 更丰富的日志记录/仪表板
• + 触发器支持长时间运行的任务
• - 需要始终开启 - 基本层及以上
• - 缩放是手动设置的
• - 入门可能有点累
• - 虚拟机总是需要的

• + Executable/Script always running
• + Richer logging/dashboard
• + Triggers supported along with long running tasks
• - Requires always on - Basic tier and above
• - Scaling is manual to set up
• - Getting started can be a bit tiresome
• - VM is always required

Azure WebJobs SDK 是一个完全独立于 WebJobs 平台功能的 SDK.它旨在在 WebJob 中运行，但实际上可以在任何地方运行.我们的客户以工人角色，甚至在本地或其他云上运行它们，尽管支持只是尽力而为.

Azure WebJobs SDK is a completely separate SDK from WebJobs the platform feature. It's designed to be run in a WebJob, but can really be run anywhere. We have customers who run them on worker roles and even on prem or other clouds, though support is only best effort.

SDK 只是让运行一些代码以响应某些事件并绑定到服务/等变得容易.简单.老实说，这在一些 文档中得到了最好的介绍，但它的核心是事件"+代码"性质.我们还做了一些很酷的可扩展性工作，但这对于核心目的来说是次要的.

The SDK is just about making it easy to run some code in reaction to some event and make binding to services/etc. easy. This is honestly best covered in some docs, but the heart of it is that "event" + "code" nature. We've also done some cool extensiblity work, but that's secondary to the core purpose.

总结:

• 以上大部分都提到了
• + 你可以扩展和运行你想要的任何东西.完全控制.
• - HTTP 的东西有点不稳定，但它有效

• Most of these are mentioned above
• + You can extend and run whatever you want. Full control.
• - HTTP stuff is a little wonky, but it works

Azure Functions 旨在实现 WebJobs SDK 的核心目的，将其作为服务托管，并使其他语言的入门变得容易.我们还在这里介绍了无服务器"概念，因为这样做很有意义 - 我们知道我们的 SDK 如何扩展，因此我们可以为您做一些智能的事情.

Azure Functions is all about taking that core purpose of the WebJobs SDK, hosting it as a service, and making it easy to get started with other languages. We also introduce the "Serverless" concept here because it made a lot of sense to do so - we know how our SDK scales, so we can do intelligent things for you.

Azure Functions 是一种管理繁重的体验.我们不支持自带主机.目前，我们不支持自定义扩展，但我们正在研究它.我们对您能做什么和不能做什么有自己的看法，但对于我们实现的功能，它们非常流畅，易于使用和管理.

Azure Functions is a very heavily managed experience. We aren't supporting bringing your own host. Currently, we don't support custom extensions but its something we're investigating. We're opinionated about what you can and can't do, but for the things we enable, they are slick, and easy to use and manage.

不过，我们为改进 Functions 所做的大部分框架"工作都是通过 WebJobs SDK 完成的.例如，我们将为 WebJobs 上传一个新的 NuGet，它确实大大提高了日志记录速度，这对 WebJobs SDK 用户具有巨大的性能优势.在将函数作为WebJobs SDK 即服务"交付时，我们确实改进了很多体验问题.

Most of the "framework" things we've done to improve Functions go through the WebJobs SDK, though. For instance, we'll be uploading a new NuGet for WebJobs which really drastically increases the speed of logging, which has huge perf benefits for WebJobs SDK users. In shipping Functions as "WebJobs SDK as a Service" we've really improved a lot of experience issues.

• + 支持多种语言
• + 完全托管的动态扩展
• + 易于使用的门户，带有 UX 用于管理连接等.
• - 主机不可定制(尚)
• ~ 在单独的应用程序"中运行，这需要在您的存储库中进行一些配置，但可以更轻松地进行长期维护.
• ~ 没有工具(还) 一些工具现在是 alpha 或预览版 - https://www.npmjs.com/package/azurefunctions(2017 年 2 月更新:Azure Functions 的 Visual Studio 工具现已提供预览版:https://blogs.msdn.microsoft.com/webdev/2016/12/01/visual-studio-tools-for-azure-functions/)

• + 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/)

我可能有偏见，因为 Functions 是我们最新和最好的，但请随时按照我的方式为 Functions 拍摄更多的缺点.

I'm probably biased since Functions is our latest and greatest, but feel free to shoot more cons for Functions my way.

我可能最终会发布一个详细说明的博客，但我尽量在本论坛中保持简洁.

I'll probably end up publishing a blog which elaborates a bit more, but I tried to keep this as succinct as possible for this forum.

这篇关于Azure Webjobs 与 Azure Functions:如何选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！