我们正在建立新项目。我们的要求是调用多个 REST API 并聚合响应并将其发送回移动客户端。
我们正在为我们的体验层探索这两个选项(集成) 1.逻辑应用程序 2. Azure 函数
我们观察到两者之间在性能方面存在一个主要差异。
我们通过简单的用例来比较性能。
我们只是调用 REST API 来获取一些具有不同可用选项的指标
与其他选项相比,逻辑应用程序的执行时间更长。下面是调用rest api的简单逻辑应用程序
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"GetReferenceData": {
"inputs": {
"headers": {
"Authorization": "@variables('AuthToken')"
},
"method": "GET",
"uri": "url"
},
"runAfter": {
"Initialize_AuthToken": [
"Succeeded"
]
},
"type": "Http"
},
"Initialize_AuthToken": {
"inputs": {
"variables": [
{
"name": "AuthToken",
"type": "string",
"value": "@{triggerOutputs()['headers']?['Access-Token']}"
}
]
},
"runAfter": {},
"type": "InitializeVariable"
},
"Response": {
"inputs": {
"body": "@body('GetReferenceData')",
"statusCode": "@outputs('GetReferenceData')['statusCode']"
},
"kind": "Http",
"runAfter": {
"GetReferenceData": [
"Succeeded"
]
},
"type": "Response"
},
"Response_2": {
"inputs": {
"body": "@body('GetReferenceData')",
"statusCode": "@outputs('GetReferenceData')['statusCode']"
},
"kind": "Http",
"runAfter": {
"GetReferenceData": [
"Failed",
"Skipped",
"TimedOut"
]
},
"type": "Response"
}
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {
"storageLocation": {
"defaultValue": [],
"type": "Array"
}
},
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"relativePath": "/referenceData",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
},
"parameters": {}
}
我们有很多用例,需要调用多个 REST API 并聚合结果。从上面的数字来看,函数应用程序似乎比函数应用程序做得更好。对于并行操作,我可能比逻辑应用程序更依赖持久函数。
所以我只是想了解为什么逻辑应用程序花费的时间比类似操作的函数花费的时间几乎是两倍?
逻辑应用程序不适合这些操作吗?
请参阅已回答此问题的另一个帖子。 与直接 .NET REST 调用相比,逻辑应用性能是否较慢?
以下添加可能会提供更多见解
“Azure Functions 是由事件触发的code,而逻辑应用程序是由事件触发的workflow 的独立框架。” 逻辑应用程序是可以使用触发器和操作定义的一个工作流的逻辑容器。
逻辑应用程序在 Azure 区域的一组基础架构(数据中心中的 VM)上运行,并且它由多个您不可见的组件组成,因为它被抽象了。通过预配逻辑应用程序,一旦定义工作流并触发该流,您就可以利用该基础设施的一部分(间接通过逻辑应用程序服务)。
Azure Functions 是 Azure Web + Mobile 应用服务套件的一部分,旨在支持创建有意义的、可重用的小块方法,并可以轻松地跨服务共享。
Azure 架构中心的这篇文章可能会为您指明正确的方向:
逻辑应用在不需要低响应延迟的场景中效果最佳,例如异步或半长时间运行的 API 调用。如果需要低延迟,例如在阻止用户界面的调用中,请使用不同的技术。例如,使用 Azure Functions 或部署到 Azure 应用服务的 Web API。
因此,如果移动应用程序将被阻止等待响应,请选择“功能”。
既然这一切都清楚了,让我们把它复杂化回来:有有状态和无状态逻辑应用程序工作流程,无状态的速度更快。
然后,由于您的目标是“调用多个 REST API”,逻辑应用程序的费用可能会由于更复杂的工作流程而增加。
可能最好返回测试板。 :) 我希望得到一些新数字。