架构：处理大规模照片上传和调整大小

Question

我有一个系统，用户可以上传大约 16 兆像素的全分辨率图像，从而生成大文件。

目前的方法是：

1. 在 HTTP 请求中接收上传。
2. 在请求中，将原始文件写入 blob 存储
3. 仍在请求范围内，以各种分辨率制作大约 10 个文件副本。 （这些是不同尺寸的缩略图，一些用于 Hi-DPI（视网膜）设备，以及用于全尺寸查看的尺寸。我还将图像转换为 WebP。
4. 然后，我将所有结果传输到不同区域的 blob 存储，以用于私有 CDN。

显然，问题在于，由于这一切都是在 HTTP 请求中完成的，因此它消耗的服务器资源比任何其他典型的 HTTP 请求都要多得多，尤其是当用户开始批量上传图像时，一次有几个用户。如果用户上传大图，内存消耗会急剧增加（我使用ImageMagick.NET进行图像处理）。

这种架构是否更合适：

1. 接收文件上传，写入 blob，向处理队列添加通知，向用户返回成功。
2. 单独的工作服务器接收新文件的通知并开始所有重新调整大小、处理和复制。
3. 我只是将客户端 JavaScript 设置为在几秒钟内不加载图像预览，或者在未找到图像时重试（这意味着图像仍在处理中，但可能很快就会出现） )。

至少这种新方法将更容易扩展，具有更可预测的性能。但是，要处理像照片上传这样“每天”的事情，似乎需要做很多工作。 有更好的方法吗？

我知道新方法遵循与使用外部调整大小服务相同的原则，但我不想在内部执行此操作，因为我担心其中一些第三方服务的隐私。这仍然意味着我必须调整客户端以处理丢失/未处理的图像。

Answer 1

是的，您所描述的是一种更好的方法。这听起来更复杂，但这是大多数可扩展站点处理大负载的方式。将其卸载到队列并让工作人员处理它。

我会为您的第 2 步添加更正：

一个单独的工作服务器监视一个队列，并在出现指示它这样做的消息时开始所有的调整大小、处理和复制。

Answer 2

另一种选择是使用新的网络作业功能。事实上，您的场景似乎很常见（就图像处理而言），它被列为Typical Scenario on MSDN 之一。

图像处理或其他 CPU 密集型工作。网络的一个共同特点 网站是上传图像或视频的能力。通常你想 上传后操纵内容，但您不想制作 用户在您执行此操作时等待。

是否更好，我会留给你决定。