php链接头尾技巧_京东统一头尾治理系统探索实践

尤其是像京东商城这样的大型购物网站，你浏览过的每一个网页的背后都是有许多个业务系统在支撑，并由专门的研发团队来卖力掩护。
而各业务系统为了能够保持统一的网页风格，每每都会利用相同的页面头部和尾部，我们称之为公共头尾。

比如上图，是目前京东网站统一在利用的页面尾部，如果想要修正尾部的文案或者链接，那就须要去推动上百个别系和研发团队去排期修正并上线。
为理解决这一问题，京东统一头尾管理系统就这样出身了，基本上实现了五分钟修正京东全站公共头尾内容。

目前，统一头尾系统取得的成果如下：

系统总体架构设计

全体系统紧张包括两部分，第一部分是管理后台，紧张用来管理京东的公共头尾文件和业务系统，配置业务系统与公共头尾文件的关联关系，并针对业务系统进行公共头尾文件的分发。
第二部分是头尾客户端，紧张用来获取业务系统依赖利用的头尾文件，然后解析渲染页面，将最新版本的头尾文件内容进行输出。
而为了应对不同版本措辞开拓的业务系统，头尾客户端又分成 Java 客户端和 Nginx 客户端。
Java 客户端紧张支持 Java 措辞开拓的业务系统，不仅可以解析处理静态 HTML，还支持解析 JSP/Velocity/FreeMarker/Thymeleaf 等页面模板引擎。
Nginx 客户端则支持了非 Java 措辞开拓的业务系统，实现了非 Java 系统的页面模板解析和渲染公共头尾的功能。

全体管理后台实现了前后端分离，后端卖力供应 HTTP 接口，前端只卖力页面渲染。
管理后台按照模块划分，紧张分为了三个模块，包括文件管理模块、运用管理模块和个人中央模块。

供应公共头尾文件的掩护功能，可以将公共头尾的 HTML 内容在管理后台进行创建保存，并针对公共头尾文件进行了版本掌握，用户可以在管理后台敌人尾文件进行编辑、发布和回滚等操作。

供应业务系统的掩护功能，用户可以在管理后台添加新运用，创建配置环境，添加业务系统依赖利用的公共头尾配置关系，查看运用信息以及业务运用接入的头尾客户端要求信息。

用来记录管理后台用户的各种操作日志，包括文件操作和运用操作，并供应操作日志查询功能。
还针对公共头尾文件的发布操作进行上线审批处理。

前边先容的头尾管理后台已经实现了头尾文件创建掩护与版本掌握，而业务系统如何依赖引用这些头尾文件，则是我们下一步须要面临的问题。
首先，我们须要办理的问题便是如何将头尾管理后台中创建的头尾文件分发到各业务系统中。
目前紧张有两种办法，分别是头尾系统 Push 办法和业务系统 Pull 办法。

意味着须要将各业务系统中每一台做事器作为做事端，而头尾系统则作为客户端，头尾系统中的头尾文件有更新时，主动连接各业务系统做事端，连接成功后，将头尾文件的最新内容发送到业务系统。
为了担保头尾系统客户端能够随时与各业务系统做事端建立连接，须要业务系统监听固定端口，并时候供应做事，否则就会有头尾文件 push 失落败的风险。
而现实环境是京东的业务系统浩瀚，支配环境也是多种多样，还有不同的开拓措辞。

如果要开拓头尾做事端，首先就要办理跨措辞的问题，京东目前常用的开拓措辞有 Java、Js、Php、Golang 和 Lua，我们就须要供应并掩护五种措辞的头尾做事端版本。
而且由于业务系统监听的端口浩瀚，头尾做事端启动时还会面临着端口被占用的风险，也同样会导致头尾做事端无法正常启动，从而无法更新头尾文件。
但是该办法也有优点，便是只有在头文件有更新须要 Push 的时候，才建立连接去 Push，头尾文件不仅能够实时更新并生效，还可以节省做事器资源。

该办法与头尾系统 Push 办法恰好相反，将头尾系统作为做事端，可以办理因端口占用而导致无法启动的问题，但还是会面临跨措辞客户端版本的问题。
但是我们通过对业务系统进行调研剖析，基本上所有的业务系统都会用到 Nginx 做为反向代理，这个 Nginx 就给了我们一个支持跨措辞业务系统的可能。
然后只须要开拓一个 Java 版本的头尾客户端来给 Java 业务系统引入并 Pull 头尾文件。
不过该办法也有缺点，便是头尾客户端不知道头尾文件何时会更新，头尾客户端只能定时轮询头尾系统来检讨头尾文件是否有更新，如果文件有更新，则拉取新的头尾文件内容。
这样就会造成头尾文件不能实时更新，并且定时轮询也会花费一定的做事器和网络资源。

末了经由综合考虑，我们选择了业务系统 Pull 办法来进行头尾文件的分发。
而为理解决业务系统跨措辞的问题，我们供应了两个版本的头尾客户端，即 Nginx 头尾客户端和 Java 头尾客户端，基本知足了所有业务系统的头尾文件拉取功能。
但是业务系统如何引用这些头尾文件，这里就涉及到一个 SSI (做事端网页包含) 技能。
下面就先容一下两种办法的头尾客户端如何办理头尾文件的拉取和 SSI 问题。

该办法紧张是利用了 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 处理，基本实现了对业务系统性能的零损耗。

作者：京东零售 曹志飞

来源：京东云开拓者社区

标签：头尾系统