京东技术架构 - 构建亿级前端读服务

http://jinnianshilongnian.iteye.com/blog/2232271

一些设计原则

• 无状态
• 数据闭环
• 缓存银弹
• 并发化
• 降级开关
• 限流
• 切流量
• 其他

无状态

如果设计的应用是无状态的，那么应用就可以水平扩展，当然实际生产环境可能是这样子的： 应用无状态，配置文件有状态。比如不同的机房需要读取不同的数据源，此时就需要通过配置文件指定。

数据闭环

如果依赖的数据来源特别多，此时就可以考虑使用数据闭环，基本步骤：

1、数据异构：通过如MQ机制接收数据变更，然后原子化存储到合适的存储引擎，如redis或持久化KV存储；

2、数据聚合：这步是可选的，数据异构的目的是把数据从多个数据源拿过来，数据聚合目的是把这些数据做个聚合，这样前端就可以一个调用拿到所有数据，此步骤一般存储到KV存储中；

3、前端展示：前端通过一次或少量几次调用拿到所需要的数据。

这种方式的好处就是数据的闭环，任何依赖系统出问题了，还是能正常工作，只是更新会有积压，但是不影响前端展示。

另外此处如果一次需要多个数据，可以考虑使用Hash Tag机制将相关的数据聚合到一个实例，如在展示商品详情页时需要：商品基本信息：p:123:， 商品规格参数：d:123:，此时就可以使用冒号中间的123作为数据分片key，这样相同id的商品相关数据就在一个实例。

缓存银弹

缓存对于读服务来说可谓抗流量的银弹。

浏览器端缓存

设置请求的过期时间，如响应头Expires、Cache-control进行控制。这种机制适用于如对实时性不太敏感的数据，如商品详情页框架、商家评分、评价、广告词等；但对于如价格、库存等实时要求比较高的，就不能做浏览器端缓存。

CDN缓存

有些页面/活动页/图片等服务可以考虑将页面/活动页/图片推送到离用户最近的CDN节点让用户能在离他最近的节点找到想要的数据。一般有两种机制：推送机制（当内容变更后主动推送到CDN边缘节点），拉取机制（先访问边缘节点，当没有内容时回源到源服务器拿到内容并存储到节点上），两种方式各有利弊。 使用CDN时要考虑URL的设计，比如URL中不能有随机数，否则每次都穿透CDN，回源到源服务器，相当于CDN没有任何效果。对于爬虫可以返回过期数据而选择不回源。

接入层缓存

对于没有CDN缓存的应用来说，可以考虑使用如Nginx搭建一层接入层，该接入层可以考虑如下机制实现：

1、URL重写：将URL按照指定的顺序或者格式重写，去除随机数；

2、一致性哈希：按照指定的参数（如分类/商品编号）做一致性Hash，从而保证相同数据落到一台服务器上；

3、proxy_cache：使用内存级/SSD级代理缓存来缓存内容；

4、proxy_cache_lock：使用lock机制，将多个回源合并为一个，减少回源量，并设置相应的lock超时时间；

5、shared_dict：此处如果架构使用了nginx+lua实现，可以考虑使用lua shared_dict进行cache，最大的好处就是reload缓存不丢失。

此处要注意，对于托底/异常数据不应该让其缓存，否则用户会在很长一段时间看到这些数据。 

应用层缓存

如我们使用Tomcat时可以使用堆内缓存/堆外缓存，堆内缓存的最大问题就是重启时内存中的缓存丢失，如果此时流量风暴来临可能冲垮应用；还可以考虑使用local redis cache来代替堆外内存；或者在接入层使用shared_dict来将缓存前置，减少风暴。

分布式缓存

一种机制就是废弃分布式缓存，改成应用local redis cache，即在应用所在服务器中部署一个redis，然后使用主从机制同步数据。如果数据量不大这种架构是最优的；如果数据量太大，单服务器存储不了，还可以考虑分片机制将流量分散到多台；或者直接就是分布式缓存实现。常见的分片规则就是一致性哈希了。

如上图就是我们一个应用的架构： 

1、首先接入层读取本地proxy cache / local cache；

2、如果不命中，会读取分布式redis集群；

3、如果还不命中，会回源到tomcat，然后读取堆内cache；如果没有，则直接调用依赖业务获取数据；然后异步化写到redis集群；

因为我们使用了nginx+lua，第二、三步可以使用lua-resty-lock非阻塞锁减少峰值时的回源量；如果你的服务是用户维度的，这种非阻塞锁不会有什么大作用。

并发化

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

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。

降级开关

对于一个读服务，很重要的一个设计就是降级开关，在设计降级开关时主要如下思路：

1、开关集中化管理：通过推送机制把开关推送到各个应用；

2、可降级的多级读服务：比如只读本地缓存、只读分布式缓存、或者只读一个默认的降级数据；

3、开关前置化：如架构是nginx--->tomcat，可以将开关前置到nginx接入层，在nginx层做开关，请求不打到后端应用。

限流

目的是防止恶意流量，恶意攻击，可以考虑如下思路：

1、恶意流量只访问cache；

2、对于穿透到后端应用的可以考虑使用nginx的limit模块处理；

3、对于恶意ip可以使用如nginx deny进行屏蔽。

大部分时候是不进行接入层限流的，而是限制流量穿透到后端薄弱的应用层。

切流量

对于一个大型应用，切流量是非常重要的，比如多机房有机房挂了、或者有机架挂了、或者有服务器挂了等都需要切流量，可以使用如下手段进行切换：

1、DNS：切换机房入口；

2、LVS/HaProxy：切换故障的nginx接入层；

3、Nginx：切换故障的应用层；

另外我们有些应用为了更方便切换，还可以在nginx接入层做切换，通过nginx进行一些流量切换，而没有通过如LVS/HaProxy做切换。 

其他

不需要cookie的应用使用无状态域名，如3.cn；

接入层请求头过滤，只转发有用的请求头到后端应用；

数据过滤逻辑前置，比如在接入层进行请求参数的合法性过滤；

内网设置合理的连接、读、写超时时间；

根据需要开启gzip压缩减少流量；

使用unix domain socket减少本机连接数；

内网考虑使用http长连接；

响应请求时，考虑响应头加上服务器ip等信息，方便调试。

我们处理的读服务大部分都是KV的，因此抗流量的思路就是大量缓存；而且怎么让缓存怎么更接近用户，离用户越近速度就越快。再一个点就是要考虑好降级方案，在异常情况下应用不被拖垮拖死。

我们系统大量使用了如nginx+lua+redis技术，使用这些技术解决了我们很多读服务问题。

http://jinnianshilongnian.iteye.com/blog/2235572

架构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技术获取数据并渲染模板输出。

详情页架构设计原则

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、商品维度其他信息（异步加载），价格、促销、配送至、广告词、推荐配件、最佳组合等。 

拆分系统

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