Azure Webjobs与Azure Functions：如何选择

我已经创建了一些使用触发器的Azure Webjob，并且我刚刚了解了Azure Functions。

据我了解，Azure功能似乎与Azure Webjobs功能重叠，并且我很难理解何时在Function和Webjob之间进行选择：

• 与Webjobs不同，Functions只能被触发，而不能被设计为运行连续过程（但是您可以编写代码来创建连续函数）。

• 您可以使用多种语言（C＃，node.js，python ...）编写Webjobs和Functions，但是您可以从Azure门户编写函数，因此可以更轻松快捷地开发测试和部署Function。

• Webjob在App Service Web应用程序，API应用程序或移动应用程序的上下文中作为后台进程运行，而“功能”使用经典/动态App Service计划运行。

• 关于扩展，“功能”似乎提供了更多的可能性，因为您可以使用动态应用程序服务计划，并且可以扩展单个功能，而对于Web作业，则必须扩展整个Web应用程序。

因此，可以肯定存在价格差异，如果您正在运行现有的Web应用程序，则可以使用它来运行Webjob，而无需支付任何额外费用，但是如果我没有现有的Web应用程序，并且必须编写代码以触发队列我应该使用webjob还是Function？

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

App Service中有几个选项。我不会涉及Logic Apps或Azure Automation，它们也会涉及这个领域。

Azure Web作业

老实说，这篇文章是最好的解释，但这里我将进行总结。

按需WebJobs又名。预定的WebJobs。触发的Web作业

触发的WebJob是WebJob，它们在调用URL或schedule.job中存在schedule属性时运行一次。计划的WebJob只是创建了Azure计划程序作业以按计划调用我们的URL的WebJob，但是我们也支持schedule属性，如前所述。

摘要：

• + 可执行文件/按需脚本
• + 预定执行
• - 必须通过.scm端点触发
• - 缩放是手动的
• - 始终需要VM

连续Web作业（非SDK）

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

摘要：

• + 可执行文件/脚本始终运行
• - 要求始终在线-基本层及以上
• - 始终需要VM

使用WebJobs SDK的连续WebJobs

从“ WebJobs功能”的角度来看，这些都不是什么。本质上，我们有针对WebJobs编写的这个甜美的SDK，可让您基于简单的触发器执行代码。我将在以后再讨论。

摘要：

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

Azure WebJobs SDK

Azure WebJobs SDK是与WebJobs平台功能完全独立的SDK。它旨在在WebJob中运行，但实际上可以在任何地方运行。我们的客户是根据工作人员角色甚至是Prem或其他云运行它们的，尽管支持只是最大的努力。

SDK旨在简化响应某些事件的代码并绑定到services / etc的过程。简单。老实说，最好在某些文档中介绍，但这的核心是“事件” +“代码”性质。我们还做了一些很酷的可扩展性工作，但这是核心目的的第二要务。

摘要：

• 上面提到了大多数
• +您可以扩展并运行所需的任何内容。完全控制。
• - HTTP东西有点古怪，但是可以用

Azure功能

Azure Functions就是为了实现WebJobs SDK的核心目的，将其作为服务托管，并使其易于开始使用其他语言。我们还在这里引入“无服务器”概念，因为这样做非常有意义-我们知道我们的SDK如何扩展，因此我们可以为您做一些明智的事情。

Azure Functions是一种非常受管理的体验。我们不支持自己带房东。当前，我们不支持自定义扩展，但我们正在调查它。我们对您可以做和不能做的事情持保留意见，但是对于我们启用的功能，它们很精巧，易于使用和管理。

不过，我们为改进功能所做的大多数“框架”工作都是通过WebJobs SDK进行的。例如，我们将上传一个新的NuGet for WebJobs，它确实可以大大提高日志记录的速度，这对于WebJobs SDK用户而言具有巨大的性能优势。在将功能作为“ WebJobs SDK即服务”发布时，我们确实改善了很多体验问题。

• + 支持多种语言
• + 全面管理的动态扩展
• + 带有UX的易于使用的门户网站，用于管理连接等。
• - 主机不可自定义（尚未）
• ~ 在一个单独的“应用程序”中运行，该应用程序需要在您的存储库中进行一些配置，但使长期维护变得更加容易。
• ~ 没有工具（但）现在有些工具是α或预览- https://www.npmjs.com/package/azurefunctions （更新2017年2月：Visual Studio工具现在预览可用Azure的功能：HTTPS：//blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-functions /）

由于Functions是我们的最新也是最伟大的产品，所以我可能有偏见，但是请随时为Functions拍摄更多缺点。

我可能最终会发布一个博客，其中详细介绍了一些内容，但是我试图使这个论坛尽可能简洁。

作为基于WebJobs SDK的Azure功能，它们提供了WebJobs中已经可用的大多数功能，但是具有一些新的很酷的功能。

就触发器而言，除了已可用于WebJob的触发器（例如，服务总线，存储队列，存储Blob，CRON计划，WebHooks，EventHub和文件云存储提供程序）之外，还可以将Azure函数作为API进行触发。HTTP调用不需要kudu凭据，但可以通过Azure AD和第三方身份提供程序进行身份验证。

关于输出，唯一的区别是，函数可以通过HTTP调用时返回响应。

两者都支持多种语言，包括：bash（.sh），批处理（.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 Functions具有WebJobs不具备的功能：

• 自动缩放（根据运行时确定的需求缩放CPU和内存）
• 按使用付费定价（使用消费计划代替App Service计划）
• 更多触发事件（例如WebHooks）
• 浏览器内开发（仍可以使用Visual Studio）
• F＃支持

简而言之：Azure Functions是更新的动物。如果您还没有App Service计划，那么我会选择使用Functions，因为从长远来看，我看不出从任何原因开始使用WebJobs会更好的原因（尽管功能工具可能还不那么稳定）。

我想在以上冗长的旧帖子中再添加两个点。如果您在天蓝色功能中选择了消费计划，则以下是限制

如果您要运行超过10分钟的任何作业，请选择webjobs。Azure函数，默认情况下仅运行5分钟，如果您的过程超过5分钟，则Azure函数将引发超时异常。您可以增加超时到在host.json10分钟。

注意：如果您使用的是应用服务计划天蓝色函数，则不会出现超时问题。

区分的另一个原因是。如果使用天蓝色函数，则初始启动时间会很慢，因为机器（容器）是动态创建的，一旦使用就会被销毁。

为了避免冷启动，Azure功能应用程序已发布高级计划，其中一个实例将一直运行，并且根据负载，功能应用程序将开始扩展，并且将根据使用情况为一个实例和其他实例计费。

我知道我要回答这个问题已经很晚了，但是由于这仍然是Google上的热门搜索结果，因此我希望严格从成本角度为该主题提供一些指导，因为操作人员似乎对成本有所担忧。这里已经有一些很棒的答案，它们讨论技术限制以及每种服务的工作原理的详细信息，因此，我不再赘述这些答案。

如果您绝对需要可以“免费”运行的产品（例如，无需为已经为Web应用程序支付的任何费用），则有两种选择：

1. Webjobs-与现有Web应用程序一起部署，并使用与Web应用程序相同的资源。使用webjobs没有额外的金钱成本，但是如上所述，存在一些局限性，这可能会导致web应用程序的性能成本下降。
2. 功能-使用消费计划时，会分配一定数量的免费执行。在撰写本文时，这个数字实际上是很高的，有100万次免费执行。但是，一百万个执行限制并不是可能给您带来麻烦的限制；这是400K GB-s（千兆字节秒）。这基本上是对函数使用的内存量乘以其运行的秒数的计算（请参阅此处的定价页面上的官方计算）。您会惊讶于此免费分配很快用完。

如果您担心成本，但不仅仅限于成本，那么您还有更多选择。

1. 功能-您可以以相对便宜的价格在消费计划或应用服务计划中运行。不过请记住，GB的计费模式。如果您正在使用消费计划并且经常进行“繁重的”工作-您可能会为巨额账单感到惊讶。
2. 云服务-尚未讨论此选项的替代方法，主要是因为OP并未对此进行询问。但这也是一个可行的选择。云服务最终只是在云中运行的VM，因此您可以在其上运行所需的任何后台作业，并且它们可以很好地扩展/缩小（尽管您必须连接自己的执行触发器，与webjobs /功能相比，不便之处）。它们具有更多的相关初始成本（因为无论是否使用实例，您都要按实例付费），但是如果您有需要持续运行的工作并且正在做很多“繁重的”工作，那么云服务可能是一个更好的选择我认为这是因为管理/监视定价固定的VM比执行和千兆字节秒更容易。

如果您有兴趣阅读一些特定的场景，以及为什么我会选择其中一个（webjobs，functions，cloud services），那么我最近写了一篇关于webjobs vs functions vs cloud services的博客文章。

一个主要考虑因素是，Azure Functions退出了对第1版之后的完整.NET Framework的支持，该版本随v2.0一起终止，并且在现在的预览版v3.0中不会更改。😔

• 文档在此处明确说明了这一点，

• 就像这个反馈响应一样，

• 以及这个github问题/回应。

同时，幸运的是，这种强大的武装方法尚未应用于Azure WebJobs：

WebJobs SDK的3.x版本支持.NET Core和.NET Framework控制台应用程序。

我想说明两个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|
--------------------------------------------