c# - 在 Azure 上调整 JPEG 图像大小/缓存

Question

我有一个用 .NET 4.5/MVC 4 编写的网站，允许用户上传图像等。这些图像可以以各种尺寸在整个站点上显示。目前，其工作方式如下:

• 图像已上传并在内存中调整大小，最大宽度为 640 像素(网站将显示的最大宽度)。
• 调整大小后的图像将保存到磁盘的/assets/photos/source/{id}-{timestampash}.jpg。
• 当收到对不同尺寸的图像的请求时，我通过组合 {id}-{hash} 来获取文件名，其中 {hash} 是 ids、高度、宽度和我需要的其他一些信息组合的哈希值获取图像。
• 如果该图像存在于/assets/photos/cache 中，我只需返回它，否则我会使用源图像在内存中创建它，然后将其保存到缓存目录。

我喜欢这种方法，因为它发生得很快，而且一切都发生在内存中或通过磁盘检索。

我希望最终将我的网站迁移到 Azure。如果我的所有图像都存储为 blob，这样的工作流程在 Azure 中会如何发生？使用这样的调整大小/缓存策略仍然有效吗？或者还有其他替代方案吗？当图像从服务器上传到 Azure 时，您不会产生网络延迟吗？今天，它只是保存到磁盘，这显然要快得多？

只是寻找一些有关如何将此类工作流程迁移到 Azure 上可行且可扩展的工作流程的指导。

Answer 1

鉴于您上面的评论，为什么不创建一个后台任务，在上传时将大小调整为所有可接受的大小，并将每个大小存储到 Azure blob 存储中。您是正确的，如果您根据请求调整大小，您会遇到一些延迟和滞后，因为您需要下载源图像，调整大小，然后上传到 blob 存储，然后将用户重定向到您的 blob 存储 url。考虑到 blob 存储的“便宜”，我认为为额外的存储多支付几毛钱将超过上述场景的潜在缓慢。

伪代码如下:

[HttpPost]
public ActionResult FileUpload(HttpPostedBaseFile file){
   if(ValidateFile(file)){
      //fire off a background tasks that resizes and stores each file size to the azure
      //blog storage.  You could use a naming scheme such as id_size.imageTypeExtension
   } 
}

现在，当要求提供文件时，您仍然可以使用相同的例程，但您将返回重定向结果，而不是返回文件结果

public ActionResult GetImage(string hash){
    //do stuff to get image details
    return Redirect("http://yourAzureBlobStorageDomain.com/Assets/Images/Cache/" + imageDetails")
}

这很酷，因为您不需要将图像下载到 Web 服务器然后提供服务，而只需将请求直接重定向到 Blob 存储即可!这会影响如下的图像标签

<img src="@Url.RouteUrl("GetImage", "Images" new {hash = hash})"/>会访问您的 Web 应用程序，强制重定向到 Blob 存储中的实际图像位置。

您不想在 Azure Web 角色上永久存储任何内容，这是正确的，因为 Web 角色可以随时移动，从而丢失任何本地存储的数据。

这只是一种简单的方法，可以通过最少的更改来保持代码库现在的样子。您可以修改它，使其行为更像您现在所拥有的，您可以查询 blob 存储是否存在图像，如果存在，则重定向，如果不存在则生成、存储和重定向，但我相信您会发现您会此时存在更多延迟问题，因为您需要下载源图像，完成您的工作，然后重新上传图像，然后再指示用户浏览器在哪里找到它。

但是，您需要决定是否值得花费额外的时间来按需调整大小，而不是存储每个图像的多个尺寸的成本。附带说明一下，当我们的 Web/ worker 角色使用 Blob 存储时，我们没有注意到明显的延迟问题。显然它比从磁盘检索要高，但它并没有真正带来我们所看到的显着增加。