针对 Azure/CDN 进行编程
我们正在将本地应用程序迁移到 Azure 云。内部企业用户通常通过管理界面将全尺寸图像上传到我们的网站（这些图像现在将发送到 Azure blob 存储）。该站点负责根据请求创建正确的图像尺寸。那么现在发生的情况（本地环境）是这样的：
1）用户上传完整大小的文件。
2) 当通过 GetImage HTTP 处理程序请求较小版本时（即 http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100）处理程序检查我们之前是否创建了该尺寸的该图像的版本。如果是，它将直接写入响应流。如果没有，则需要一秒钟来调整其大小，将其保存到“/iamges/cache”目录并将调整后的图像写入响应流。
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 存储的交互，有什么接近“最佳实践”的东西吗？我可以考虑另一种方法吗？这对于调整图像大小来说似乎是很大的开销，所以我想我一定错过了一些东西或忽略了另一个解决方案。
We're in the process of moving an on premise application to the Azure cloud. Internal corporate users routinely upload full size images via an admin interface to our website (these will now be sent to Azure blob storage). The site is responsible for creating the correct images sizes when they are requested. So what happens right now (on premise environment) is this:
1) User uploads full size file.
2) When a smaller version is requested through GetImage HTTP handler (i.e. http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100) the handler checks to see if we have previously created a version of that image in that size. If so, it writes it directly to the Response stream. If not, it takes a second to resize it, save it to the "/iamges/cache" directory and writes the resized image to the Response stream.
3) Next time that file is requested in that size it returns the previously created image.
So I want to implement the same type of mechanism using Azure and Blob storage, but I have a couple of concerns:
1) I can't simply check to see if a blob exists. I have to download the blob first, then call FetchAttributes to see if it throws an exception. However, doing this actually downloads the image. So doesn't this double the number of requests for images (one to see if it exists and another to display to the user)?
2) Let's say the image does not exist in the size I need it (i.e. the blob /images/cache/image_15_100_100.jpg does not exist -- id #15, 100x100 pixels). So I've hit a request to the CDN once to see if it exists. Now I have to download possibly a 5-10 MB full size image (as opposed to reading it off our on-premise file system which is fast), load that 5-10 MB image in memory, resize it and re-upload it to the CDN. This seems time consuming, especially when I could have 10-15 of these images on a single request.
I know Azure is relatively new, but is there anything close to a "best practice" for this type of interaction with blob storage? Is there another approach that I could consider? This just seems a lot of overhead for image resizing so I figure I must be missing something or overlooking another solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我想这里发生了很多事情。我的回答基于这些假设：
显示在网站
在Azure上运行
访问图像
如果这些假设
中有任何一个是错误的，请告诉我，我将适当地编辑我的答案。
你是对的，.Net 客户端库中没有内置方法可以让你检查 blob 是否存在。但是，通过执行
.FetchAttributes()这实际上并没有下载图像，它只是尝试 检索标头信息（很像当您列出容器中的所有 Blob 时），直到您调用一个 Blob 后才会真正下载 Blob.DownloadX()方法。您的服务器端代码无需对话即可使用任何 CDN 功能。它应该只与 Blob 存储中的图像进行交互，就像它们是任何旧的 Blob 一样。您唯一需要使用 CDN URL 的时间是在指定所显示页面上的图像路径时。
您不希望网站必须返回图像流，您希望它指向包含图像的 CDN 上的 URL。 CDN 将能够处理比您可以构建的任何网站更多的负载。然后网站可以检查 blob 是否存在，如果存在，则仅返回 URL。如果它没有下载完整图像，请调整其大小，保存它，然后返回 URL。虽然从 Blob 存储访问图像不如从本地磁盘读取图像那么快，但它仍然相当快，特别是对于像您所说的 <10MB 的文件。
大概有人正在指定在您的网站中使用图像的位置和大小。您可以捕获该图像并生成调整大小的图像吗？
OK, I think there's lots going on here. My answer is based on these assumptions:
be displayed on a website
running on Azure
access to the images
library
If any of these assumptions are wrong, let me know and I'll edit my answer appropriately.
You're right, there is no built in method in the .Net client library which allows you to check if a blob exists. But, by doing the
.FetchAttributes()this doesn't actually download the image, it simply attempts to retrieve the header information (much like when you list all of the blobs in a container), the blobs aren't actually downloaded until you call one of the.DownloadX()methods.Your server side code has no need to talk to use any of the CDN functionality. It should just talk to your images in blob storage like they're any old blob. The only time you need to use the CDN URLs is when you're specifying the path to the images on the page you're displaying.
You don't want you're website to have to return the stream of the image, you want it to point to a URL on the CDN that contains the image. The CDN will be able to deal with much more load than any website that you can build. The website can then check to see if the blob exists, if it does, just return the URL. If it doesn't download the full image, resize it, save it, then return the URL. While accessing the image from blob storage isn't as quick as reading it off of a local disk, it's still pretty quick, particularly for files <10MB like you're talking about.
Presumably somewhere someone is specifying where and what size images to use in your site. Could you capture that and generate the resized image then?