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

Question

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

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

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

我期望用户做的是使用我在成功上传文件时给他们的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。