我正在尝试实现一个基于 ASP.NET Core 的 Web 服务,该服务将通过 ARM 模板和适用于 .NET 的 Azure SDK 部署 Azure 资源。
事实是,根据我的测试,某些操作最多可能需要三到四分钟才能完成。我没有设计需要这么长时间才能完成某事的 API 的经验。
所以我正在考虑做以下事情。
- 当 API 收到配置资源的请求时,我会将请求信息放入队列中。
- 我返回一个带有票号的 200,供调用者监控进度,调用者可以通过调用另一个端点来监控进度。
- 我使用网络作业创建资源请求,并更新数据库中的信息。
- 当调用者调用端点以获取有关资源部署进度的反馈时,我现在可以提供更新的信息(成功或失败)。
我不确定这个架构,因为我以前从未做过这样的事情。我正在考虑使用 Azure 队列来组织传入请求,使用 Azure 表来在部署时放置有关请求的信息,并使用 Azure WebJobs 来执行请求的创建。
这是一个足够好的架构吗?或者我应该考虑使用其他技术或模式来做到这一点?我不确定如何处理这种情况,欢迎提供任何意见。
最佳答案
- I return a 200 with a ticket number for the caller to monitor the progress, which the caller can to by calling another endpoint.
返回一个202 Accepted
,以明确表示“嘿,我有你的东西,我稍后再处理”。
返回包含结果的 Location
header ,而不是票号,如果您大致了解客户端何时应该“回电”,请添加 Retry-after
header ”。
客户端,当位置 URL 不再返回 404 时,客户端 UI 应尝试呈现结果,或者(如果没有 UI)启动处理这些结果的任何逻辑。
I'm thinking of using Azure Queues to organize the incoming requests [...]
我赞同这个决定。否则,您将只是从头开始重新实现持久性、重试和不良参与者处理,而且我们都知道最好的代码是别人的代码。
使用 Azure 队列,您需要 implement your own poison message logic ,服务总线为您提供开箱即用的功能。
关于.net - 什么是处理长时间运行任务的良好 API 架构?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51814041/