404涉及静态资产、CDN和多服务器环境。

Question

我们的生产环境有问题，也许其他人遇到了这个问题，并且有了一个聪明的解决方案。

Prerequisites:

• 我们在两个前端服务器前使用负载均衡器。
• 我们使用CDN来传递静态资产，如CSS/JS/映像。
• 我们使用校验和对JS/CSS文件进行指纹识别，使用SquishIt提供缓存中断
• 在应用程序启动时，我们将资产路径与CDN路径结合起来。这也是一个SquishIt特性(.WithOutputBaseHref)。示例：/ui/main_465987ecb75.css将呈现为//cdn.host.com/ui/main_465987ecb75.css

部署例程：

1. 把server1从负载平衡器上拿下来。
2. 使部署到server1。
3. 把它热起来。
4. 在负载均衡器中包括服务器1。
5. 将server2从负载均衡器中取出(...and重复步骤2-4)

这就是它失败的地方：

在上面的第4步和第5步之间，两台服务器都可以在短时间内在线运行。在此期间，server1可以引用main_46eb48ac968.css，server2可以引用main_987eba4687.css。这会在下面的场景中引起麻烦..。

用例：

1. 用户访问站点并在新部署的服务器1上结束。
2. 浏览器将从CDN请求main_46eb48ac968.css。
3. CDN从负载均衡器请求该文件，因为它不在缓存中。
4. 负载均衡器将CDN请求发送给server2。
5. Server2 returs一个404页未找到错误，因为新文件仅在服务器1上。
6. 网站看起来像垃圾！

当然，一个简单的解决方法是在部署期间不使用CDN运行，但是由于CDN url在应用程序启动过程中优先于路径，所以我们必须在生产中重新启动应用程序.:/

想法？

Answer 1

嗯，所以你的CDN是用你的网站作为我的原点？

您可能需要查看本期。这样做是将散列写入生成路径中的文件夹，然后可以使用IIS重写规则从URL中删除该文件夹。这样做是为了提供一个选项，该选项提供了“文件名中的散列”选项的可靠缓存破坏，而不会导致文件激增。您可以使用它来确保服务--但在这种情况下，它将使您在CDN的缓存中保留一个旧版本的文件(因此，您需要在完成部署后使所有文件失效)。

这将在下一个版本中提供(0.9.3)

Answer 2

回复@AlexCuse

是的，我们的CDN正在使用该网站作为原产地。

实际上是我提出了作为虚拟文件夹的散列解决方案:)我们使用了该解决方案，直到我们部署到我们发现这个问题的多前端服务器环境中。在没有CDN、和多个前端服务器的环境中，缓存破坏文件是一种很好的方法。不幸的是我们两者都有。

如果我们使用哈希作为虚拟文件夹解决方案，在50%的情况下，旧文件与新URL一起服务--这是两个服务器都在线的短时间，一个服务器有旧代码，一个服务器有新代码。我们确实可以在部署后刷新CDN，但这将无助于已经下载错误文件的客户端，因为它的最大年龄为365天，并且在客户端访问ctrl+F5之前不会更新。我们控制不了这一点。废话。;)

因此，到目前为止，我们的决定是，用户最好在大约一分钟内获得一个没有CSS/JS的糟糕站点(如果是第一个访问者，访问了“错误”服务器)，而不是缓存错误的文件，直到下一次部署才会更新。

我们还对代码做了一些修改，现在我们可以在服务器生产时禁用CDN，而无需通过删除在http缓存中存储CDN URL的密钥来回收应用程序池。这有点繁琐，因为它涉及登录到CMS，做更改，保存，发布，然后更改，但这是可能的。

不管怎样，谢谢你，这是个很棒的图书馆！