京东活动系统亿级流量应对之术
|
副标题[/!--empirenews.page--]
《京东活动系统亿级流量应对之术》要点： 作者：干天星,2012年初加入京东,先后在京东审计、搭配购、jshop活动系统等项目从事系统研发和架构工作.目前主要负责jshop活动系统架构升级,以及jshop数据中心实现运算架构设计.对构建高并发web架构,以及高性能实时大数据运算,有一定的见解.入职前有过5年电信传统行业开发、架构经验. 背景京东活动系统是一个可在线编辑、实时编辑更新和发布新活动,并对外提供页面访问服务的系统,地址如http://sale.jd.com/***.html.其高时效性、灵活性等特征,极受青睐,已发展成京东几个重要流量入口之一.近几次大促,系统所承载的PV均为数亿以上.随着京东业务的高速发展,京东活动系统的压力会越来越大.急需要一个更高效,稳定的系统架构,来支持业务的高速发展.本文主要对活动页面浏览方面的性能,进行探讨. 活动页面浏览性能提升的难点： 活动与活动之间差异很大,不像商品页有固定的模式.每个页面能抽取的公共部分有限,可复用性差； 活动页面内容多样,业务繁多.依赖大量外部业务接口,数据很难做到闭环.外部接口的性能,以及稳定性,严重制约了活动页的渲染速度、稳定性； 经过多年在该系统下的开发实践,提出“页面渲染与页面浏览异步化”的思想,页面渲染是把渲染好的整页数据放到redis或者硬盘里了,页面浏览是从redis或者硬盘里取静态的页面,并以此为指导,对该系统进行架构升级改造.通过近几个月的运行,各方面性能都有显著提升.在分享”新架构”之前,先看看我们现有web系统的架构现状. web架构发展与现状*浏览服务 以京东活动系统架构的演变为例,这里没有画出具体的业务逻辑,只是简单的描述下架构. 我们会在消耗性能的地方加缓存,这里对部分查库操作加redis缓存. 并且对页面进行整页redis缓存：由于活动页面内容繁多,渲染一次页面的成本是很高.这里可以考虑把渲染好的活动内容整页缓存起来,下次请求到来时,如果缓存中有值,直接获取缓存返回. 以上是系统应用服务层面架构演进的,简单示意.为了减少应用服务器的压力,可以在应用服务器前面,加cdn和nginx的proxy_cache,减少回源率. 整体架构(老) 除了“浏览服务”外,老架构还做了其他两个大的优化：“接口服务”、“静态服务”
接口服务分两类,直接读redis缓存和调用外部接口.这里可以对直接读redis的接口采用nginx+lua(openresty)进行优化,不做详细讲解.本次分享主要对“浏览服务”架构. 新老架构性能对比在讲新架构之前先看看新老架构下的新能对比. *老架构浏览服务性能 击穿cdn缓存、nginx缓存,回源到应用服务器的流量大约为20%-40%之间,这里的性能对比,只针对回源到应用服务器的部分. 浏览方法TP99如下(物理机) TP99? 1000ms左右,且抖动幅度很大,内存使用近70%,cpu 45%左右.1000ms内没有缓存,有阻塞甚至挂掉的风险. * 新架构浏览服务性能 本次2016 618采用新架构支持,浏览TP99如下(分app端活动和pc端活动)
移动活动浏览TP99稳定在8ms,PC活动浏览TP99 稳定在15ms左右.全天几乎一条直线,没有性能抖动. 新架构支持,服务器(docker)cpu性能如下 cpu消耗一直平稳在1%,几乎没有抖动. 对比结果：新架构TP99从1000ms降低到15ms,cpu消耗从45%降低到1%,新架构性能得到质的提升. why!!!下面我们就来揭开新架构的面纱. 新架构探索*页面渲染与页面浏览异步化 再来看之前的浏览服务架构,20%-40%的页面请求会重新渲染页面,渲染需要重新计算、查询、创建对象等导致cpu、内存消耗增加,TP99性能下降. 如果能保证每次请求都能获取到redis整页缓存,这些性能问题就都不存在了.即：页面渲染与页面浏览异步. *直接改造后的问题以及解决方案 理想情况下,如果页面数据变动可以通过手动触发渲染(页面发布新内容)、外部数据变化通过监听mq自动触发渲染. 但是有些外部接口不支持mq、或者无法使用mq,比如活动页面置入的某个商品,这个商品名称变化. （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
