4

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

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

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

我想最终将我的网站移动到 Azure。考虑到我的所有图像都将存储为 blob，这样的工作流将如何在 Azure 中发生？使用这样的调整大小/缓存策略是否仍然有效，还是有其他选择？当图像从今天的服务器上传到 Azure 时，您不会产生网络延迟，它只是被保存到磁盘，这显然要快得多？

只是寻找一些关于如何将这样的工作流迁移到 Azure 的可行和可扩展的方向。

4

1 回答 1

4

鉴于您在上面的评论，为什么不创建一个后台任务，在上传时将大小调整为所有可接受的大小，并将每个任务存储到 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 存储时，我们没有注意到明显的延迟问题。显然它高于从磁盘中检索，但它并没有真正构成我们能够看到的显着增加。

于 2013-04-18T01:38:55.117 回答