共计 3292 个字符，预计需要花费 9 分钟才能阅读完成。
一、问题背景
想必不少同学在开发过程中都经验过以下场景：
测试人员提出一个 Bug，你在进行修复和 Resolve 后，测试人员 Reopen 并备注问题仍然存在。你在本地确定代码无误后，去测试环境复现，发现原来是前端资源缓存的问题。
运维部署我的项目后，测试人员进行复查发现我的项目接口存在异样，后端与运维排查半天，最初发现原来是因为前端缓存还是上一个版本的。
浏览器缓存提供展示信息减速力的同时也会给所有使用者带来一些 illusion。有时候即使教训十分丰盛的前端技术人员，也可能会被 hoisting 所骗。这种本地缓存滞后的问题，尽管经常性遇到但很少真正被解决。
例如：在给客户部署产品后，应用过程中接口频频呈现 4xx 状态码，在进行排查后端服务，排查代理等方向破费较长时间进行试错，最初发现是所应用的前端资源是浏览器缓存导致，在新版本中接口进行了变动，但因为是缓存资源，它申请的是新版本后端服务中废除资源的 URI。
二、传统计划
对网络根底理解比拟充沛的同学必定会马上想到：
重启 nginx 服务器强制更新缓存。
咱们都晓得浏览器的缓存分为两种：强缓存和协商缓存。并且依据优先级缓存被存储介质分为 worker cache、memory cache、disk cache、push cache。通过 HTTP heads 对它们施加限度，以管制缓存的应用。上面来逐个为大家阐明为何这种形式不可取。
HTTP Headers
从上文的场景来说，咱们须要的是及时无效的缓存革除，因而对于通过设置 cache-conrol: max-age=1000; 或 HTTP 1.0 时代的 Expires: Wed, 22 Nov 2019 08:41:00 GMT 都无奈满足咱们对于实时性的需要。
是否可应用协商缓存呢？
协商缓存可能是大部分同学面对这种问题时首要想到的解决办法。它是通过询问服务端是否应用缓存，达到非法应用缓存的目标。可配合缓存服务器，升高服务器解决申请的负载，实现负载平衡。
即便这个解决方案看起来不错，但会带来一些其余问题：
若运维降级时，用户敞开了对应域名的服务，降级完结后，仍然应用的是旧缓存，没有申请动态资源。
缓存服务会导致拜访曾经不存在的接口资源，返回 4xx 系列谬误。
因为数栈产品是大数据处理，localstorage 的 5MB 容量无奈满足需要，因而应用 IndexDB 进行数据长久化，那么在缓存资源更新时还须要额定清理长久化的旧数据。
对于后端存在强依赖性，例如，前端 bug fix 后会重新部署，然而后端服务并没有扭转。
WebSocket
那么若是应用 websocket 推送更新给用户呢？
此计划尽管在视觉效果上是完满的，然而须要在所有客户的服务上减少中间层有肯定的危险，且工夫老本较高。
轮询申请
那可否尝试应用轮询申请服务端以获取资源最新的版本信息？
轮询并不适宜本场景应用，起因有三：
轮询申请不好指定工夫，如果轮询间隔时间太长，比方 5 分钟，那么很可能在这 5 分钟外面用户曾经应用缓存拜访了谬误资源。如果工夫设置太短，申请会过于频繁并且这种频繁申请会在用户应用期间始终存在，这或多或少会影响用户体验。
轮询申请在非 HTTP2 应用 Stream 进行多路复用的场景，并行申请只有 6 个管道。让一个只是某一时刻重要的缓存申请继续占据一个管道显然是不适合的。
轮询申请须要增加一个版本问询服务，这有服务挂掉的危险，但 nginx 代理服务器能够接手解决。
三、前端资源静默更新
在 nginx 代理服务层进行解决，能防止被链路后的环境烦扰，并且能够命令 nginx 在满足某些条件的时候跳过后端服务的反向代理，间接返回制订的响应码亦或是响应报文。
因为整条链路还是比拟长，咱们先整顿下思路。
思路
咱们能够在部署时通过某种形式，把前端资源的标记位交给代理服务器，在代理服务器每次转发 http response 时把标记位塞入 response head 返回给客户端。客户端把标记位存储到本地存储，在此之后的 request head 带上标记位信息。
代理服务器取出 request head 标记位与服务器环境的标记位进行比照，如果资源统一，能够表明用户应用的是最新的前端版本，反之返回 412 状态码，并在 response 中塞入最新的状态码。
前端的 Fetch / XHR 接管 412 响应后，做对应的清理工作并更新本地的标记位。确保客户端始终是最新的资源。
具体措施
step1: Webpack Plugin
首先咱们要生成交给服务器的标记位，个别状况下应用 UUID 作为标记位即可，我司部署计划会应用 Kubernetes 集群部署，在不同的容器环境中，会生成数个 UUID。
出于环境的影响用户拜访的并不是固定某个容器，因而容易呈现代理服务器数次揭示客户端版本滞后的问题。所以最初决定在部署环节应用插件在 webpack emit hooks 生成一个以我的项目版本 + 部署工夫戳为标示的 key，置入最初产出的包中，以兼容 k8s 部署，所有最新的标记位以这份生成的 bundle key 为主。
step2: Additional Shell
定义一份 shell 脚本，将其置入自动化 CD 脚本的开端，此时前端资源曾经存在于服务器上，只需在脚本中取出前端资源的 bundle key 并存入服务器即可，笔者抉择存储在服务器的环境变量中。
step3：Lua / Perl
通过以上环节，服务器筹备工作曾经实现，下一步须要给代理服务器赋能，获得环境变量中的标记位 boundle key。
代理服务器想要拿到对应的 bundle key 并被动推送给客户端，只依附本人是不可能的，但能够借助其余脚本语言实现。通过尝试与钻研，可确定 Lua 和 Perl 反对从服务器环境变量中获取 bundle key。
这里咱们以 nginx 为例看一下，可通过扩大 nginx 的模块，借助 lua-nginx-module 将 nginx 配置文件中的 lua 脚本交给零碎环境的 LuaJIT 代替执行。胜利读取环境变量后，让 nginx 动静加载环境变量中的 bundle key。
step4：Nginx
nginx 获取 boundle key 后须要判断标记位是否统一。
通过下图咱们可知 nginx 的原生逻辑判断能力与 lua 的配合后，能够验证浏览器发送的 request head 信息，若和服务器的 bundle key 不统一，则返回 412 状态码。
因为咱们应用自定义的 response head，依照标准须要以 X 结尾，本例中的响应头为 X -Application-Version。
step5：Front end processing
最初增加客户端校验，判断响应返回的 X -Application-Version 信息，前端能够自定义解决计划，增加任意交互或揭示，以及革除本地资源等操作。
总体流程图
四、可能存在的疑难
Q: 此计划和协商缓存相似，均在 Http Heads 中增加信息进行交互，和那么和传统的协商缓存有那些区别？
A: 其实区别还是十分大的，本计划只是交互模式比拟相似而已。
传统的协商缓存如果要引入代理服务器验证是须要主服务器通过 Cache-Control: public 进行赋能的，并且服务器赋能会有时限和强制确定的限度（s-max-ageproxy-revalidate），而此计划齐全是应用前端在服务器端的动态资源进行赋能的，和源服务器没有实质分割。
传统的协商缓存无奈逾越源服务器呈现故障，缓存拜访过期接口 URL 的等问题，而此计划因为不与源服务器进行交互，齐全自力更生，是十分稳固的计划。
Q: 应用此计划部署前端我的项目后，就曾经失常启动此计划了么？
A: 如果是首次应用本计划，必须事后确保以后浏览器可能获取到最新的前端动态资源，因为如果浏览器缓存着之前版本的前端资源，那么不会触发新版本中前端检测到标识符变动后的交互与清理操作。因而只须要保障首次部署本计划的时候，用户读取的不是缓存，那么之后的任何应用和部署便可无忧。
上文计划曾经在袋鼠云外部通过测试推动并胜利落地。胜利解决了前端资源静默刷新方面的需要，因为笔者程度无限，此计划也只是一个抛砖引玉，必定有值得优化的中央。若读者有更好的倡议，欢送对本文进行评论，帮忙笔者欠缺计划过程。
更多内容欢送关注“数栈研习社”公主号
