网站如何做图片自动切换,网站制作怎么办,沈阳男科医院哪家好些,wordpress目录seo公众号#xff1a;程序员白特#xff0c;欢迎一起交流学习~ 原文#xff1a;前端部署真的不简单 - 掘金 (juejin.cn) 现在大部分的中小型公司部署前端代码都是比较简单的#xff0c;主要步骤如下:
首先#xff0c;通过脚手架提供的命令npm run build打包前端代码程序员白特欢迎一起交流学习~ 原文前端部署真的不简单 - 掘金 (juejin.cn) 现在大部分的中小型公司部署前端代码都是比较简单的主要步骤如下:
首先通过脚手架提供的命令npm run build打包前端代码生成dist文件夹
最后将dist文件夹丢给后台开发人员放在他们的工程里面随后台一起部署现在普遍是前后端分开部署因此利用nginx起一个web服务器将dist文件夹放到指定的路径下配置下nginx访问路径对于请求接口使用proxy_pass进行转发解决跨域的问题。
更加高端一点的操作是利用CI/CD Docker进行自动化部署。
但是你是否真的想过前端部署真的就这么简单吗
这其实是一个非常严肃且复杂的问题因为这关系到线上生产环境的稳定。
有一天从自知乎上看到一篇张云龙大佬在2014年写的文章非常有启发即使这篇文章距离现在有快10年了但是其中的思想仍然熠熠生辉。
因为写的真的是太好了为了让更多的人看到所以大部分内容直接就照搬过来为了让自己加深印象。如果想看原文原文网址在这里。
那让我们从原始的前端开发讲起。
下图是一个 index.html 页面和它的样式文件 a.css无需编译本地预览丢到服务器等待用户访问。 哇前端这么简单门槛好低啊。这也是前端有太多人涌入进来的原因。
接着我们访问页面看到效果再查看一下网络请求200不错太完美了 那么研发完成。。。。了么
等等这还没完呢
对于像 BAT 这种公司来说那些变态的访问量和性能指标将会让前端一点也不好玩。
看看那个 a.css 的请求如果每次用户访问页面都要加载是不是很影响性能很浪费带宽啊我们希望最好这样 利用304让浏览器使用本地缓存。
但这样也就够了吗
不够
304叫协商缓存这玩意还是要和服务器通信一次我们的优化级别是变态级所以必须彻底灭掉这个请求要变成这样 强制浏览器使用本地缓存(cache-control/expires)不要和服务器通信。
好了请求方面的优化已经达到变态级别那问题来了你都不让浏览器发资源请求了这缓存咋更新
很好相信有人想到了办法通过更新页面中引用的资源路径让浏览器主动放弃缓存加载新资源。
像这样 下次上线把链接地址改成新的版本这就更新资源了。
问题解决了么当然没有思考这种情况 页面引用了3个 css 文件而某次上线只改了其中的a.css如果所有链接都更新版本就会导致b.cssc.css的缓存也失效那岂不是又有浪费了
不难发现要解决这种问题必须让url的修改与文件内容关联也就是说只有文件内容变化才会导致相应url的变更从而实现文件级别的精确缓存控制。
什么东西与文件内容相关呢
我们会很自然的联想到利用数据摘要要算法对文件求摘要信息摘要信息与文件内容一一对应就有了一种可以精确到单个文件粒度的缓存控制依据了。
OK那我们把 url 改成带摘要信息的 这回再有文件修改就只更新那个文件对应的 url 了想到这里貌似很完美了。你觉得这就够了么
图样图森破
现代互联网企业为了进一步提升网站性能会把静态资源和动态网页分集群部署静态资源会被部署到CDN节点上网页中引用的资源也会变成对应的部署路径 好了当我要更新静态资源的时候同时也会更新 html 中的引用吧就好像这样 这次发布同时改了页面结构和样式也更新了静态资源对应的url地址。现在重点来了现在要发布代码上线亲爱的前端研发同学你来告诉我咱们是先上线页面还是先上线静态资源 这里的静态资源不仅仅包括css文件也包括图片以及不怎么经常变的资源。 先部署动态页面再部署静态资源在二者部署的时间间隔内如果有用户访问页面就会在新的页面结构中加载旧的资源并且把这个旧版本的资源当做新版本缓存起来其结果就是用户访问到了一个样式错乱的页面除非手动刷新否则在资源缓存过期之前页面会一直执行错误。 先部署静态资源再部署动态页面在部署时间间隔之内有旧版本资源本地缓存的用户访问网站由于请求的页面是旧版本的资源引用没有改变浏览器将直接使用本地缓存这种情况下页面展现正常但没有本地缓存或者缓存过期的用户访问网站就会出现旧版本页面加载新版本资源的情况导致页面执行错误但当页面完成部署这部分用户再次访问页面又会恢复正常了。
好的上面一坨分析想说的就是先部署谁都不成都会导致部署过程中发生页面错乱的问题。
所以访问量不大的项目可以让研发同学苦逼一把等到半夜偷偷上线先上静态资源再部署页面看起来问题少一些。这也是很多公司的部署方案。
但是大公司超变态没有这样的绝对低峰期只有相对低峰期。
所以为了稳定的服务还得继续追求极致啊
这个奇葩问题起源于资源的 覆盖式发布用待发布资源覆盖已发布资源就有这种问题。
解决它也好办就是实现 非覆盖式发布。 看上图用文件的摘要信息来对资源文件进行重命名把摘要信息放到资源文件发布路径中这样内容有修改的资源就变成了一个新的文件发布到线上不会覆盖已有的资源文件。上线过程中先全量部署静态资源再灰度部署页面整个问题就比较完美的解决了。
因为很多前端开发同学不怎么接触部署对灰度部署不太熟悉下面将介绍下什么是灰度部署。
软件开发一般都是一个版本一个版本的迭代。新版本上线前都会经过测试但就算这样也不能保证上线了不出问题。
所以在公司里上线新版本代码一般都是通过灰度系统。灰度系统可以把流量划分成多份一份走新版本代码一份走老版本代码。 而且灰度系统支持设置流量的比例比如可以把走新版本代码的流程设置为 5%没啥问题了再放到 10%50%最后放到 100% 全量。这样可以把出现问题的影响降到最低。
不然一上来就全量万一出了线上问题那就是大事故。
另外灰度系统不止这一个用途比如产品不确定某些改动是不是有效的就要做 AB 实验也就是要把流量分成两份一份走 A 版本代码一份走 B 版本代码。
那这样的灰度系统是怎么实现的呢其实很多都是用 nginx 实现的。
nginx 是一个反向代理的服务用户请求发给它由它转发给具体的应用服务器。 它的过程如下图所示 首先需要对流量进行染色即对这个用户进行标注让这个用户访问服务1另外的用户访问服务2。染色的方式有很多可以通过cookie来完成。不同的用户携带的cookie是不同的。第一染色的时候所有的用户都访问服务1。
然后第二次访问的时候nginx根据用户携带的cookie进行转发到不同的服务这样就完成了灰度访问。
好了灰度部署就介绍到这里回到原文讲的先全量部署静态资源再灰度部署页面这是什么意思呢
首先部署静态资源的时候不要删除原来的静态资源而是把新的静态资源发复制过去因为文件名用摘要算法重命名的所以不会发生重名的问题。
其次灰度部署动态页面也就是一部分用户访问老的页面一部分用户访问新的页面。访问老页面的用户请求的还是老资源直接使用缓存。访问新页面的用户访问新资源此时新资源已经部署完成所以不会访问老的资源导致页面出现错误。
最后根据访问情况利用灰度系统逐渐把访问老页面的用户过渡到访问新页面上。
所以大公司的静态资源优化方案基本上要实现这么几个东西 配置超长时间的本地缓存节省带宽提高性能 采用内容摘要作为缓存更新依据精确的缓存控制 静态资源CDN部署优化网络请求 更资源发布路径实现非覆盖式发布平滑升级
全套做下来就是相对比较完整的静态资源缓存控制方案了而且还要注意的是静态资源的缓存控制要求在前端所有静态资源加载的位置都要做这样的处理。
是的所有
什么js、css自不必说还要包括js、css文件中引用的资源路径由于涉及到摘要信息引用资源的摘要信息也会引起引用文件本身的内容改变从而形成级联的摘要变化大概就是 到这里本文结束了我们已经了解了前端部署中关于静态资源缓存要面临的优化和部署问题新的问题又来了这™让工程师怎么写码啊
这又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题。
妈妈我再也不玩前端了。。。。
