Azure Webjobs与Azure功能：如何选择

时间：2016-04-13 22:53:02

标签： azure azure-webjobs azure-functions

我创建了一些使用触发器的Azure Webjobs，我刚刚了解了Azure Functions。

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

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

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

  • Webjobs在App Service Web应用程序，API应用程序或移动应用程序的上下文中作为后台进程运行，而Function则使用Classic / Dynamic App Service Plan运行。

  • 关于缩放，函数似乎提供了更多的可能性，因为您可以使用动态应用服务计划，并且您可以扩展单个函数，而对于webjob，您必须扩展整个Web应用程序。

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

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

8 个答案:

答案 0 :(得分：149)

App Service中有几个选项。我不会涉及逻辑应用程序或Azure自动化，它也触及这个领域。

Azure WebJobs

This article老实说是最好的解释，但我会在这里总结一下。

On Demand WebJobs又名。预定的WebJobs又名。触发WebJobs

触发的WebJobs是WebJobs，在调用URL或schedule property is present in schedule.job时运行一次。计划的WebJobs只是WebJobs，它创建了一个Azure Scheduler作业，用于按计划调用我们的URL，但我们也支持schedule属性，如前所述。

要点：

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

连续WebJobs（非SDK）

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

要点：

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

使用WebJobs SDK的连续WebJobs

这些并非来自“WebJobs功能”的观点。从本质上讲，我们有一个针对WebJobs编写的甜蜜SDK，它允许您基于简单的触发器执行代码。我稍后会谈到这个。

要点：

  • +可执行文件/脚本始终在运行
  • +更丰富的日志记录/信息中心
  • +支持触发器和长时间运行的任务
  • -始终需要 - 基本级别及以上
  • -缩放是手动设置
  • -入门可能有点令人厌烦
  • -始终需要VM

Azure WebJobs SDK

Azure WebJobs SDK是一个与WebJobs完全独立的SDK平台功能。它被设计为在WebJob中运行，但可以在任何地方运行。我们有客户使用工作角色甚至是在前期或其他云上运行它们，但支持只是最好的努力。

SDK只是为了简单地运行一些代码以响应某些事件并对服务/等进行绑定。简单。在一些docs中，诚实地说这是最好的，但它的核心是“事件”+“代码”性质。我们还做了一些很酷的可扩展性工作，但这是次要的核心目的。

要点：

  • 上面提到的大部分内容
  • +您可以扩展并运行您想要的任何内容。完全控制。
  • - HTTP内容有点不可思议，但它可以正常工作

Azure功能

Azure功能完全是为了实现WebJobs SDK的核心目的，将其作为服务托管，并使其易于使用其他语言。我们还在这里介绍了“无服务器”概念，因为这样做很有意义 - 我们知道我们的SDK如何扩展，因此我们可以为您做智能事情。

Azure功能是一种管理非常丰富的体验。我们不支持自带主机。目前，我们不支持自定义扩展，但我们正在研究它。我们对于您能做什么和不能做什么持有自己的看法，但对于我们启用的内容，它们很灵活，易于使用和管理。

我们为改进功能所做的大部分“框架”事情都是通过WebJobs SDK完成的。例如，我们将上传一个新的NuGet for WebJobs，它真正大大提高了日志记录的速度，这对WebJobs SDK用户来说具有巨大的优势。在将功能作为“WebJobs SDK即服务”发布时，我们确实改善了许多体验问题。

我可能有偏见，因为函数是我们最新最好的函数，但我可以自由地为函数射出更多的缺点。

我可能最终会发布一篇详细阐述的博客，但我试图尽可能简洁地为这个论坛保留这些博客。

答案 1 :(得分：16)

作为基于WebJobs SDK的Azure功能，它们提供了WebJobs中已有的大部分功能，但具有一些新的酷炫功能。

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

关于输出，唯一的区别是函数可以在通过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：）

答案 2 :(得分：12)

根据docs Azure功能，WebJobs不具备以下功能：

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

简单地说：Azure Functions是最新的动物。如果您还没有应用服务计划，我会使用函数，因为从长远来看，我没有看到任何理由为什么从WebJobs开始会更好（尽管函数工具可能不是那么稳定）。 / p>

答案 3 :(得分：8)

我想再加上两点以上的长篇＆amp;有点老帖子。如果您在天蓝色功能中选择消费计划，则以下是限制

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

注意：如果您使用的是应用服务计划天蓝色功能，则没有超时问题。

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

答案 4 :(得分：3)

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

如果您绝对需要免费运行的东西（因为您已经为网络应用支付的费用没有额外的费用），那么您有两种选择：

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

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

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

如果您有兴趣阅读某些特定情况以及为什么我会选择其中一个（Web作业，功能，云服务），那么我最近在webjobs vs functions vs cloud services上写了一篇博客文章。

答案 5 :(得分：1)

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

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

  

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

答案 6 :(得分：0)

我想给出两者之间的共同点和区别 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|
--------------------------------------------

enter image description here

答案 7 :(得分：0)

我对于这个问题经常发现的一个答案是 您可以自定义Azure WebJobs中的主机，但不能自定义Azure功能的主机，

一个例子是 “在WebJob中，您可以为自定义重试策略创建对外部系统的调用。”

无法在Azure Function中配置这种策略。

相关问题
最新问题