最近有不少同学都问到我关于前端部署相关的问题，特别是针对大厂的部署方案。
在之前我有发过类似的文章，文章的内容依据 张云龙 在知乎的回答：
回答地址：https://www.zhihu.com/question/20790576
我认为这个回答非常有价值，应该可以帮助到很多对部署不是很了解的同学，因此整理。
问题
首先把问题给大家贴出来，如果大家也有类似的困惑，那么本文章肯定会给你带来一定的收获
大公司里怎样开发和部署前端代码？
主要有以下问题：
- 开发时的和部署时类库的引用和存放是一致还是不同？
- 模块放在项目中还是放在 CDN 之类服务器？
- 渲染网页用 Nginx 还是其他动态语言的 Web 服务器？
- 制作网页的流程，是先有设计师的稿，还是先看模块？
- 会选择用自己写的模块还是从社区寻找模块？
其他的思考
你平时在公司中是怎么部署项目的呢？
- 直接执行 npm run build 打包项目
- 得到 dist 文件夹，放到服务器对应位置
- 重新执行 nginx -s reload 完成部署
这样应该没有什么问题了。撑死再去解决下跨域的问题，一般的中小公司部署就算是完成了。
但是 部署真的有那么简单吗？那些大厂的部署也是通过以上方式完成的吗？？
让我们一起来看看吧~~
基础部署逻辑
当我们回归到最基本的前端开发时，就像看到了这个"可爱"的index.html页面和它的样式文件a.css，简单地用文本编辑器书写代码，不需进行编译，只要本地预览确认无误，然后将其放到服务器上等待用户访问。
前端开发就是"如此简单"，很轻松嘛！门槛也是相当低嘛！轻轻松松掌握有木有！！
图片
然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？
等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。
看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样：
图片
利用304，让浏览器使用本地缓存。
但，这样也就够了吗？不成！
304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样：
图片
强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？
很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。好像这样：
图片
下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！
当然没有！大公司的变态又来了，思考这种情况：
图片
页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！
重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。
什么东西与文件内容相关呢？我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的：
图片
这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！
唉~~~~，让我喘口气
现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径：
图片
图片
这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？
- 先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
- 先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。
但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
图片
看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。
什么是灰度？
软件开发通常是逐个版本不断迭代的过程。尽管新版本在上线前经过了测试，但即使如此，也无法确保没有问题。
因此，在公司里，上线新版本代码通常通过灰度系统。灰度系统能够将流量分为多个部分，其中一部分流向新版本代码，另一部分流向旧版本代码。
图片
而且，灰度系统可以设置流量的比例。例如，可以将走新版本代码的流量设置为 5%，确认没有问题后再逐步增加到 10%，50%，最终到达 100% 的全量。这样做可以将出现问题的影响降到最低。
否则，如果一开始就直接使用全量流量，一旦出现线上问题，就可能引发重大事故。
此外，灰度系统不仅仅用于此，例如，当产品不确定某些更改是否有效时，需要进行 A/B 实验，将流量分为两部分，一部分走 A 版本代码，另一部分走 B 版本代码。
那么这样的灰度系统是如何实现的呢？实际上，很多都是通过 nginx 实现的。
nginx 是一个反向代理的服务，用户的请求发送给它，然后由它转发给具体的应用服务器。
图片
它的工作流程如下图所示：
图片
首先，需要对流量进行染色，即对每个用户进行标注，让某些用户访问服务1，而其他用户访问服务2。染色的方法有很多种，可以通过cookie来实现。不同的用户携带不同的cookie。一开始所有用户都访问服务1。
然后，在用户进行第二次访问时，nginx 根据用户携带的cookie将其转发到不同的服务，从而实现灰度访问。
好了，灰度部署的介绍就到这里。回到原文提到的先全量部署静态资源，再灰度部署页面，这是什么意思呢？
当进行静态资源的部署时，不必删除原有的静态资源，而是复制新的静态资源过去。由于文件名采用了摘要算法重命名，因此不会出现重名的问题。
在灰度部署动态页面方面，部分用户访问旧页面，而另一部分用户访问新页面。对于访问旧页面的用户，其请求仍指向旧资源并直接使用缓存。对于访问新页面的用户，他们访问的是已经完成部署的新资源，避免了访问旧资源导致页面错误的情况。
最后，根据用户访问情况，通过灰度系统逐步将访问旧页面的用户过渡到新页面上。
部署方案总结
所以，大公司的静态资源优化方案，基本上要实现这么几个东西：
- 配置超长时间的本地缓存
- 节省带宽，提高性能采用内容摘要作为缓存更新依据
- 精确的缓存控制静态资源CDN部署
- 优化网络请求更资源发布路径实现非覆盖式发布
- 平滑升级
全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在前端所有静态资源加载的位置都要做这样的处理。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是：
图片
好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！
要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。
总之，前端性能优化绝逼是一个工程问题！
以上不是我YY的，可以观察 百度 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。
建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？
另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！
10.29 日更新
在评论中， @陈钢@fleuria @林翔 提到了rails，刚刚去看了一下，确实是完成了以上所说的优化细节，对整个静态资源的管理上的思考于本答案描述的一致。很遗憾我直到今天才了解到rails中的assets pipeline。这里向以上3位同学道歉，原谅我的无知。
不过整篇回答没有讲解到具体的解决方案实现思路，只是介绍了前端在工程化方向的思考，答案本身是可用的，了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。
rails通过把静态资源变成erb模板文件，然后加入<%= asset_path 'image.png' %>，上线前预编译完成处理，不得不承认，fis的实现思路跟这个几乎完全一样，但我们当初确实不知道有rails的这套方案存在。
10.31 日更新
用 FIS3（https://fis.baidu.com/） 包装了一个小工具，完整实现整个回答所说的最佳部署方案，并提供了源码对照，可以感受一下项目源码和部署代码的对照。
- 源码项目：fouber/static-resource-digest-project · GitHub
- 部署项目：fouber/static-resource-digest-project-release · GitHub
- 部署项目可以理解为线上发布后的结果，可以在部署项目里查看所有资源引用的md5化处理。
这个示例也可以用于和assets pipeline做比较。fis没有assets的目录规范约束，而且可以以独立工具的方式组合各种前端开发语言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），并与其他后端开发语言结合。
assets pipeline的设计思想值得独立成工具用于前端工程，fis就当做这样的一个选择吧。
