控制台应用程序将其作为Web作业触发了Webjob应用程序与Web api应用程序的比较

时间:2019-05-27 21:54:26

标签: azure .net-core azure-webjobs

我有一个Web api(.netcore),我已通过应用程序服务将其托管在Azure中。

我还有一个与上述api相关的应用程序(在同一资源组中),需要每隔几分钟触发一次。

我的困惑是最好的做法?

1)为第二个应用程序编写一个webjob应用程序(.net框架)。

2)将第二个应用程序编写为api,并编写控制台应用程序以调用api。然后从Azure中的webjobs调用控制台应用程序。但这将意味着在同一资源组(用于第二个API)中的第二个应用程序服务。

两者之间有价格差异吗?

一个人比另一个人有优势吗?

还有更好的方法吗?

更新

我选择了第二个选项。

enter image description here

如果我遵循以下内容(成本和代码副)是否有任何优势。所以在同一个应用程序服务中,将有一个wep应用程序,一个Webjob触发api和另一个webjob从队列中读取消息来进行处理

enter image description here

1 个答案:

答案 0 :(得分:0)

有一些选项可用于编写在计时器上触发的服务:

  1. WebJobs-本质上是控制台应用程序,它们在后台运行以完成您的API用户不需要等待的相关工作(照片处理是常见的示例)或需要按计划运行,例如您的用例。
  2. Azure函数-函数类似于WebJob,但是使扩展和抽象化对许多其他服务的连接编码的必要性变得更容易。如果您仅创建运行它们的应用程序服务,它们也可以具有计费优势。
  3. Azure Logic Apps-我想您需要WebJobs或Functions,但是Logic Apps也可以按计划运行作业。在这种情况下,您将在JSON文件中或更可能在GUI中设计工作流。如果您的工作不需要大量的自定义代码,那么使用Logic App意味着可以减少开发时间,并且只需维护一小部分自定义代码即可。

定价:

  • 只要您有足够的资源来处理额外的负载,就可以将Webjobs和Functions都附加到与您的API相同的App Service帐户中。因此,那里没有额外的费用。
  • 如果需要,您可以为Webjob支付单独的App Service帐户费用,但通常它们与API保持在同一App Service帐户中。
  • Functions应用程序可以在具有consumption plan的特殊类型的App Service帐户上运行。这意味着您要支付实际使用的资源,而不是按月支付费用。
  • Logic Apps未连接到App Services,并且具有类似于功能的基于消费的计费。