方案的架构下面我们从宏观架构的角度进一步深入浅出的讲解本文的解决方案。框架如下图1所示：
图 1. 框架示例 图1中：SWR， static web resource 的英文首字母简写。AA，active active的简写。SS，SampleServlet的简写。SF，Side Flip 的简写。就是部署完成后，准备上线的程序逻辑。只有被zooKeeper选中的节点才会执行此程序逻辑。
浏览器对静态资源的请求发送到了负载均衡服务器F5，F5根据路由规则（active-active 的iRule）把请求发给SideA 或SideB。SideA 部署的是旧版本的SampleApp应用程序，版本号是20170509-1101。SideB 部署的是新版本的SampleApp 应用程序，版本号是20170609-1704。
假定请求URL是http://sampleCompany/sample/static/20170509-1101/js/SampleApp.js，如果SideA 中的结点服务器收到了请求，SampleServlet匹配版本号，从本地加载文件返回客户端。如果SideB中的结点服务器收到了请求，SampleServlet 访问NFS 文件服务器加载文件并返回给客户端。
细心的读者可能会问，既然不同的Web服务应用版本同时存在，有没有可能新上线的应用服务中返回了旧版本的SampleApp.js 文件，而已经在线的应用服务请求得到了新上线的SampleApp.js文件呢？答案是：不可能存在这种情况。第一次请求被负载均衡服务器路由到了某个应用服务器，该应用服务器返回给客户端HTML主页面（通常采用Ajax 富客户端开发的应用程序，只有一个HTML 主页面），它负责加载与应用服务器上版本相对应的javascript，css，图片等静态资源文件。进而通过Session, cookie 等技术让客户端保持对应用服务器的持久化连接。一言以蔽之，想要的静态资源文件从哪里来不打紧，只要是对应版本的就可以了。
正如本文开篇所说的那样，我们期望，用户已经打开的应用程序可继续连接到旧版本SideA 上。新版本SideB 已经上线了，用户登陆后打开应用程序，会得到最新的应用服务。旧版本持续服务一段时间就会升级成和SideB 一样的版本。
小结本文深入浅出的讲解了多个版本静态资源文件管理问题的由来及解决方案。多个版本的静态资源可同时存在于应用服务器集群中。这种部署策略加快了云上产品新功能服务上线的周期，降低了云上产品运维的风险，提供了更好的用户体验。解决方案则简单易行，开发人员需要自己动手写Servlet 响应静态资源的请求。先从结点本地去获取静态资源文件，如果不能找到则去NFS 服务器上下载对应版本的资源文件，缓存后，返回给客户端。在部署的过程中，应用zookeeper 选择一个应用服务器结点完成对NFS 服务器上静态资源文件的上传、删除等管理操作。希望读者能从本文的讲解中获益，圆满解决多版本静态资源文件管理的问题。 |
