将Azure存储blob URI用作网站资产（即可链接）的一部分是否被认为是一个好主意？

从我的Azure web app服务ASP.NET MVC，我通过匿名控制器方法从Azure classic blob存储以两种方式提供图像：

一种是直接重定向到存储blob URI，另一种是 第二，通过HttpClient获取服务，然后从检索到的字节中获取FileContentResult，这有利于隐藏存储URI。 这两种控制器方法都涉及几个数据库选择调用，但我使用的是P2层Azure数据库

我仍在测试两者之间的性能差异——显然，第二个需要两倍的总流量：从存储到web应用的字节，然后从web应用到客户端的字节

然而，在这两种情况下，我都看到blob存储在负载下的响应时间和错误是不可接受的，使用Azure性能测试工具在5分钟内模拟250个并发用户

当使用第二种方法在web应用程序上从存储获取和流回时，我在从存储请求时会遇到很多HTTP请求错误，因此我有一个即时重试机制，max 3尝试缓解这一问题。最终的结果是图像的平均响应时间在12到25秒之间，这对于现在在电子邮件中显示来说已经不是什么好事了

使用第一种方法清理重定向到存储URI，根据诊断日志，这平均会下降到3-6秒，以便为重定向服务—但我无法控制随后的客户端重定向到存储的请求是否会失败，这显然是必须的—成功率在80%到95%之间。因此，我认为，通过“保证”将图像明确地提供给客户端，延迟将增加四倍，这实际上同样糟糕

---

这是一种彻底的愚蠢方法吗？我可能对这一切都一无所知。当然，在Azure存储上构建的体系结构比我的体系结构大得多，而且响应速度快？

这只是个传闻，但我们已经看到Azure CDN使用blob存储作为源的良好效果。因此，不要使用Azure CDN URL重定向到blob存储URL

这些图像是静态的，即图像URL是否可以硬编码到您的应用程序中，或者它们是否需要始终从数据库中获取，即特定于用户？不，传统意义上的图像不是静态的，不幸的是，这些图像每隔几周左右生成一次，然后存储在Azure Blob中。提供的图像取决于控制器方法的参数和请求的时间。所以，很遗憾，用户和时间是特定的！谢谢本，你读到了我的想法——我正在建立一个CDN，指向博客存储。在Azure门户中，这是一项非常简单的任务，所以我至少尝试一下也没有什么坏处。我已经看到了一些关于向存储中添加blob和它出现在CDN端点之间可能存在不可忽略的延迟的担忧，但到目前为止，我的样本大小为两个blob，情况并非如此：