【转】构建需求响应式亿级商品详情页

[京东技术]声明：本文转载自微信公众号“开涛的博客”，转载务必声明。

 

该文章是根据velocity 2015技术大会的演讲《京东网站单品页618实战》细化而来，希望对大家有用。

 

商品详情页是什么

商品详情页是展示商品详细信息的一个页面，承载在网站的大部分流量和订单的入口。京东商城目前有通用版、全球购、闪购、易车、惠买车、服装、拼购、今日抄底等许多套模板。各套模板的元数据是一样的，只是展示方式不一样。目前商品详情页个性化需求非常多，数据来源也是非常多的，而且许多基础服务做不了的都放我们这，因此我们需要一种架构能快速响应和优雅的解决这些需求问题。因此我们重新设计了商品详情页的架构，主要包括三部分：商品详情页系统、商品详情页统一服务系统和商品详情页动态服务系统；商品详情页系统负责静的部分，而统一服务负责动的部分，而动态服务负责给内网其他系统提供一些数据服务。

    

商品详情页前端结构

前端展示可以分为这么几个维度：商品维度(标题、图片、属性等)、主商品维度（商品介绍、规格参数）、分类维度、商家维度、店铺维度等；另外还有一些实时性要求比较高的如实时价格、实时促销、广告词、配送至、预售等是通过异步加载。

京东商城还有一些特殊维度数据：比如套装、手机合约机等，这些数据是主商品数据外挂的。

 

我们的性能数据

618当天PV数亿，618当天服务器端响应时间<38ms。此处我们用的是第1000次中第99次排名的时间。   

单品页流量特点

离散数据，热点少，各种爬虫、比价软件抓取。

 

单品页技术架构发展

 

架构1.0

 IIS+C#+Sql Server，最原始的架构，直接调用商品库获取相应的数据，扛不住时加了一层memcached来缓存数据。这种方式经常受到依赖的服务不稳定而导致的性能抖动。

 

架构2.0

 

 该方案使用了静态化技术，按照商品维度生成静态化HTML。主要思路：

1、通过MQ得到变更通知；

2、通过Java Worker调用多个依赖系统生成详情页HTML；

3、通过rsync同步到其他机器；

4、通过Nginx直接输出静态页；

5、接入层负责负载均衡。

 

该方案的主要缺点：

1、假设只有分类、面包屑变更了，那么所有相关的商品都要重刷；

2、随着商品数量的增加，rsync会成为瓶颈；

3、无法迅速响应一些页面需求变更，大部分都是通过JavaScript动态改页面元素。

 

随着商品数量的增加这种架构的存储容量到达了瓶颈，而且按照商品维度生成整个页面会存在如分类维度变更就要全部刷一遍这个分类下所有信息的问题，因此我们又改造了一版按照尾号路由到多台机器。

 

 主要思路：

1、容量问题通过按照商品尾号做路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到11台；

2、按维度生成HTML片段（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是一个大HTML；

3、通过Nginx SSI合并片段输出；

4、接入层负责负载均衡；

5、多机房部署也无法通过rsync同步，而是使用部署多套相同的架构来实现。

 

该方案主要缺点：

1、碎片文件太多，导致如无法rsync；

2、机械盘做SSI合并时，高并发时性能差，此时我们还没有尝试使用SSD；

3、模板如果要变更，数亿商品需要数天才能刷完；

4、到达容量瓶颈时，我们会删除一部分静态化商品，然后通过动态渲染输出，动态渲染系统在高峰时会导致依赖系统压力大，抗不住；

5、还是无法迅速响应一些业务需求。

 

我们的痛点

1、之前架构的问题存在容量问题，很快就会出现无法全量静态化，还是需要动态渲染；不过对于全量静态化可以通过分布式文件系统解决该问题，这种方案没有尝试；

2、最主要的问题是随着业务的发展，无法满足迅速变化、还有一些变态的需求。

 

架构3.0

我们要解决的问题：

1、能迅速响瞬变的需求，和各种变态需求；

2、支持各种垂直化页面改版；

3、页面模块化；

4、AB测试；

5、高性能、水平扩容；

6、多机房多活、异地多活。

 

主要思路：

1、数据变更还是通过MQ通知；

2、数据异构Worker得到通知，然后按照一些维度进行数据存储，存储到数据异构JIMDB集群（JIMDB：Redis+持久化引擎），存储的数据都是未加工的原子化数据，如商品基本信息、商品扩展属性、商品其他一些相关信息、商品规格参数、分类、商家信息等；

3、数据异构Worker存储成功后，会发送一个MQ给数据同步Worker，数据同步Worker也可以叫做数据聚合Worker，按照相应的维度聚合数据存储到相应的JIMDB集群；三个维度：基本信息（基本信息+扩展属性等的一个聚合）、商品介绍（PC版、移动版）、其他信息（分类、商家等维度，数据量小，直接Redis存储）；

4、前端展示分为两个：商品详情页和商品介绍，使用Nginx+Lua技术获取数据并渲染模板输出。

 

另外我们目前架构的目标不仅仅是为商品详情页提供数据，只要是Key-Value获取的而非关系的我们都可以提供服务，我们叫做动态服务系统。  

该动态服务分为前端和后端，即公网还是内网，如目前该动态服务为列表页、商品对比、微信单品页、总代等提供相应的数据来满足和支持其业务。

 

详情页架构设计原则

1、数据闭环

2、数据维度化

3、拆分系统

4、Worker无状态化+任务化

5、异步化+并发化

6、多级缓存化

7、动态化

8、弹性化

9、降级开关

10、多机房多活

11、多种压测方案

 

 

数据闭环

 数据闭环即数据的自我管理，或者说是数据都在自己系统里维护，不依赖于任何其他系统，去依赖化；这样得到的好处就是别人抖动跟我没关系。

 

数据异构，是数据闭环的第一步，将各个依赖系统的数据拿过来，按照自己的要求存储起来；

 

数据原子化，数据异构的数据是原子化数据，这样未来我们可以对这些数据再加工再处理而响应变化的需求；

 

数据聚合，将多个原子数据聚合为一个大JSON数据，这样前端展示只需要一次get，当然要考虑系统架构，比如我们使用的Redis改造，Redis又是单线程系统，我们需要部署更多的Redis来支持更高的并发，另外存储的值要尽可能的小；

 

数据存储，我们使用JIMDB，Redis加持久化存储引擎，可以存储超过内存N倍的数据量，我们目前一些系统是Redis+LMDB引擎的存储，目前是配合SSD进行存储；另外我们使用Hash Tag机制把相关的数据哈希到同一个分片，这样mget时不需要跨分片合并。

 

我们目前的异构数据时键值结构的，用于按照商品维度查询，还有一套异构时关系结构的用于关系查询使用。

 

详情页架构设计原则 / 数据维度化

对于数据应该按照维度和作用进行维度化，这样可以分离存储，进行更有效的存储和使用。我们数据的维度比较简单：

1、商品基本信息，标题、扩展属性、特殊属性、图片、颜色尺码、规格参数等；

2、商品介绍信息，商品维度商家模板、商品介绍等；

3、非商品维度其他信息，分类信息、商家信息、店铺信息、店铺头、品牌信息等；

4、商品维度其他信息（异步加载），价格、促销、配送至、广告词、推荐配件、最佳组合等。 

 

拆分系统

 将系统拆分为多个子系统虽然增加了复杂性，但是可以得到更多的好处，比如数据异构系统存储的数据是原子化数据，这样可以按照一些维度对外提供服务；而数据同步系统存储的是聚合数据，可以为前端展示提供高性能的读取。而前端展示系统分离为商品详情页和商品介绍，可以减少相互影响；目前商品介绍系统还提供其他的一些服务，比如全站异步页脚服务。

 

 

Worker无状态化+任务化 

1、数据异构和数据同步Worker无状态化设计，这样可以水平扩展；

2、应用虽然是无状态化的，但是配置文件还是有状态的，每个机房一套配置，这样每个机房只读取当前机房数据；

3、任务多队列化，等待队列、排重队列、本地执行队列、失败队列；

4、队列优先级化，分为：普通队列、刷数据队列、高优先级队列；例如一些秒杀商品会走高优先级队列保证快速执行；

5、副本队列，当上线后业务出现问题时，修正逻辑可以回放，从而修复数据；可以按照比如固定大小队列或者小时队列设计；

6、在设计消息时，按照维度更新，比如商品信息变更和商品上下架分离，减少每次变更接口的调用量，通过聚合Worker去做聚合。

 

异步化+并发化

 我们系统大量使用异步化，通过异步化机制提升并发能力。首先我们使用了消息异步化 进行系统解耦合，通过消息通知我变更，然后我再调用相应接口获取相关数据；之前老系统使用同步推送机制，这种方式系统是紧耦合的，出问题需要联系各个负责人重新推送还要考虑失败重试机制。数据更新异步化 ，更新缓存时，同步调用服务，然后异步更新缓存。可并行任务并发化， 商品数据系统来源有多处，但是可以并发调用聚合，这样本来串行需要1s的经过这种方式我们提升到300ms之内。异步请求合并，异步请求做合并，然后一次请求调用就能拿到所有数据。前端服务异步化/聚合，实时价格、实时库存异步化， 使用如线程或协程机制将多个可并发的服务聚合。异步化还一个好处就是可以对异步请求做合并，原来N次调用可以合并为一次，还可以做请求的排重。

 

多级缓存化

浏览器缓存，当页面之间来回跳转时走local cache，或者打开页面时拿着Last-Modified去CDN验证是否过期，减少来回传输的数据量；

CDN缓存，用户去离自己最近的CDN节点拿数据，而不是都回源到北京机房获取数据，提升访问性能；

服务端应用本地缓存，我们使用Nginx+Lua架构，使用HttpLuaModule模块的shared dict做本地缓存（ reload不丢失）或内存级Proxy Cache，从而减少带宽；

另外我们还使用使用一致性哈希（如商品编号/分类）做负载均衡内部对URL重写提升命中率；

我们对mget做了优化，如去商品其他维度数据，分类、面包屑、商家等差不多8个维度数据，如果每次mget获取性能差而且数据量很大，30KB以上；而这些数据缓存半小时也是没有问题的，因此我们设计为先读local cache，然后把不命中的再回源到remote cache获取，这个优化减少了一半以上的remote cache流量；

服务端分布式缓存，我们使用内存+SSD+JIMDB持久化存储。

 

动态化

数据获取动态化，商品详情页：按维度获取数据，商品基本数据、其他数据（分类、商家信息等）；而且可以根据数据属性，按需做逻辑，比如虚拟商品需要自己定制的详情页，那么我们就可以跳转走，比如全球购的需要走jd.hk域名，那么也是没有问题的；

模板渲染实时化，支持随时变更模板需求；

重启应用秒级化，使用Nginx+Lua架构，重启速度快，重启不丢共享字典缓存数据；

需求上线速度化，因为我们使用了Nginx+Lua架构，可以快速上线和重启应用，不会产生抖动；另外Lua本身是一种脚本语言，我们也在尝试把代码如何版本化存储，直接内部驱动Lua代码更新上线而不需要重启Nginx。

 

 

弹性化

我们所有应用业务都接入了Docker容器，存储还是物理机；我们会制作一些基础镜像，把需要的软件打成镜像，这样不用每次去运维那安装部署软件了；未来可以支持自动扩容，比如按照CPU或带宽自动扩容机器，目前京东一些业务支持一分钟自动扩容。

 

降级开关

推送服务器推送降级开关，开关集中化维护，然后通过推送机制推送到各个服务器；

可降级的多级读服务，前端数据集群--->数据异构集群--->动态服务(调用依赖系统)；这样可以保证服务质量，假设前端数据集群坏了一个 磁盘，还可以回源到数据异构集群获取数据；

开关前置化，如Nginx--àTomcat，在Nginx上做开关，请求就到不了后端，减少后端压力；

可降级的业务线程池隔离，从Servlet3开始支持异步模型，Tomcat7/Jetty8开始支持，相同的概念是Jetty6的Continuations。我们可以把处理过程分解为一个个的事件。通过这种将请求划分为事件方式我们可以进行更多的控制。如，我们可以为不同的业务再建立不同的线程池进行控制：即我们只依赖tomcat线程池进行请求的解析，对于请求的处理我们交给我们自己的线程池去完成；这样tomcat线程池就不是我们的瓶颈，造成现在无法优化的状况。通过使用这种异步化事件模型，我们可以提高整体的吞吐量，不让慢速的A业务处理影响到其他业务处理。慢的还是慢，但是不影响其他的业务。我们通过这种机制还可以把tomcat线程池的监控拿出来，出问题时可以直接清空业务线程池，另外还可以自定义任务队列来支持一些特殊的业务。

  

多机房多活

应用无状态，通过在配置文件中配置各自机房的数据集群来完成数据读取。

数据集群采用一主三从结构，防止当一个机房挂了，另一个机房压力大产生抖动。

多种压测方案

线下压测，Apache ab，Apache Jmeter，这种方式是固定url压测，一般通过访问日志收集一些url进行压测，可以简单压测单机峰值吞吐量，但是不能作为最终的压测结果，因为这种压测会存在热点问题；

线上压测，可以使用Tcpcopy直接把线上流量导入到压测服务器，这种方式可以压测出机器的性能，而且可以把流量放大，也可以使用Nginx+Lua协程机制把流量分发到多台压测服务器，或者直接在页面埋点，让用户压测，此种压测方式可以不给用户返回内容。

 

遇到的一些坑和问题

 

SSD性能差

使用SSD做KV存储时发现磁盘IO非常低。配置成RAID10的性能只有3~6MB/s；配置成RAID0的性能有~130MB/s，系统中没有发现CPU，MEM，中断等瓶颈。一台服务器从RAID1改成RAID0后，性能只有~60MB/s。这说明我们用的SSD盘性能不稳定。

根据以上现象，初步怀疑以下几点：SSD盘，线上系统用的三星840Pro是消费级硬盘。RAID卡设置，Write back和Write through策略。后来测试验证，有影响，但不是关键。RAID卡类型，线上系统用的是LSI 2008，比较陈旧。

 

本实验使用dd顺序写操作简单测试，严格测试需要用FIO等工具。

 

 

键值存储选型压测

我们对于存储选型时尝试过LevelDB、RocksDB、BeansDB、LMDB、Riak等，最终根据我们的需求选择了LMDB。

机器：2台

配置：32核CPU、32GB内存、SSD（(512GB)三星840Pro--> (600GB)Intel 3500 /Intel S3610）

数据：1.7亿数据（800多G数据）、大小5~30KB左右

KV存储引擎：LevelDB、RocksDB、LMDB，每台启动2个实例

压测工具：tcpcopy直接线上导流

压测用例：随机写+随机读

 

LevelDB压测时，随机读+随机写会产生抖动（我们的数据出自自己的监控平台，分钟级采样）。

RocksDB是改造自LevelDB，对SSD做了优化，我们压测时单独写或读，性能非常好，但是读写混合时就会因为归并产生抖动。  

 

LMDB引擎没有大的抖动，基本满足我们的需求。

 

我们目前一些线上服务器使用的是LMDB，其他一些正在尝试公司自主研发的CycleDB引擎。

 

 

数据量大时JIMDB同步不动

Jimdb数据同步时要dump数据，SSD盘容量用了50%以上，dump到同一块磁盘容量不足。解决方案：

1、一台物理机挂2块SSD(512GB)，单挂raid0；启动8个jimdb实例；这样每实例差不多125GB左右；目前是挂4块，raid0；新机房计划8块raid10；

2、目前是千兆网卡同步，同步峰值在100MB/s左右；

3、dump和sync数据时是顺序读写，因此挂一块SAS盘专门来同步数据；

4、使用文件锁保证一台物理机多个实例同时只有一个dump；

5、后续计划改造为直接内存转发而不做dump。

 

切换主从

之前存储架构是一主二从（主机房一主一从，备机房一从）切换到备机房时，只有一个主服务，读写压力大时有抖动，因此我们改造为之前架构图中的一主三从。

 

分片配置

 

之前的架构是分片逻辑分散到多个子系统的配置文件中，切换时需要操作很多系统；解决方案：

1、引入Twemproxy中间件，我们使用本地部署的Twemproxy来维护分片逻辑；

2、使用自动部署系统推送配置和重启应用，重启之前暂停mq消费保证数据一致性；

3、用unix domain socket减少连接数和端口占用不释放启动不了服务的问题。

 

 

模板元数据存储HTML

起初不确定Lua做逻辑和渲染模板性能如何，就尽量减少for、if/else之类的逻辑；通过java worker组装html片段存储到jimdb，html片段会存储诸多问题，假设未来变了也是需要全量刷出的，因此存储的内容最好就是元数据。因此通过线上不断压测，最终jimdb只存储元数据，lua做逻辑和渲染；逻辑代码在3000行以上；模板代码1500行以上，其中大量for、if/else，目前渲染性能可以接受。

 

线上真实流量，整体性能从TP99 53ms降到32ms。

绑定8 CPU测试的，渲染模板的性能可以接受。

 

 

库存接口访问量600w/分钟

商品详情页库存接口2014年被恶意刷，每分钟超过600w访问量，tomcat机器只能定时重启；因为是详情页展示的数据，缓存几秒钟是可以接受的，因此开启nginx proxy cache来解决该问题，开启后降到正常水平；我们目前正在使用Nginx+Lua架构改造服务，数据过滤、URL重写等在Nginx层完成，通过URL重写+一致性哈希负载均衡，不怕随机URL，一些服务提升了10%+的缓存命中率。

 

 

微信接口调用量暴增

通过访问日志发现某IP频繁抓取；而且按照商品编号遍历，但是会有一些不存在的编号；解决方案：

1、读取KV存储的部分不限流；

2、回源到服务接口的进行请求限流，保证服务质量。

 

开启Nginx Proxy Cache性能不升反降

 

开启Nginx Proxy Cache后，性能下降，而且过一段内存使用率到达98%；解决方案：

1、对于内存占用率高的问题是内核问题，内核使用LRU机制，本身不是问题，不过可以通过修改内核参数

sysctl -w vm.extra_free_kbytes=6436787

sysctl -w vm.vfs_cache_pressure=10000

2、使用Proxy Cache在机械盘上性能差可以通过tmpfs缓存或nginx共享字典缓存元数据，或者使用SSD，我们目前使用内存文件系统。

 

配送至读服务因依赖太多，响应时间偏慢

配送至服务每天有数十亿调用量，响应时间偏慢。解决方案：

1、串行获取变并发获取，这样一些服务可以并发调用，在我们某个系统中能提升一倍多的性能，从原来TP99差不多1s降到500ms以下；

2、预取依赖数据回传，这种机制还一个好处，比如我们依赖三个下游服务，而这三个服务都需要商品数据，那么我们可以在当前服务中取数据，然后回传给他们，这样可以减少下游系统的商品服务调用量，如果没有传，那么下游服务再自己查一下。

 

假设一个读服务是需要如下数据：

1、数据A  10ms

2、数据B  15ms

3、数据C   20ms

4、数据D   5ms

5、数据E   10ms

那么如果串行获取那么需要：60ms；

而如果数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C；那么我们可以这样子来获取数据：

那么如果并发化获取那么需要：30ms；能提升一倍的性能。

 

假设数据E还依赖数据F(5ms)，而数据F是在数据E服务中获取的，此时就可以考虑在此服务中在取数据A/B/D时预取数据F，那么整体性能就变为了：25ms。

 

通过这种优化我们服务提升了差不多10ms性能。

如下服务是在抖动时的性能，老服务TP99 211ms，新服务118ms，此处我们主要就是并发调用+超时时间限制，超时直接降级。

  

 

网络抖动时，返回502错误

Twemproxy配置的timeout时间太长，之前设置为5s，而且没有分别针对连接、读、写设置超时。后来我们减少超时时间，内网设置在150ms以内，当超时时访问动态服务。

 

机器流量太大

2014年双11期间，服务器网卡流量到了400Mbps，CPU 30%左右。原因是我们所有压缩都在接入层完成，因此接入层不再传入相关请求头到应用，随着流量的增大，接入层压力过大，因此我们把压缩下方到各个业务应用，添加了相应的请求头，Nginx GZIP压缩级别在2~4吞吐量最高；应用服务器流量降了差不多5倍；目前正常情况CPU在4%以下。

 

总结

数据闭环

数据维度化

拆分系统

Worker无状态化+任务化

异步化+并发化

多级缓存化

动态化

弹性化

降级开关

多机房多活

多种压测方案

Nginx接入层线上灰度引流

接入层转发时只保留有用请求头

使用不需要cookie的无状态域名（如c.3.cn），减少入口带宽

Nginx Proxy Cache只缓存有效数据，如托底数据不缓存

使用非阻塞锁应对local cache失效时突发请求到后端应用(lua-resty-lock/proxy_cache_lock)

使用Twemproxy减少Redis连接数

使用unix domain socket套接字减少本机TCP连接数

设置合理的超时时间（连接、读、写）

使用长连接减少内部服务的连接数

去数据库依赖（协调部门迁移数据库是很痛苦的，目前内部使用机房域名而不是ip），服务化

客户端同域连接限制，进行域名分区：c0.3.cn  c1.3.cn，如果未来支持HTTP/2.0的话，就不再适用了。

 

下文是根据OpenResty Con 2015技术大会的演讲《Nginx+Lua在京东商品详情页的大规模应用》细化而来，希望对大家有用。

 

京东商品详情页技术方案在之前《构建需求响应式亿级商品详情页》这篇文章已经为大家揭秘了，接下来为大家揭秘下双十一抗下几十亿流量的商品详情页统一服务架构，这次双十一整个商品详情页没有出现不服务的情况，服务非常稳定。统一服务提供了：促销和广告词合并服务、库存状态/配送至服务、延保服务、试用服务、推荐服务、图书相关服务、详情页优惠券服务、今日抄底服务等服务支持；这些服务中有我们自己做的服务实现，而有些是简单做下代理或者接口做了合并输出到页面，我们聚合这些服务到一个系统的目的是打造服务闭环，优化现有服务，并为未来需求做准备，跟着自己的方向走，而不被别人乱了我们的方向。

 

大家在页面中看到的c.3.cn/c0.3.cn/c1.3.cn/cd.jd.com请求都是统一服务的入口。

 

为什么需要统一服务

商品详情页虽然只有一个页面，但是依赖的服务众多，我们需要把控好入口，一统化管理。这样的好处：统一管理和监控，出问题可以统一降级；可以把一些相关接口合并输出，减少页面的异步加载请求；一些前端逻辑后移到服务端，前端只做展示，不进行逻辑处理。

 

有了它，所有入口都在我们服务中，我们可以更好的监控和思考我们页面的服务，让我们能运筹于帷幄之中，决胜于千里之外。在设计一个高度灵活的系统时，要想着当出现问题时怎么办：是否可降级、不可降级怎么处理、是否会发送滚雪球问题、如何快速响应异常；完成了系统核心逻辑只是保证服务能工作，服务如何更好更有效或者在异常情况下能正常工作也是我们要深入思考和解决的问题。

 

整体架构

 

 

整体流程：

1、请求首先进入Nginx，Nginx调用Lua进行一些前置逻辑处理，如果前置逻辑不合法直接返回；然后查询本地缓存，如果命中直接返回数据；

2、如果本地缓存不命中数据，则查询分布式Redis集群，如果命中数据，则直接返回；

3、如果分布式Redis集群不命中，则会调用Tomcat进行回源处理；然后把结果异步写入Redis集群，并返回。

如上是整个逻辑流程，可以看到我们在Nginx这一层做了很多前置逻辑处理，以此来减少后端压力，另外我们Redis集群分机房部署，如下所示：

 

即数据会写一个主集群，然后通过主从方式把数据复制到其他机房，而各个机房读自己的集群；此处没有在各个机房做一套独立的集群来保证机房之间没有交叉访问，这样做的目的是保证数据一致性。

 

在这套新架构中，我们可以看到Nginx+Lua已经是我们应用的一部分，我们在实际使用中，也是把它做为项目开发，做为应用进行部署。

 

一些架构思路和总结

我们主要遵循如下几个原则设计系统架构：

• 两种读服务架构模式
• 本地缓存
• 多级缓存
• 统一入口/服务闭环
• 引入接入层
• 前端业务逻辑后置
• 前端接口服务端聚合
• 服务隔离

  

两种读服务架构模式

1、读取分布式Redis数据架构

 

可以看到Nginx应用和Redis单独部署，这种方式是一般应用的部署模式，也是我们统一服务的部署模式，此处会存在跨机器、跨交换机或跨机柜读取Redis缓存的情况，但是不存在跨机房情况，因为通过主从把数据复制到各个机房。如果对性能要求不是非常苛刻，可以考虑这种架构，比较容易维护。

 

2、读取本地Redis数据架构

 

可以看到Nginx应用和Redis集群部署在同一台机器，这样好处可以消除跨机器、跨交换机或跨机柜，甚至跨机房调用。如果本地Redis集群不命中， 还是回源到Tomcat集群进行取数据。此种方式可能受限于TCP连接数，可以考虑使用unix domain socket套接字减少本机TCP连接数。如果单机内存成为瓶颈（比如单机内存最大256GB），就需要路由机制来进行Sharding，比如按照商品尾号Sharding，Redis集群一般采用树状结构挂主从部署。

 

 

本地缓存

我们把Nginx作为应用部署，因此我们大量使用Nginx共享字典作为本地缓存，Nginx+Lua架构中，使用HttpLuaModule模块的shared dict做本地缓存（ reload不丢失）或内存级Proxy Cache，提升缓存带来的性能并减少带宽消耗；另外我们使用一致性哈希（如商品编号/分类）做负载均衡内部对URL重写提升命中率。

 

我们在缓存数据时采用了维度化存储缓存数据，增量获取失效缓存数据（比如10个数据，3个没命中本地缓存，只需要取这3个即可）；维度如商家信息、店铺信息、商家评分、店铺头、品牌信息、分类信息等；比如我们本地缓存30分钟，调用量减少差不多3倍。

另外我们使用一致性哈希+本地缓存，如库存数据缓存5秒，平常命中率：本地缓存25%；分布式Redis28%；回源47%；一次普通秒杀活动命中率：本地缓存 58%；分布式Redis 15%；回源27%；而某个服务使用一致哈希后命中率提升10%；对URL按照规则重写作为缓存KEY，去随机，即页面URL不管怎么变都不要让它成为缓存不命中的因素。

 

多级缓存

对于读服务，我们在设计时会使用多级缓存来尽量减少后端服务压力，在统一服务系统中，我们设计了四级缓存，如下所示：

 

 

1.1、首先在接入层，会使用Nginx本地缓存，这种前端缓存主要目的是抗热点；根据场景来设置缓存时间；

1.2、如果Nginx本地缓存不命中，接着会读取各个机房的分布式从Redis缓存集群，该缓存主要是保存大量离散数据，抗大规模离散请求，比如使用一致性哈希来构建Redis集群，即使其中的某台机器出问题，也不会出现雪崩的情况；

1.3、如果从Redis集群不命中，Nginx会回源到Tomcat；Tomcat首先读取本地堆缓存，这个主要用来支持在一个请求中多次读取一个数据或者该数据相关的数据；而其他情况命中率是非常低的，或者缓存一些规模比较小但用的非常频繁的数据，如分类，品牌数据；堆缓存时间我们设置为Redis缓存时间的一半；

1.4、如果Java堆缓存不命中，会读取主Redis集群，正常情况该缓存命中率非常低，不到5%；读取该缓存的目的是防止前端缓存失效之后的大量请求的涌入，导致我们后端服务压力太大而雪崩；我们默认开启了该缓存，虽然增加了几毫秒的响应时间，但是加厚了我们的防护盾，使服务更稳当可靠。此处可以做下改善，比如我们设置一个阀值，超过这个阀值我们才读取主Redis集群，比如Guava就有RateLimiter API来实现。

 

统一入口/服务闭环

在《构建需求响应式亿级商品详情页》中已经讲过了数据异构闭环的收益，在统一服务中我们也遵循这个设计原则，此处我们主要做了两件事情：

1、数据异构，如判断库存状态依赖的套装、配件关系我们进行了异构，未来可以对商家运费等数据进行异构，减少接口依赖；

2、服务闭环，所有单品页上用到的核心接口都接入统一服务；有些是查库/缓存然后做一些业务逻辑，有些是http接口调用然后进行简单的数据逻辑处理；还有一些就是做了下简单的代理，并监控接口服务质量。

 

引入Nginx接入层

我们在设计系统时需要把一些逻辑尽可能前置以此来减轻后端核心逻辑的压力，另外如服务升级/服务降级能非常方便的进行切换，在接入层我们做了如下事情：

• 数据校验/过滤逻辑前置、缓存前置、业务逻辑前置
• 降级开关前置
• AB测试
• 灰度发布/流量切换
• 监控服务质量
• 限流

 

数据校验/过滤逻辑前置

我们服务有两种类型的接口：一种是用户无关的接口，另一种则是用户相关的接口；因此我们使用了两种类型的域名c.3.cn/c0.3.cn/c1.3.cn和cd.jd.com；当我们请求cd.jd.com会带着用户cookie信息到服务端；在我们服务器上会进行请求头的处理，用户无关的所有数据通过参数传递，在接入层会丢弃所有的请求头(保留gzip相关的头)；而用户相关的会从cookie中解出用户信息然后通过参数传递到后端；也就是后端应用从来就不关心请求头及Cookie信息，所有信息通过参数传递。

请求进入接入层后，会对参数进行校验，如果参数校验不合法直接拒绝这次请求；我们对每个请求的参数进行了最严格的数据校验处理，保证数据的有效性。如下所示，我们对关键参数进行了过滤，如果这些参数不合法就直接拒绝请求。

 

另外我们还会对请求的参数进行过滤然后重新按照固定的模式重新拼装URL调度到后端应用，此时URL上的参数是固定的而且是有序的，可以按照URL进行缓存。

 

缓存前置

我们把很多缓存前置到了接入层，来进行热点数据的削峰，而且配合一致性哈希可能提升缓存的命中率。在缓存时我们按照业务来设置缓存池，减少相互之间的影响和提升并发。我们使用Lua读取共享字典来实现本地缓存。

 

业务逻辑前置

我们在接入层直接实现了一些业务逻辑，原因是当在高峰时出问题，可以在这一层做一些逻辑升级；我们后端是Java应用，当修复逻辑时需要上线，而一次上线可能花费数十秒时间启动应用，重启应用后Java应用JIT的问题会存在性能抖动的问题，可能因为重启造成服务一直启动不起来的问题；而在Nginx中做这件事情，改完代码推送到服务器，重启只需要秒级，而且不存在抖动的问题。这些逻辑都是在Lua中完成。

 

降级开关前置

我们降级开关分为这么几种：接入层开关和后端应用开关、总开关和原子开关；我们在接入层设置开关的目的是防止降级后流量还无谓的打到后端应用；总开关是对整个服务降级，比如库存服务默认有货；而原子开关时整个服务中的其中一个小服务降级，比如库存服务中需要调用商家运费服务，如果只是商家运费服务出问题了，此时可以只降级商家运费服务。另外我们还可以根据服务重要程度来使用超时自动降级机制。

我们使用init_by_lua_file初始化开关数据，共享字典存储开关数据，提供API进行开关切换（switch_get(“stock.api.not.call”) ~= “1”）。可以实现：秒级切换开关、增量式切换开关（可以按照机器组开启，而不是所有都开启）、功能切换开关、细粒度服务降级开关、非核心服务可以超时自动降级。

 

比如双十一期间我们有些服务出问题了，我们进行过大服务和小服务的降级操作，这些操作对用户来说都是无感知的。

 

AB测试

对于服务升级，最重要的就是能做AB测试，然后根据AB测试的结果来看是否切新服务；而有了接入层非常容易进行这种AB测试；不管是上线还是切换都非常容易。可以在Lua中根据请求的信息调用不同的服务或者upstream分组即可完成AB测试。

 

灰度发布/流量切换

对于一个灵活的系统来说，能随时进行灰度发布和流量切换是非常重要的一件事情，比如验证新服务器是否稳定，或者验证新的架构是否比老架构更优秀，有时候只有在线上跑着才能看出是否有问题；我们在接入层可以通过配置或者写Lua代码来完成这件事情，灵活性非常好。可以设置多个upstream分组，然后根据需要切换分组即可。

 

监控服务质量

对于一个系统最重要的是要有双眼睛能盯着系统来尽可能早的发现问题，我们在接入层会对请求进行代理，记录status、request_time、response_time来监控服务质量，比如根据调用量、状态码是否是200、响应时间来告警。

 

限流

我们系统中存在的主要限流逻辑是：对于大多数请求按照IP请求数限流，对于登陆用户按照用户限流；对于读取缓存的请求不进行限流，只对打到后端系统的请求进行限流。还可以限制用户访问频率，比如使用ngx_lua中的ngx.sleep对请求进行休眠处理，让刷接口的速度降下来；或者种植cookie token之类的，必须按照流程访问。当然还可以对爬虫/刷数据的请求返回假数据来减少影响。

 

前端业务逻辑后置

前端JS应该尽可能少的业务逻辑和一些切换逻辑，因为前端JS一般推送到CDN，假设逻辑出问题了，需要更新代码上线，推送到CDN然后失效各个边缘CDN节点；或者通过版本号机制在服务端模板中修改版本号上线，这两种方式都存在效率问题，假设处理一个紧急故障用这种方式处理完了可能故障也恢复了。因此我们的观点是前端JS只拿数据展示，所有或大部分逻辑交给后端去完成，即静态资源CSS/JS CDN，动态资源JSONP；前端JS瘦身，业务逻辑后置。

在双十一期间我们的某些服务出问题了，不能更新商品信息，此时秒杀商品需要打标处理，因此我们在服务端完成了这件事情，整个处理过程只需要几十秒就能搞定，避免了商品不能被秒杀的问题。而如果在JS中完成需要耗费非常长的时间，因为JS在客户端还有缓存时间，而且一般缓存时间非常长。

 

前端接口服务端聚合

商品详情页上依赖的服务众多，一个类似的服务需要请求多个不相关的服务接口，造成前端代码臃肿，判断逻辑众多；而我无法忍受这种现状，我想要的结果就是前端异步请求我的一个API，我把相关数据准备好发过去，前端直接拿到数据展示即可；所有或大部分逻辑在服务端完成而不是在客户端完成；因此我们在接入层使用Lua协程机制并发调用多个相关服务然后最后把这些服务进行了合并。

 

比如推荐服务：最佳组合、推荐配件、优惠套装；通过

http://c.3.cn/recommend?methods=accessories,suit,combination&sku=1159330&cat=6728,6740,12408&lid=1&lim=6进行请求获取聚合的数据，这样原来前端需要调用三次的接口只需要一次就能吐出所有数据。

我们对这种请求进行了API封装，如下所示：

 

比如库存服务，判断商品是否有货需要判断：1、主商品库存状态、2、主商品对应的套装子商品库存状态、主商品附件库存状态及套装子商品附件库存状态；套装商品是一个虚拟商品，是多个商品绑定在一起进行售卖的形式。如果这段逻辑放在前段完成，需要多次调用库存服务，然后进行组合判断，这样前端代码会非常复杂，凡是涉及到调用库存的服务都要进行这种判断；因此我们把这些逻辑封装到服务端完成；前端请求http://c0.3.cn/stock?skuId=1856581&venderId=0&cat=9987,653,655&area=1_72_2840_0&buyNum=1&extraParam={%22originid%22:%221%22}&ch=1&callback=getStockCallback，然后服务端计算整个库存状态，而前端不需要做任何调整。在服务端使用Lua协程并发的进行库存调用，如下图所示：

 

比如今日抄底服务，调用接口太多，如库存、价格、促销等都需要调用，因此我们也使用这种机制把这几个服务在接入层合并为一个大服务，对外暴露：http://c.3.cn/today?skuId=1264537&area=1_72_2840_0&promotionId=182369342&cat=737,752,760&callback=jQuery9364459&_=1444305642364。

 

我们目前合并的主要有：促销和广告词合并、配送至相关服务合并。而未来这些服务都会合并，会在前端进行一些特殊处理，比如设置超时，超时后自动调用原子接口；接口吐出的数据状态码不对，再请求一次原子接口获取相关数据。

 

服务隔离

服务隔离的目的是防止因为某些服务抖动而造成整个应用内的所有服务不可用，可以分为：应用内线程池隔离、部署/分组隔离、拆应用隔离。

应用内线程池隔离，我们采用了Servlet3异步化，并为不同的请求按照重要级别分配线程池，这些线程池是相互隔离的，我们也提供了监控接口以便发现问题及时进行动态调整，该实践可以参考《商品详情页系统的Servlet3异步化实践》。

部署/分组隔离，意思是为不同的消费方提供不同的分组，不同的分组之间不相互影响，以免因为大家使用同一个分组导致有些人乱用导致整个分组服务不可用。

拆应用隔离，如果一个服务调用量巨大，那我们便可以把这个服务单独拆出去，做成一个应用，减少因其他服务上线或者重启导致影响本应用。