企业网站托管外包平台,施工合同模板,wordpress网站相册,网站jquery在线优化前端训练营#xff1a;1v1私教#xff0c;终身辅导计划#xff0c;帮你拿到满意的 offer。 已帮助数百位同学拿到了中大厂 offer。欢迎来撩~~~~~~~~ Hello#xff0c;大家好#xff0c;我是 Sunday。
昨天的时候有同学问到前端部署相关的内容#xff0c;正好在知乎中看到… 前端训练营1v1私教终身辅导计划帮你拿到满意的 offer。 已帮助数百位同学拿到了中大厂 offer。欢迎来撩~~~~~~~~ Hello大家好我是 Sunday。
昨天的时候有同学问到前端部署相关的内容正好在知乎中看到了张云龙大佬的前端部署回答 回答地址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.cssc.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文件中引用的资源路径由于涉及到摘要信息引用资源的摘要信息也会引起引用文件本身的内容改变从而形成级联的摘要变化大概示意图就是 好了目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题新的问题又来了这™让工程师怎么写码啊
要解释优化与工程的结合处理思路又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题以上只是开了个头解决方案才是精髓但要说的太多太多有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解https://github.com/fouber/blog 总之前端性能优化绝逼是一个工程问题 以上不是我YY的可以观察 百度 或者 facebook 的页面以及静态资源源代码查看它们的资源引用路径处理以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平跪舔了。
建议前端工程师多多关注前端工程领域也许有人会觉得自己的产品很小不用这么变态但很有可能说不定某天你就需要做出这样的改变了。而且如果我们能把事情做得更极致为什么不去做呢
另外也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决大家总是把自己不关心的问题丢给别人那么前端工程师的开发过程将受到极大的限制这种情况甚至在某些大公司都不少见
妈妈我再也不玩前端了。。。。5555 10.29 日更新
在评论中 陈钢fleuria 林翔 提到了rails刚刚去看了一下确实是完成了以上所说的优化细节对整个静态资源的管理上的思考于本答案描述的一致。很遗憾我直到今天2014-10-29才了解到rails中的assets pipeline。这里向以上3位同学道歉原谅我的无知。
不过整篇回答没有讲解到具体的解决方案实现思路只是介绍了前端在工程化方向的思考答案本身是可用的了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。
rails通过把静态资源变成erb模板文件然后加入% asset_path image.png %上线前预编译完成处理不得不承认fis的实现思路跟这个几乎完全一样但我们当初确实不知道有rails的这套方案存在。 10.31 日更新
用 FIS3https://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就当做这样的一个选择吧。
1v1私教帮大家拿到满意的 offer
我目前在做一个 前端训练营 主打的就是1v1 私教帮大家拿到满意的 offer 。
可以点击这里查看详情
也可以直接加我微信沟通备注【训练营】
