零碎背景
问：批改一个网站的文案须要多久？对于一个小型集体网站来说，预计很简略，几分钟就能批改实现并公布。但如果说要批改的是上百个网站的文案呢？那预计就得须要产品提需要，研发排期开发，测试进行回归验证。因为波及的利用泛滥，而每个利用都有本人的研发需要，可能无奈疾速排期进行文案批改。所以看似一个非常简单的需要，波及到的利用和部门比拟多的时候，也就成了产品经理的恶梦。尤其是像京东商城这样的大型购物网站，你浏览过的每一个网页的背地都是有许多个业务零碎在撑持，并由专门的研发团队来负责保护。而各业务零碎为了可能放弃对立的网页格调，往往都会应用雷同的页面头部和尾部，咱们称之为公共头尾。
比方上图，是目前京东网站对立在应用的页面尾部，如果想要批改尾部的文案或者链接，那就须要去推动上百个零碎和研发团队去排期批改并上线。为了解决这一问题，京东对立头尾管理系统就这样诞生了，基本上实现了五分钟批改京东全站公共头尾内容。
目前，对立头尾零碎获得的成绩如下：
零碎总体架构设计
整个零碎次要包含两局部，第一局部是治理后盾，次要用来治理京东的公共头尾文件和业务零碎，配置业务零碎与公共头尾文件的关联关系，并针对业务零碎进行公共头尾文件的散发。第二局部是头尾客户端，次要用来获取业务零碎依赖应用的头尾文件，而后解析渲染页面，将最新版本的头尾文件内容进行输入。而为了应答不同版本语言开发的业务零碎，头尾客户端又分成 Java 客户端和 Nginx 客户端。Java 客户端次要反对 Java 语言开发的业务零碎，不仅能够解析解决动态 HTML，还反对解析 JSP/Velocity/FreeMarker/Thymeleaf 等页面模板引擎。Nginx 客户端则反对了非 Java 语言开发的业务零碎，实现了非 Java 零碎的页面模板解析和渲染公共头尾的性能。
治理后盾设计与实现
整个治理后盾实现了前后端拆散，后端负责提供 HTTP 接口，前端只负责页面渲染。治理后盾依照模块划分，次要分为了三个模块，包含文件治理模块、利用治理模块和集体核心模块。
- 文件治理模块
提供公共头尾文件的保护性能，能够将公共头尾的 HTML 内容在治理后盾进行创立保留，并针对公共头尾文件进行了版本控制，用户能够在治理后盾对头尾文件进行编辑、公布和回滚等操作。
- 利用治理模块
提供业务零碎的保护性能，用户能够在治理后盾增加新利用，创立配置环境，增加业务零碎依赖应用的公共头尾配置关系，查看利用信息以及业务利用接入的头尾客户端申请信息。
- 集体核心模块
用来记录治理后盾用户的各种操作日志，包含文件操作和利用操作，并提供操作日志查问性能。还针对公共头尾文件的公布操作进行上线审批解决。
头尾客户端设计与实现
前边介绍的头尾治理后盾曾经实现了头尾文件创建保护与版本控制，而业务零碎如何依赖援用这些头尾文件，则是咱们下一步须要面临的问题。首先，咱们须要解决的问题就是如何将头尾治理后盾中创立的头尾文件散发到各业务零碎中。目前次要有两种形式，别离是头尾零碎 Push 形式和业务零碎 Pull 形式。
- 头尾零碎 Push 形式：
意味着须要将各业务零碎中每一台服务器作为服务端，而头尾零碎则作为客户端，头尾零碎中的头尾文件有更新时，被动连贯各业务零碎服务端，连贯胜利后，将头尾文件的最新内容发送到业务零碎。为了保障头尾零碎客户端可能随时与各业务零碎服务端建设连贯，须要业务零碎监听固定端口，并时刻提供服务，否则就会有头尾文件 push 失败的危险。而事实环境是京东的业务零碎泛滥，部署环境也是多种多样，还有不同的开发语言。如果要开发头尾服务端，首先就要解决跨语言的问题，京东目前罕用的开发语言有 Java、Js、Php、Golang 和 Lua，咱们就须要提供并保护五种语言的头尾服务端版本。而且因为业务零碎监听的端口泛滥，头尾服务端启动时还会面临着端口被占用的危险，也同样会导致头尾服务端无奈失常启动，从而无奈更新头尾文件。然而该形式也有长处，就是只有在头文件有更新须要 Push 的时候，才建设连贯去 Push，头尾文件不仅可能实时更新并失效，还能够节俭服务器资源。
- 业务零碎 Pull 形式：
该形式与头尾零碎 Push 形式正好相同，将头尾零碎作为服务端，能够解决因端口占用而导致无奈启动的问题，但还是会面临跨语言客户端版本的问题。然而咱们通过对业务零碎进行调研剖析，基本上所有的业务零碎都会用到 Nginx 做为反向代理，这个 Nginx 就给了咱们一个反对跨语言业务零碎的可能。而后只须要开发一个 Java 版本的头尾客户端来给 Java 业务零碎引入并 Pull 头尾文件。不过该形式也有毛病，就是头尾客户端不晓得头尾文件何时会更新，头尾客户端只能定时轮询头尾零碎来查看头尾文件是否有更新，如果文件有更新，则拉取新的头尾文件内容。这样就会造成头尾文件不能实时更新，并且定时轮询也会耗费肯定的服务器和网络资源。
最初通过综合思考，咱们抉择了业务零碎 Pull 形式来进行头尾文件的散发。而为了解决业务零碎跨语言的问题，咱们提供了两个版本的头尾客户端，即 Nginx 头尾客户端和 Java 头尾客户端，根本满足了所有业务零碎的头尾文件拉取性能。然而业务零碎如何援用这些头尾文件，这里就波及到一个 SSI(服务端网页蕴含) 技术。上面就介绍一下两种形式的头尾客户端如何解决头尾文件的拉取和 SSI 问题。
- Nginx 头尾客户端
该形式次要是利用了 Nginx 的 SSI 模块来实现头尾文件的拉取和 SSI 问题，ngx\_http\_ssi\_module 模块是 Nginx 中的一个过滤器，在通过它的响应中解决 SSI（服务端蕴含）指令。目前用到的就是 inclued 指令，配置示例：
<!--# include file="/fragment/footer.html" -->
业务零碎中的页面就通过该配置指令来援用头尾零碎中保护的头尾文件，然而该配置指令须要服务器上实在存在这些文件，才可能被 Nginx 加载并替换。所以只靠该配置还无奈引入头尾零碎中配置的头尾文件，还须要将 inclued 指令引入的文件名称转换成 URL，而后去头尾零碎服务端申请对应版本的头尾文件。所以这里应用了 Nginx 的 URL 重写和反向代理配置来解决头尾文件的拉取问题。到这里，其实一个残缺的头尾文件 SSI 性能曾经实现了，在业务零碎拜访蕴含头尾文件的页面也曾经能够残缺展现了。
然而还是存在一些问题，这里的头尾文件申请是用户浏览页面时被动触发的，而且还是 Nginx 通过反向代理同步申请的头尾文件，所以头尾零碎的响应工夫就间接影响到了业务零碎的页面加载工夫，如果头尾零碎超时，则业务零碎页面也会超时；而且业务零碎（包含京东首页，商详页）的页面流量会全部打到头尾零碎，这都是头尾零碎无奈接受的流量。所以咱们须要缩小业务零碎的申请量，而这些头尾文件的内容自身变动的频率也不太高，所以能够通过 Nginx 来减少一级本地缓存 proxy\_cache。当用户浏览业务零碎页面时，则优先申请本地缓存的头尾文件, 缓存工夫到期后，再去申请头尾零碎获取最新的头尾文件。通过 Nginx 代理缓存的配置，将成千上万的用户申请量优化为每台业务零碎的服务器缓存工夫内只申请一次，大大减少了头尾零碎的申请压力。同时再通过 proxy\_cache\_use\_stale 配置来升高业务系统对头尾零碎的依赖危险，即便头尾零碎呈现宕机问题，也不会影响业务零碎的头尾文件加载展现。上面是 Nginx 客户端局部配置示例：
location ~ ^/fragment/ {
proxy_cache header_cache;
proxy_cache_key $uri;
proxy_cache_valid 200 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_lock_timeout 1s;
proxy_connect_timeout 1s;
proxy_ignore_headers Set-Cookie Cache-Control;
proxy_hide_header Cache-Control;
proxy_hide_header Set-Cookie;
# 参考头尾零碎中配置，请留神辨别测试环境和生产环境，返回的文件内容默认都是 UTF- 8 编码内容，如果须要 GBK 编码内容须要在 env 前面拼接参数?charset=GBK
# 只须要替换 {appId} {token} 和 {env}
rewrite ^/fragment/(.*) /open/fragment/$1/Nginx/$nginx_version/$server_addr/{appId}/{token}/{env} break;
proxy_set_header Accept-Encoding "";
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://xxx.jd.local;
}
- Java 头尾客户端
前边介绍的 Nginx 形式客户端尽管曾经解决了头尾文件的 SSI 问题，但因为 Nginx 的 SSI 过程是在用户拜访页面时才触发的，属于用户申请过程中的同步调用，即便减少了本地缓存，但还是会对页面的响应工夫有所影响。所以为了解决这一性能损耗问题，咱们专门开发了一个 Java 版本的头尾客户端，来实现头尾文件的 SSI 性能。头尾客户端的启动过程如下图：
首先须要业务零碎引入 Java 头尾客户端依赖 jar 包，而后配置头尾零碎中的利用 ID、拜访令牌、环境标识以及须要解析的页面模板门路和模板文件后缀名。配置实现后，头尾客户端会追随业务零碎一起启动。在启动过程中，头尾客户端会首先将头尾零碎中配置的头尾文件下载到业务零碎服务器本地目录中，而后再启动一个异步线程去轮询申请头尾零碎并检测头尾文件更新状况，如果头尾文件有变动，则间接下载最新头尾文件到本地目录中。
头尾文件下载到本地后，头尾客户端会依据配置中的页面模板门路和后缀名去扫描加载所有蕴含 SSI 指令的模板文件到内存中，并创立这些模板文件的备份文件。而后依据加载到内存中的模板文件再去解析模板文件中的 include 指令，最初通过 inclued 指令配置的文件名称加载头尾文件内容进行替换，从而生成新的模板文件。模板解析实现后注册启动一个头尾文件观察者，专门用来监督头尾文件是否更新，如果有更新，再次解析内存中的模板内容生成新的模板文件。这一过程基本上是在业务系统启动时进行的，所以当用户申请业务零碎页面时，业务零碎能够间接将这个模板文件进行返回，防止了在用户申请过程中的 SSI 解决，根本实现了对业务零碎性能的零损耗。
作者：京东批发 曹志飞
起源：京东云开发者社区