托管长期运行的 Web 服务操作

Question

我正在创建一个 Web 服务来处理文件（这可能很耗时），并且我正在尝试通过确保 Web 服务器不会一次在内存中包含太多文件来证明它的未来。

为了实现这一点，我允许用户上传文件，我立即将其放入 Azure blob 存储，并为用户提供该文件的 ID。

与此同时，文件已在后台添加到处理队列中（由单独的应用程序处理），完成后，会将输出文件添加到 azure 并更新数据库以反映已完成的操作。

我期望用户做的是使用我在他们成功上传文件时给他们的 ID，调用网络服务说“我的文件准备好了吗？如果是，请将其提供给我”。

这是一种可接受的做法吗？

最初我使用它是为了让用户必须等待整个操作完成，这样更简洁，但感觉它的扩展性不是很好。

我的想法是，如果我将文件处理组件从请求中分离出来，并且文件进入处理队列，它可能会立即得到处理，但也可能需要几分钟（取决于网络的繁忙程度服务获取 - 最坏的情况，如果我不实施自动缩放可能需要几个小时），并且我担心让 Web 请求可能会停留很长时间。

我是否过度设计了这个，或者这是一个明智的方法？

Answer 1

这是一个非常明智的做法。事实上，REST 专门通过 202 Accepted 响应代码来解决这个问题。

更多详情请见Asynchronous REST。

总结一下：

1. 当用户提交原始请求时，不要只给他们一个文件ID，返回状态码202 Accepted并将Location头设置为他们可以轮询以获得请求状态的临时资源的URI
   1. 此临时资源的正文可能包含待完成的 ETA，或者只是“正在进行中”
2. 请求完成后，此 URI 应返回 303 See Other，并将 Location Header 设置为他们可以实际获取文件的 URI。