京东前台PC首页系统技术详解 _京东

京东零售系统在2018年实现前中台架构的调整与划分。中台实现基础服务组件开发，前台主要对接用户请求，通过对中台RPC数据的聚合，来满足用户多样化需求。其前台系统又分为首页系统、单品系统、搜索系统、列表系统、订单系统等等。
作为PC首页研发，本文主要讲解PC首页的技术实现。
PC首页业务逻辑从最初的模板渲染，到后来的SSI模块加载以及现在的前后端分离。开发语言也从之前的ASP、php逐步过渡到以LUA为主的技术框架。通过技术迭代升级，首页页面打开速度从之前的200ms缩减到30ms内，API性能从之前的500ms优化至100ms左右。
京东零售系统，每天承载着亿万网民的购物需求。PC首页又是京东商城的一级入口，所以系统必须达到以下3方面要求：页面完整性(容灾、兜底、降级)；流畅的加载速度(高并发、页面加载优化、API加载优化)；监控&告警。
【京东前台PC首页系统技术详解】下面将根据系统设定目标逐步讲解首页系统实现方案。
1.页面完整性
页面完整性指任何时候访问页面均需呈现正常的页面样式，不得出现天窗以及非200状态码(40x、50x等) 。如下图楼层，若将单模块缺失直接呈现给用户，将导致页面天窗，影响体验。在单模块异常时，系统可对整楼层隐藏操作，优先保证页面完整显示。

文章插图

下面从6方面讲解容灾降级的业务逻辑：
页面的容灾：前端页面主要承载页面骨架，也会包含部分开关配置及必要的兜底数据，即使后端API服务异常，html依然可以提供基础的用户体验。前端页面由模板渲染生成，其中模板变量通过配置中心（蜂巢系统）维护，定时worker触发生成前端页面，然后推送到静态资源服务器，最终通过CDN加速提供服务。其中在worker触发生成html阶段执行多层验证逻辑，保证html的完整性。
接口的容灾：一般接口逻辑均是优先读取缓存数据，若缓存失效则继续读取上游RPC数据来输出。但上游系统均不保证100%可用，如何保证在上游异常的情况下提供可靠服务使页面正常渲染呢？PC首页系统在接口层面做了2方面工作：
第一、接口在读取&聚合上游RPC数据后会保存两部分缓存，一个为正常用户加速缓存，一般会设置5min过期时间，一个是兜底缓存，永不过期。当缓存或者上游RPC服务均不可用时，接口会读取兜底缓存保证正常的数据输出。
第二、如果API服务由于自身问题（例如宿主机异常、redis服务异常、用户网络抖动等）导致无法提供正常的服务怎么办。为了避免这个问题，系统为API提供了一条新的访问途径-CDN API 。CDN API会访问由Worker定时生成的静态结果集（File）输出数据。当前端异步加载数据感知常规线路异常后自动触发CDN API线路来保证接口可用性。
依据上面2种兜底逻辑，绘制如下流程图，此逻辑将首页API服务的可靠率提高至100% 。

文章插图

接口的降级：如下图所示，正常情况接口通过读取Cache、RPC数据、兜底Cache提供服务。但如果Cache和RPC服务均异常，接口的响应时间就大大浪费在前两阶段（10ms+100ms）。为了避免此情况的发生，系统通过配置中心（蜂巢系统）设置降级开关，当系统感知降级开关打开时，将直接读取兜底Cache，保证API的响应速度。

文章插图

Nginx的容灾：NGINX容灾指系统监控到接口非200状态码的时候在NGINX层面执行兜底逻辑，此兜底逻辑可以读取（或代理）远程静态资源实现透明容灾。具体实现通过error_page指令完成，error_page指令可以在特定的状态码设置一个named location，并在其代码块中执行相应的兜底业务逻辑。
楼层容灾：在多模块楼层，前端会调用多个API进行页面渲染。如下图所示，此楼层一共包含4个模块，每个模块均提供独立的API接口。当其中一个模块API异常，即触发楼层隐藏动作，避免天窗的出现。（这里执行的是页面可以有损但必须完整的策略）