问题描述
我们有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 队列也被触发。
,如果使用 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 不同的路径/方法。