Question

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

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

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

我想最终将我的网站移至Azure。考虑到我的所有图像都将存储为blob，Azure会如何发生这样的工作流程？使用像这样的重新调整大小/缓存策略还是有其他替代方案仍然有效吗？您是否会因为图像从服务器上传到Azure而导致网络延迟，现在它只是保存到磁盘，这显然要快得多？

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

Answer 1

根据上面的评论，为什么不创建一个后台任务，在上传时调整大小到所有可接受的大小，将每个大小存储到Azure blob存储中。你是正确的，如果你根据要求调整大小，你会遇到一些延迟和滞后，因为你需要下载源图像，调整大小，然后上传到blob存储，然后将用户重定向到你的blob存储网址。鉴于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})"/>会点击您的网络应用程序，强制重定向到blob存储中的实际图像位置。

您是正确的，您不希望永久存储Azure Web角色，因为Web角色可以随时移动，丢失任何本地存储的数据。

这只是一种简单的方法，可以按照现在的方式保持代码库的最小化。您可以将其修改为更像现在的行为，如果图像存在，您可以查询blob存储，如果存在，重定向，如果它不生成，存储和重定向，但我相信你会发现你会考虑到你需要下载源图像，做你的东西，然后在指示用户的浏览器去哪里找到它之前重新上传图像，这里有更多的延迟问题。

然而，这将是您决定是否值得按需调整大小所需的额外时间与存储每个图像的多个尺寸的成本相关的事情。作为旁注，我们没有注意到从我们的Web /辅助角色使用blob存储时出现严重的延迟问题。显然它比从磁盘中检索要高，但它并没有真正带来我们能够看到的显着增长。

在Azure上调整/缓存JPEG图像

1 个答案: