Azure功能与逻辑应用程序

时间:2016-04-02 15:35:01

标签: azure-logic-apps azure-functions

Functions& Logic Apps是Microsoft Azure提供的两种不同产品。我想知道有哪些用例应该支持新功能而不是逻辑应用程序。

8 个答案:

答案 0 :(得分:65)

Azure功能是由事件触发的代码

逻辑应用是由事件触发的工作流程

这意味着它们实际上也是互补的。您可以在昨天的某个时候通过Logic Apps UX在Logic App中添加一个Function作为工作流程的一部分。

TL; DR - 它是逻辑应用+功能,而不是逻辑应用或功能。

答案 1 :(得分:9)

"以下是一些用例,您可以决定在Azure功能和Azure Logic应用程序之间进行选择。

Azure功能:

  1. Azure功能是由事件触发的代码
  2. Azure功能可以在本地工作站上开发和调试,这是一个很大的功能 加上提高开发人员的工作效率
  3. 在处理执行更复杂逻辑的同步请求/响应调用时,Azure函数是首选选项
  4. 逻辑应用

    1. 逻辑应用是由事件触发的工作流程

    2. 逻辑应用仅在云中运行,因为它依赖于Microsoft管理的连接器。它不能在本地调试,测试或运行逻辑应用程序

    3. 逻辑应用程序更适合需要可靠处理的异步集成和即发消息。

    4. Azure Functions具有足够的日志记录和故障排除功能,您甚至可以构建自定义监视工具。功能不依赖于云,它也可以在本地运行。"

答案 2 :(得分:7)

逻辑应用程序用于自动化您的业务流程。它们通过几个开箱即用的连接器轻松实现与云和内部系统的集成。另一方面,Azure函数在响应事件时执行某些操作,例如,当将消息添加到队列或添加blob时,处理这些等等。我猜您甚至可以将Azure功能公开为HTTP API端点并集成使用Logic Apps进入您的业务流程。

我认为另一个显而易见的差异是定价,Azure函数根据用于执行函数的计算以及与函数(https://azure.microsoft.com/en-us/pricing/details/functions/)相关联的内存来收费。

答案 3 :(得分:3)

Azure Durable Functions发布后,这个问题的答案可能已经改变了。 现在两个平台之间的重叠更大。这两种服务都允许您构建无服务器工作流程;虽然Azure Durable Functions是基于代码的工作流程,但Logic Apps是可视化设计的工作流程。

逻辑应用更适合在构建集成解决方案时,因为有大量的连接器可以缩短产品上市时间,并且需要丰富的构建和管理可视化工具。< / p> 如果您需要或者更喜欢具有强大编程语言的所有功能和灵活性,或者您需要更多可移植性,并且可用的绑定和日志记录功能足够,那么

持久功能更适合。

两个平台之间的详细比较是in this post

答案 4 :(得分:1)

Logic Apps是Microsoft提供的iPaas。它可用于在云上创建易于实施的集成解决方案。它配备了一系列开箱即用的连接器,可用于集成On-Premises和基于Can的应用程序的解决方案。 但是,Azure功能可用于在“云”上快速运行少量代码或功能。 Azure功能可与Logic Apps集成,以在Logic Apps中运行代码片段。

答案 5 :(得分:1)

我都广泛使用。对于简单的应用程序/ API,我更喜欢逻辑应用程序而不是Azure函数。逻辑应用程序的知识转移非常容易,因为下一个人只需要看图片。日志/跟踪也已经内置。但是,如果您拥有多个if-else或case条件,或者您具有多个嵌套工作流,则Logic Apps(和Flow)将变得混乱且难以阅读。 Logic Apps中的错误处理也有很多不足之处。

答案 6 :(得分:1)

只想补充我的一些想法

Azure Function应用应用于

  • 高频任务-1,000,000次执行和400,000 GB-s的内存可用,因此价格非常低。知道任何编码语言功能支持后,您就可以以非常低的成本运行数百万个执行。
  • 非常容易与多个Azure服务绑定-而Logic Apps还可以轻松与外部服务绑定,如果您想从逻辑应用中高频地进行操作,则将花费您一两个美元。这些功能还允许轻松地将输入和输出绑定到外部azure服务。
  • 状态执行-使用持久的任务框架,您可以运行多个功能,执行扇入和扇出以及轻松编写状态执行。
  • 编程和脚本语言-如果您已经知道编程语言,那么使用功能可能是将您的某些应用程序迁移到云中的简单方法,而只需很少的更改即可。

Azure Logic应用应用于

  • 低频-这样做的最大原因是定价模式。想象一下,逻辑应用程序中的单个动作是您要付费的,因为它是单独执行。 例如,如果您有 1个具有3个步骤的逻辑应用,并且每10秒运行一次。这将是每分钟18次操作。因此,每小时1080个,每天25920个。如果这3个动作连接到外部任何内容(例如blob / http等),它们都是 connectors ,那么每天运行 26,000个连接器的简单逻辑应用将使您每月> 100美元。与极有可能低于1 $的功能相比。
  • 组合大量外部服务/ API -借助200多个连接器,您可以轻松组合多种服务,而无需学习API等。这是简单的TCO计算,最好是以开发人员的价格编写X数量的API集成,还是只使用开箱即用的连接器。
  • 设计精良的日志记录-使用可视化日志记录,可以非常容易地检查每个执行步骤的输入,输出,时间等。就像您在Azure Functions中记录了每一行一样。
  • 很好地扩展了诸如Data Factory之类的其他服务-一些服务为某些任务而设计得非常好,但在其他任务上却不那么出色。例如,数据工厂无法开箱即用地发送电子邮件,但是您可以在10分钟内从数据工厂为Logic App调用HTTP webhook,然后开始轻松地发送电子邮件。
简而言之,就像其他人所说的那样。他们承担着不同的角色,应照此使用。

通常,逻辑应用❤️功能

如果您想查看一些信息,建议您查看

答案 7 :(得分:0)

天蓝色功能 天蓝色函数是在某些事件或计时器上触发的一段代码 它可以被调试,并且可以使用几种语言进行编码 和几个选项来编写代码,例如Visual Studio Code,Visual Studio,门户内

逻辑应用 这是一个工作流程编排工具,它的触发方式与azure函数类似,但是它是您无法在其中编写代码的拖放工具 它提供了一堆动作来执行主要用于集成系统的功能

这两个系统均基于无服务器架构,但是azure逻辑应用程序易于开发和调试,但范围有限 如果您需要大量自定义的逻辑天蓝色函数