转载

京东商详前台系统优化实践

写在前面

商品详情页又名单品页，是京东商城购物主流程之一。商品详情页作为用户了解商品信息的主要页面，有上百种业务场景，并且展示层面要求个性化场景较多，同时承载着京东购物主流程最大的访问量，再加上电商共同的特点，秒杀类场景居多，尤其以618和双11 更为突出。这样就对商详系统的性能提出了很高的要求，今年公司提出的降本提效的战略，以前一直扩机器的模式显然已经不可持续。在这个大背景下，我们开始对系统性能做针对性的提升优化，下面的介绍希望读者可以对商详有一个全面的了解。

商详系统技术架构介绍

0 1

商详整体架构图

商详系统做为承上启下的系统，承接着客户端商品页过来的所有流量，再调用中台各个业务系统获取信息。
业务角度商详业务主要分为以下场景：优惠券场景，用户信息场景，价格信息场景，促销场景，商品与扩展信息场景，库存与履约场景。
结构上来讲整个商详业务分为客户端，前台，中台，后台。这里主要介绍的系统为商详前台系统。

京东商详前台系统优化实践

0 2

系统组件图

目前商详系统由于历史原因分为purewaresoa,warecoresoa 两个系统。首先看一下目前的两个系统的调用流程：

京东商详前台系统优化实践

purewaresoa 是商详老系统，整体提供http服务，流程为流量从app客户端过来，然后过nginx ,如果是静态资源的话会走cdn缓存，然后到tomcat, 系统内部为sirector（公司自研的并发流程编排框架）流程编排，然后到jsf 客户端调用jsf 服务获取业务信息。
warecoresoa 系统为商详新系统，提供jsf 服务给容器（提供楼层样式配置化支持的系统）调用最终组合成楼层信息给客户端用，所以流量会先过容器再到warecoresoa ,系统内部通过sirector 流程编排调用jsf 服务获取业务信息。

0 3

系统分析

因为随着系统的发展warecore 所占的比重会越来越大，所以以下分析主要针对warecoresoa 系统。

系统内存分析

京东商详前台系统优化实践

java内存分析一般采用Java jmap dump下系统内存文件使用mat 进行分析,上图是一台机器内存报警时dump下来的内存文件。经过分析发现系统内存占用主要集中在两块，1. zk 本地缓存 2.ump 统计。

系统线程分析

线程栈一般通过jstack 得到，或者使用京东工具jvm.jd.com 连接上对应机器导出java进程所有的线程，以下为warecore整理过后的所有线程（线程数量非最终线程数量）

{

"taskProcessorThreadPool": 10, //队列线程

"nioEventLoopGroup": 10, //netty 对应线程

"userTracerWorker": 100, //ump 线程

"Jst": 7,

"BrokenConnectionDestroyer": 2,

"SystemClock": 1,

"pool": 331,{

"pool-10":200, //sirector 线程

"pool-4":128, //jimdb 连接线程池

"pool-3":1,

"pool-2":1,

"pool-1":1

}

"JSF": 699,

{

"JSF-CLI-WORKER": 9,

"JSF-SEV-BOSS": 1,

"JSF-CLI-RC": 156, //客户端线程

"JSF-SEV-WORKER": 2, //jsf io线程池

"JSF-Future-Checker": 2,

"JSF-jsfRegistry-HB&Retry": 1,

"JSF-BZ-22000": 215, //业务线程池

"JSF-CLI-CANDIDATE": 156, //客户端线程

"JSF-CLI-HB": 155, //客户端线程

"JSF-FileRegistry-Back": 1,

"JSF-jsfRegistry-Check": 1

}

"UpdateProfile": 1,

"ContainerBackgroundProcessor[StandardEngine[Catalina]]": 1,

"CfsHeartbeat": 6, //jimdb 心跳线程

"main": 1,

"commons": 1,

"CLIENT_SIDE_RINGBUFFER": 1,

"Reference Handler": 1,

"Finalizer": 1,

"localhost": 6, //tomcat　线程

"ZkClient": 3,

"I/O dispatcher 2": 1,

"PathCache": 1,

"IoLoopGroup ": 4,

"I/O dispatcher 3": 1,

"I/O dispatcher 4": 1,

"I/O dispatcher 5": 1,

"I/O dispatcher 6": 1,

"I/O dispatcher 7": 1,

"I/O dispatcher 8": 1,

"GC Daemon": 1,

"RMI TCP Connection(2)": 1,

"Signal Dispatcher": 1,

"FailoverEvent": 8,

"RMI Scheduler(0)": 1,

"Thread": 1,

"System_Clock": 1,

"NioBlockingSelector.BlockPoller": 1,

"http": 3,

"UMP": 11,

"JMX server connection timeout 36": 1,

"ClearTimeout": 1,

"ClusterManager": 1,

"UpdateCluster": 1,

"ChannelEvent": 8,

"I/O dispatcher 1": 1,

"RMI TCP Accept": 3

}

通过以上分析能得出结论，jsf 线程池，sirector线程池，jimdb线程池，ump线程池等线程池所占比例最大，所以后续调整也主要针对这几个线程池大小进行调整。

系统cpu分析

随着计算机的发展，cpu 逐渐成了系统性能的主要瓶颈，所以也诞生了各种各样的针对cpu 的分析工具，这里主要用了火焰图和arthas 来进行分析

火焰图

京东商详前台系统优化实践

arthas -- 按cpu 统计

京东商详前台系统优化实践

图一火焰图能看到系统内部各个环节的cpu 占比，图二是按cpu 耗损占比排名线程。

性能优化

商详系统优化历程：

以下3个阶段划分属于时间点划分

0 1

阶段1

并行化
动静分离
cdn加速
lua静态化
垃圾收集器

Tomcat nio

0 2

阶段2

jdk8 tomcat8
线程池调优
堆内存调优
本地缓存命中率
热点方法缓存覆盖率

分布式缓存命中率

0 3

阶段3

异步化(io异步，日志异步，懒加载)
业务重构(重构,上移下沉,降级)

阶段1 展示了商详老系统的优化历程，首先当然就是并行化的改造，商详系统后端对应着一百多个业务，挨个串行调用的话，几乎无法完成给用户的响应。这样就需要进行并行化改造，并行改造使用了公司的并发编排框架 sirector , 再后来随着流量的增加，为了减少不必要的网络流量，进行了动静态分离改造，就是现在用的动态接口和静态接口。静态接口除了本地缓存，jimdb外为了减少网络传输将部分缓存提前到了cdn处，之后又加了lua 缓存，此次jdk方面的调整主要集中在垃圾回收器的选择以及一些jvm的调优上，tomcat 则是主要调整了io异步化

阶段2首先调整的是jdk. 由于历史原因 jdk一直用的jdk6,jdk8在性能方面做了很多优化，第一步先是进行了jdk8,tomcat8的升级，调完之后qps有了较明显的提升，之后通过对系统线程分析发现线程存在一些问题，对线程池进行了调整，之后压测过程中发现ygc较多为了减少ygc 次数，对堆内存进行了调整，也为之后本地缓存命中率的调整打下了基础，之后又针对热点方法和分布式缓存命中率做了相应的优化调整。

阶段3是一个长期的过程，涉及到代码层面的改造，所以需要慎之又慎。目前我们只做了一些，包括一些正在做的有推荐，排行榜异步化改造，价格促销合并，主图中台缓存共享等，还有一些下线业务梳理清理，缓存梳理下线等。

工具

工欲善其事，必先利其器

性能调优主要是工具的使用

公司内部

首先当然是公司内部工具的使用，如下：

forcebot
mdc

ump
visual

开源工具集

Linux 系统工具

京东商详前台系统优化实践

以上是linux 调优大神整理的工具集

当然还会用到一些jdk 自带的命令，如 jps jstat,jmap,jstack. 等等。

0 4

示例

线程池相关

京东商详前台系统优化实践

sirector线程池调整的时候发现一个现象cpu 在刚开始压测的时候第一行会有一个cpu 一直涨，查看jstack 发现sirector 线程数一直在涨，查看了配置发现线程池核心线程数不等于最大线程数，当线程不够用的时候，系统会开始创建线程，创建线程是个极为消耗性能的操作，所以这里会显示cpu 持续升高，调整线程池为固定线程数之后再没出现这种情况。

火焰图相关

京东商详前台系统优化实践