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

Question

在我的Azure web应用服务(ASP.NET MVC)中，我通过一种匿名控制器方法从Azure经典blob存储中以两种方式提供图像：

• 一种是直接重定向到存储blob URI，以及
• 第二种方法是通过HttpClient提取，然后从检索到的字节中提取FileContentResult (隐藏存储URI的优点)。

这两种控制器方法都涉及几个数据库选择调用，但我使用的是P2层Azure数据库。

我仍然在测试两者之间的性能差异--很明显，第二个需求是总体流量的两倍:从存储到web应用程序的字节，然后是从web应用到客户端的字节。

然而，在这两种情况下，使用Azure性能测试工具(在5分钟内有250个并发模拟用户)，在加载的blob存储中看到了非常不可接受的响应时间和错误。

当使用第二种方法(从存储中获取web应用程序并返回流)时，我在从存储处请求时会得到很多HTTP请求错误，因此我有一个即时重试机制(最多3次尝试)来缓解这种情况。最终的结果是图像的平均响应时间在12到25秒之间，这对现在的电子邮件显示并不太好。

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

这是一个完全愚蠢的方法吗？我可能是这一切的罪魁祸首。当然，在Azure存储上构建的体系结构比我的要大得多，并且响应速度快？

Answer 1

这只是一件轶事，但我们已经看到了使用Azure CDN使用blob存储作为源的良好效果。因此，与其重定向到blob存储url，不如使用Azure CDN URL。