需要更好的方法让 azure api 处理大量数据

如何解决需要更好的方法让 azure api 处理大量数据

我们有Azure http 触发函数应用程序(f1)，它与另一个具有预测算法的http 触发函数应用程序(f2) 对话。 根据函数(f1) 的输入请求大小，函数(f2) 的响应时间会增加很多。 当函数(f2)的响应时间更长时，函数在320秒时超时。

• 我们的要求是提供预测算法作为 服务(f2)

• 将由客户端调用的编排 API(f1) 和 根据客户的输入请求 (f1) 将收集 来自数据库的数据进行数据验证并将数据传递给 (f2) 用于预测

• 预测后 (f2) 会将预测结果回复到 (f1)

• 一旦 (f1) 收到来自 (f2) 的响应，(f1) 就会响应 返回给客户。

我们正在寻找替代的 azure 方法或解决方案 减少 API 的延迟，条件是有 f2 作为一项服务。

解决方法

如果验证用户输入、检索其他数据、将其提供给模型并运行模型本身总共需要 5 分钟以上的时间，您可能需要查看与同步返回响应的 API 不同的东西。

对于这些类型的运行时间，我会推荐一种异步模式，例如 F1 将所有数据存储在 Azure 队列中，F2（队列触发）运行模型并将数据存储在数据库中。请求者可以监视数据库的更新。 F1 花费的时间最多，而不是创建一个将请求存储在队列中的 F0，并使 F1 队列也被触发。

,

如Limits for Http Trigger中所述：

如果使用 HTTP 触发器的函数未在 230 秒内完成，Azure 负载均衡器将超时并返回 HTTP 502 错误。该函数将继续运行，但将无法返回 HTTP 响应。

因此不可能使 f1 和/或 f2 Http 触发。

---

替代方案有很多，但没有一个是同步的（由于上述限制），如果：

• 与最终用户的接口是 REST API 和
• API 由 Http 触发的 Azure 函数提供服务，
• 处理请求所需的时间超过 230 秒。

---

假设：

• 与最终用户的接口是 REST API 和
• API 由 Http 触发的 Azure 函数提供

一种异步可能性是这样的：

PS：我保留了 f1 和 f2，它们的作用与您的设计相同。尽管它们的触发/输出发生了变化。

• 来自 f3 的 Http Triggered REST API 是最终用户触发 job 的入口点。它将发布到队列 q1 并返回 job-id / status-url 作为响应。
• 用户可以使用由 f4 提供的另一个 Http Trigger API 通过 job-id 查询/轮询作业的当前状态/结果。
• f1 和 f2 现在由队列触发器触发
• f1、f2 和 f3 随时更新每个 job-id 的状态到 ADLS（可以是其他任何东西，例如 { {3}} 或 Redis cache 等）。
• f4 不需要单独的函数，它可以作为与 f3 不同的路径/方法。