我们正在将内部部署应用程序迁移到Azure云。内部企业用户通常通过管理界面将完整尺寸的图像上传到我们的网站（这些图像现在将被发送到Azure blob存储）。该网站负责在请求时创建正确的图像大小。那么现在发生的事情（内部环境）是：
1）用户上传完整大小的文件。
2）当通过GetImage HTTP处理程序（即http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100）请求较小的版本时，处理程序检查我们是否先前已创建该大小的该图像的版本。如果是，则将其直接写入Response流。如果没有，则需要一秒钟来调整它，将其保存到“/ iamges / cache”目录并将调整后的图像写入Response流。
3）下次以该大小请求该文件时，它将返回先前创建的图像。
所以我想使用Azure和Blob存储实现相同类型的机制，但我有几个问题：
1）我不能简单地检查blob是否存在。我必须首先下载blob，然后调用FetchAttributes以查看它是否抛出异常。但是，这样做实际上会下载图像。那么这不会使图像请求的数量增加一倍（一个用于查看是否存在，另一个用于显示给用户）？
2）假设图像不存在我需要的尺寸（即blob /images/cache/image_15_100_100.jpg不存在 - id＃15,100x100像素）。所以我已经向CDN发出了一次请求，看它是否存在。现在我必须下载一个5-10 MB的全尺寸图像（而不是从我们的内部部署文件系统中快速读取它），在内存中加载5-10 MB图像，调整其大小并重新上传到CDN。这似乎很耗时，特别是当我可以在一次请求中获得10-15个这样的图像时。
我知道Azure相对较新，但是对于这种与blob存储的交互，有什么接近“最佳实践”吗？还有其他方法可以考虑吗？这似乎是图像大小调整的大量开销，所以我想我必须遗漏一些东西或忽略另一种解决方案。
答案 0 :(得分：6)
好的，我觉得这里有很多事情要做。我的回答是基于这些假设：
如果这些假设有任何错误，请告诉我，我会适当地编辑我的答案。
您说得对，.Net客户端库中没有内置方法，可以检查blob是否存在。但是，通过执行.FetchAttributes()这实际上并不下载图像，它只是尝试retrieve the header information（就像列出容器中的所有blob时一样），实际上并没有下载blob直到你调用其中一个.DownloadX()方法。
您的服务器端代码无需通话即可使用任何CDN功能。它应该只是在blob存储中与你的图像交谈，就像它们是任何旧的blob一样。您需要使用CDN URL的唯一时间是指定您正在显示的页面上图像的路径。
您不希望网站必须返回图像流，您希望它指向包含图像的CDN上的URL。 CDN将能够处理比您可以构建的任何网站更多的负载。然后，网站可以检查blob是否存在，如果存在，只需返回URL。如果没有下载完整图像，请调整大小，保存，然后返回URL。虽然从blob存储中访问图像的速度不如从本地磁盘读取图像那么快，但它仍然非常快，特别是对于像你所说的那样大于10MB的文件。
据推测，某人正在指定您网站中使用的图片的大小和尺寸。您可以捕获并生成调整后的图像吗？