.net - 什么是处理长时间运行任务的良好 API 架构？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我正在尝试实现一个基于 ASP.NET Core 的 Web 服务，该服务将通过 ARM 模板和适用于 .NET 的 Azure SDK 部署 Azure 资源。

事实是，根据我的测试，某些操作最多可能需要三到四分钟才能完成。我没有设计需要这么长时间才能完成某事的 API 的经验。

所以我正在考虑做以下事情。

1. 当 API 收到配置资源的请求时，我会将请求信息放入队列中。
2. 我返回一个带有票号的 200，供调用者监控进度，调用者可以通过调用另一个端点来监控进度。
3. 我使用网络作业创建资源请求，并更新数据库中的信息。
4. 当调用者调用端点以获取有关资源部署进度的反馈时，我现在可以提供更新的信息(成功或失败)。

我不确定这个架构，因为我以前从未做过这样的事情。我正在考虑使用 Azure 队列来组织传入请求，使用 Azure 表来在部署时放置有关请求的信息，并使用 Azure WebJobs 来执行请求的创建。

这是一个足够好的架构吗？或者我应该考虑使用其他技术或模式来做到这一点？我不确定如何处理这种情况，欢迎提供任何意见。

Answer 1

2. 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 ，服务总线为您提供开箱即用的功能。