京东商品详情页服务闭环实践

标签: 京东 商品 服务 | 发表时间:2015-11-20 06:54 | 作者:
出处:http://jinnianshilongnian.iteye.com

该文章是根据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异步化实践》。

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

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

 

相关文章 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [京东 商品 服务] 推荐:

京东商品详情页服务闭环实践

- - 开涛的博客(欢迎关注我的公众号[博客头像二维码])
该文章是根据OpenResty Con 2015技术大会的演讲《 Nginx+Lua在京东商品详情页的大规模应用》细化而来,希望对大家有用. 京东商品详情页技术方案在之前《 构建需求响应式亿级商品详情页》这篇文章已经为大家揭秘了,接下来为大家揭秘下双十一抗下几十亿流量的商品详情页统一服务架构,这次双十一整个商品详情页没有出现不服务的情况,服务非常稳定.

京东商品详情页碎碎念

- - ITeye博客
在之前的两篇文章《 构建需求响应式亿级商品详情页》和《 京东商品详情页服务闭环实践》已经详细介绍了整个系统的架构设计和实现思路. 本篇将介绍下杂七杂八的一些实践:. 对于突发流量,我这边系统的一般解决方案:高效缓存、自动降级、减少回源量;高效缓存可以参考《 构建需求响应式亿级商品详情页》和《 京东商品详情页服务闭环实践》中的缓存实践;而自动降级也在这两篇文章中讲到了,不再重复.

使用python抓取并分析京东商品评论数据

- - 蓝鲸的网站分析笔记
本篇文章是python爬虫系列的第三篇,介绍如何抓取京东商城商品评论信息,并对这些评论信息进行分析和可视化. 下面是要抓取的商品信息,一款女士文胸. 这个商品共有红色,黑色和肤色三种颜色, 70B到90D共18个尺寸,以及超过700条的购买评论. 京东商品评论信息是由JS动态加载的,所以直接抓取商品详情页的URL并不能获得商品评论的信息.

京东亿级商品搜索核心技术解密

- - 运维派
作者:王春明,现任京东搜索平台部负责人,2011年加入京东搜索团队,期间一直负责京东搜索引擎研发工作,主导了多次搜索架构升级工作保障其满足京东发展需求,擅长搜索引擎、高性能服务开发、分布式系统架构. 招聘: 京东搜索平台部木有有高级/资深搜索引擎研发工程师(C/C++)  、高级/资深算法工程师(C/C++)、高级/资深数据系统工程师(java)等职位,期待您的加入,一起打造弹性搜索平台.

京东抢购服务高并发实践

- - 企业架构 - ITeye博客
限时抢购又称闪购,英文Flash sale,起源于法国网站Vente Privée. 闪购模式即是以互联网为媒介的B2C电子零售交易活动,以限时特卖的形式,定期定时推出国际知名品牌的商品,一般以原价1-5折的价格供专属会员限时抢购,每次特卖时间持续5-10天不等,先到先买,限时限量,售完即止. 顾客在指定时间内(一般为20分钟)必须付款,否则商品会重新放到待销售商品的行列里.

京东推云存储服务:仅向电子书和金牌用户开放

- - TechWeb 今日焦点 RSS阅读
这一服务目前仅面向京东商城电子书用户和金牌以上用户. 在JBOX中购买电子书、上传音乐和文档等资料.   新浪科技讯 8月6日下午消息,京东商城于7月中旬悄然上线了云存储服务“JBOX”. 这一服务目前仅面向京东商城电子书用户和金牌以上用户. 每个用户拥有5G大小的在线存储空间,能够在其中购买电子书、上传音乐和文档等资料.

来自京东、宅急送对微服务编排、API网关、持续集成的实践分享(下)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

来自京东、唯品会对微服务编排、API网关、持续集成的实践分享(上)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

淘宝客禁止提供商品搜索服务便宜了谁

- - 派代网 - 资讯
最近淘宝客圈里都在讨论6.1号淘宝客规则的更改问题,对于6月1号淘宝客禁止提供商品搜索服务争论不休,但是不管怎么样,应该有人欢喜有人愁. 或许大家都在想,如果禁止提供商品搜索服务,那么返利网是否还能继续做呢,原来的返利网又该何去何从呢?这里嗨推淘宝客社区坏坏和大家一起讨论下,淘宝客禁止提供商品搜索服务到底便宜了谁?.

顺丰将推海淘转寄服务 商品美国转寄中国最多10天

- - 互联网的那点事
顺丰速运宣布,其去年推出的专业海淘转寄服务平台SFBuy(中文名海购丰运)将于近日对外开放注册,这意味着顺丰内测的海淘转运服务将正式对外开放. 顺丰方面表示,海淘商品从美国转寄至中国内地只须7-10个工作日,运费低至二五折,还可享受30天的免费仓储服务. 顺丰海淘转寄服务SFBuy将开放 商品美国转寄中国最多10天.