提供CDN后备的本地JS和CSS资源

鉴于

• CDN是一件好事，因为它们可以为靠近客户端的资源提供服务，客户端可以缓存它们，并且您可以减少自己服务器上的负载。
• 在最新的浏览器中，由于子资源完整性（SRI）的原因，从第三方服务器加载资源不会降低安全性。
• CDN在某些国家/地区可能已关闭或受阻，并且在离线开发¹时不可用。

我认为使用CDN很有必要，但也要为它们不可用做准备。这篇博客文章很好地介绍了提供备用功能的不同方法。如果看一下Basic示例，您会发现它已经包含了很多样板代码，仅可为jQuery和Bootstrap提供后备，而受青睐的解决方案建议使用Fallback.js，在过去的一年中似乎几乎没有保留。 。同样，与该主题最相关的SO问题仅涉及为jQuery提供后备功能。

但是，在大多数实际项目中，我希望有5个或更多的js / css资源，所以我觉得您不必重复一些混乱的样板即可为所有这些提供后备。此外，每次添加或更新资源时，您现在都必须

• 更新CDN链接
• 通过手动下载或更改npm / bower配置中的版本来更新本地后备副本
• 更新链接到后备
• 更新SRI哈希

而在理想世界中，我希望在一个配置文件中添加/更新资源，并让所有其他步骤自动执行（然后运行测试以查看更新是否破坏了任何内容）。

是否已经建立工作流程来实现这一目标？

还是CDN尤其是SRI太新了？

还是大多数人根本不愿意为CDN资源提供后备资源？

_{1.尽管您可以拥有一个不依赖CDN的开发版本，但是我也认为这是一种后备形式，因为它也需要维护。}

我认为您可能会误解了可能需要这种弹性的大型站点如何使用CDN。

这不仅仅是托管jQuery或一些图像的问题。该网站的大部分内容将托管在CDN上，只有动态生成的内容（如付款页面或购物篮）托管在“主要网络农场”上

甚至这些也越来越多地使用JS和cookie在本地进行处理，以显示用户特定的内容，而无需进行服务器端处理。

如果CDN发生故障，并且您开始将所有流量传递到Web服务器，则很有可能会失败，否则，您实际上就不需要CDN。

我在CDN上工作的网站对该网站变得越来越重要。在开始时，我们只是使用它来缓存Images / CSS / JS。在此阶段，我们有一个config属性，用于将这些资源的主机名从www.mysite.com/改写为www.cdn.com/，因此，如果CDN崩溃，我们可以简单地更改此主机值或将其完全关闭并离开指向我们的网络服务器的网址。

但是，我们现在已经开始基本上缓存整个页面，并通过AJAX加载个性化内容。我们的CDN对我们的站点已变得至关重要，如果没有它，我们可以像我们自己的HTTP服务器一样运行。我们之所以向CDN支付好钱，部分原因是它具有弹性和SLA承诺的正常运行时间，因此将时间和精力浪费在后备上似乎是浪费时间。我们确实已经制定了灾难恢复计划，以防供应商遇到重大问题，但这不是一个简单的自动化流程，并且在迁移到后备CDN时会出现停运的情况。

因此，在回答您的问题时，取决于CDN对您的站点的集成程度。如果只是您的资产，那么您将放入CDN，并假设您的http服务器可以处理提供此内容的负载，那么您可以使用配置开关来实质上打开或关闭CDN。加上监视工具，您可以自动打开或关闭该开关。

我发现使用CDN的3个非常重要的原因：

1. 减少远方用户的网络延迟。当您拥有一个面向全球受众的网站时，对于南亚（尤其是中国）的用户来说，在北美托管似乎并不快。用户体验的差异可能很大，以至于阻止用户使用您的网站。在这种情况下，多区域CDN对您的业务至关重要。

2. 从高可用性资源中尽可能多地服务。可靠性是使用云CDN的主要原因之一-流量会自动重新路由到可用节点，并且如果整个云区域都关闭，您可以添加一些额外措施来重新路由流量。

3. 与提供动态内容的应用程序服务器相比，CDN易于维护且价格便宜。当您必须解决上述问题时，这是省钱的自然方法。

所有这些意味着，CDN的目标是提高内容对最终用户的可用性。如果CDN失败或由于某种原因变慢，客户端回退将大大增加页面负载，因为它首先会尝试获取不可访问的资源。更好的解决方案是具有服务器端设计，该设计将在“ {CDN} /js/jquery-version-min.js”之类的链接中替换基本URL。如果CDN运行状况检查失败，这将允许将流量重新路由到应用程序服务器而不是CDN-客户端将不会执行不必​​要的请求，而将直接转到应用程序服务器，这将是客户端解决方案的后备功能。这还将解决本地部署和暂存部署的问题，