【问题标题】:Azure Logic Apps performanceAzure 逻辑应用性能
【发布时间】:2021-05-18 09:09:21
【问题描述】:

我目前正在研究 Azure 逻辑应用程序,但在理解文档以了解我可以预期的性能时遇到了一些麻烦。我也很难找到详细介绍使用逻辑应用的任何真实示例以及所体验到的性能的文章/博客文章。

我试图解决的场景有以下流程:

  1. Http 请求触发逻辑应用
  2. 请求的主体被保存到存储... Cosmos 或 Table Storage
  3. 根据请求正文中的某些值,调用外部 API 而无需关心响应(即发即弃)
  4. 使用适当的响应响应原始 Http 请求(例如,如果步骤 2 和 3 成功,则返回 200 OK)

...所有这些都需要在 1 秒内完成。我不确定每秒进入我的流程的请求数会发生什么,但我假设每秒有 100 个请求。

我想知道是否有人对逻辑应用有一些实际经验,可能正在做类似于我正在查看的事情,以及他们正在体验的性能?我上面概述的可行吗?每秒是否有更多请求的空间?

我考虑过 Azure Functions(可能是 Durable 函数),但我不仅关心性能,还关心冷启动方案,因为我需要我的解决方案实时工作。目前我只是在构建一个 .NET Core API 来封装这个流(以及更多),但我认为 Azure Logic App 可以简化我正在做的事情。

【问题讨论】:

    标签: azure azure-functions azure-logic-apps


    【解决方案1】:

    整体 LogicApps 有点慢,这可能是您不想使用它的原因。为避免在 Functions 中冷启动,您可以使用带有预热实例的高级计划。

    另外,请阅读此主题:

    【讨论】:

    • 感谢您的链接。进一步阅读后,我开始同意您的观点,如果我需要速度,逻辑应用程序可能不是解决方案。我考虑过 Azure Functions 的高级计划选项以避免冷启动,但我觉得我不妨构建一个 .NET Core Web API 并将其托管在 linux 应用程序服务或 Kubernetes 集群上。一旦我开始进入这些价格范围,我不确定 Azure 函数相对于标准 .NET Core Web API 有什么优势?
    • 如果成本几乎相同,请选择更适合您的架构的。 azure 函数是事件驱动的,由于其广泛的绑定和触发器,它为轻松创建集成模式提供了很多可能性。但是,如果您将使用 HTTP,并且想要使用高级版,Azure Functions 的优势就会变得模糊不清。
    猜你喜欢
    • 1970-01-01
    • 2018-12-13
    • 2017-08-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-27
    相关资源
    最近更新 更多