前端上线部署最佳实践

这是一个很有趣的，感觉和前端这个领域不太搭嘎的话题，今天这个话题主要是聊聊利用我们前端相关的解决方案来解决前端开发和相关上线发布优化的复杂问题。其实开启工程化始祖应该是facebook。

ok,那么接下来我们从最基本的技术原理开始讲起吧。

 

让我们从最先最原始的前端开发入手。如上所示是一个index.html页面与一个样式文件a.css，我们可以用我们最熟悉的文本编辑器进行编码，然后本地测试，再将代码直接上传至服务器，这样就算上线发布完成了。是不是觉得很easy呢？

接着，我们用浏览器看看线上的页面，一切正常，好的，完美上线！

但是，但是，在一些大公司的话，因为考虑到各种页面访问相关的指标，你觉会知道，前端也不是这么随意的。

很容易可以看出，a.css这个文件每次访问都需要重新reload一下，这种情况在访问量大的网站是不可想想的，因为很烧带宽，我们最好是像下面这种情况：

这里使用了浏览器的304本地缓存，然而304还是需要和服务器链接一次，我们现在想做到一次都不访问，像下面这样个样子：

这里强制让浏览器使用本地的缓存，不和服务器连接。这样的页面优化几乎是达到了极限了。但是如果想让缓存更新怎么办呢？

估计很多人都会知道这样的一个做法：改变一下资源的路径，浏览器就会加载新的资源了。像下面这样：

 

每次上线的时候，将文件文件的地址更新一下就行了。当然，这样又会遇到新的问题：

 

比如页面里有3个外部css文件，在某次迭代中只修改了a.css文件，但是将所有链接地址都改了，那么就会让另外的两个文件缓存也失效，是不是有点浪费贷款了呢。

那么并着精益求精的精神，我们可以让文件的url和文件变更建立某种联系，就是说，如果某个文件内容变更了，就会相应的改变其url地址，这样就让变更加的精准了。

那么，要采取什么方式与文件变更相关联呢，我们可以很容易想到的是文件数据摘要算法 对文件算摘要信息，那么文件的内容就和得到的摘要信息唯一对应了，那么就有了精确到一个文件粒度的控制根据了。现在我们将url地址变成其内容的摘要信息：

 

这样如果文件有变更，那么就变更文件对应的URL地址了，是不是感觉这样非常的ferfect呢。

但是事情还没完呢，大家都知道现在的互联网公司为了提升自己网站的加载速度，通常会将相关的静态资源放到CDN服务上，网页中的静态资源也会变成CDN的部署地址：

 

当然，在我们想要变更静态文件的时候，也一定会将相关的资源url变更，就像下面这样：

 

现在是这样的，我们同时改变了html和页面的静态资源的url地址，现在要上线了，那么我们是先发布html页面呢，还是先发布我们变更后的静态资源呢？

：这样的话，在二者部署的时间期间内，假如有新的访问，那么html页面将加载的是就的静态资源，浏览器将会把这个旧的资源当成新的资源缓存起来。那么就导致：用户看到的是一个乱的网页，除了强制刷新，否则在资源失效之前一直都是这样的样式错乱的页面。

：这样呢就会导致在这二者部署的期间内，具有旧静态文件本地缓存的用户，因为浏览器会取本地的缓存，那么这样页面就是正常的。到那时如果哪些本地没有缓存的用户访问时，结果就是页面访问的是新版本的静态资源，那么页面就会错乱了。

那么，既然先部署那一个都会出问题，那怎么办呢？现在很多访问量不大的网站，就是在半夜或者凌晨偷偷的线上静态资源，然后上页面，问题比较少。

但是呢，有些访问量巨大的项目，就没有所谓的访问低谷期了，所以怎么办呢？

这个难解的问题就是 覆盖式发布 造成的，我们用待发布的资源去替换 已经发布的资源，那么就会出现这种情况。那么怎么解决呢？其实我们可以用 非覆盖式的发布方式：

 

如图所示，我们用文件的摘要信息对静态文件来命名，然后将摘要信息放到资源文件要发布的路径之中，如此，变更之后的文件旧成了一个要发布上线的文件了，并不会覆盖已经上线的静态资源文件。上线发布的时候，先进行完全部署静态资源文件，然后在进行页面的灰度部署，这样的方案就比较的perfect了。

因此，有些公司静态资源优化的习惯，基本上需要满足下面几个原则：

设置比较长的本地缓存 —— 提高性能，节省带宽

利用摘要信息进行文件变更依据 —— 缓存的精确控制

将静态资源部署到CDN节点上 ——节省网络请求

利用非覆盖式发布来更新静态资源 —— 渐进替换

那么，这一整个流程下来，就是一个相对比较perfect 的解决办法了。

 

最后，现在我们知道饿怎么优化前端工程里的静态资源部署的难题，那么新的issue又来了，那就是前端工程师怎么去coding呢？

那么要想理解优化和工程相融合的思维方式，那么就会衍生出一系列有关模块化开发、资源的加载、资源合并、前端架构等等的工程相关的问题。上面只是抛砖引玉，解决方案才是关键，但是这又要一大堆篇幅才能说明白了。

总结：前端性能优化就是一个工程化的问题。

上面的不是个人臆想的，我们可以看看百度或者facebook的页面和静态资源的一些原始代码，看看人家的资源引用的处理方式，还有网络资源缓存控制的方案。就知道人家是工程化是怎么样的一个水准了。

这里比较推荐大家多关注一下前端工程相关的一些东西，或者有些人觉得我的产品规模很小啊，不用这么认真吧，然而你也不大后那天你确实需要这样做了呢。而且如果我们能将工作做的更好那么，为什么不去做的更完美一些呢？

另外要注意的是，不要觉得这些应该丢给后端或者运维去做。你要想想，如果什么难题都让别人解决了，那么我们前度工程师的角色价值会大打折扣。

 

原文链接：https://kuaibao.qq.com/s/20180925G11DO800?refer=cp_1026