京东商城交易系统的演进 _京东

商城服务

文章插图

如图所示是京东交易平台的一张大的渔网图。从主页面网站开始，到后面提交订单、购物车、结算页、订单中心等的整个生产过程，大体可分为三个部分。第一部分是订单提交前，就是俗称的购物车，结算页。第二部分是订单预处理部分，生成订单之后、到物流之前，还会有一些预处理过程，比如生鲜、大家电、奢侈品、易碎品等商品。第三部分是订单履约部分。今天我讲的主要内容是，交易平台的提交以前和预处理部分。

文章插图

京东交易平台，包括单品页的价格、库存，购物车、促销，结算页的下单，再到订单中心线。

文章插图

如下图所示，2011年京东的订单量是30万，2015年订单量就已经到了3000多万，京东的流量每年不断地翻倍。订单从30万到100万是三倍增长，实际上访问流量的翻番，可能是10倍、50倍，甚至上百倍。比如，用户购买东西从单品页进入，然后查询很多信息，包括价格、评价。商品加入购物车后，用户会不停地比对各类商品。刷新购物车，从前端到后端所有的服务基本上都会刷新。那么，当你刷新一次，调动服务就会承受一次动态的调用。当订单量翻三倍的时候，实际服务访问量最少是要翻20倍。

文章插图

【京东商城交易系统的演进】我见过的京东目前最大的前端流量是，一分钟几千万，一个正常前端服务访问量是在几千万，几亿、几十亿，一天的PV 。
那为了应对如此大的调动量，每年的618、双11，京东都做了什么？
下面我会详细讲618、双11备战后面，每一年所做的不同改变。这是一个整体的大概分析，我们从哪些方面做优化，去提高系统的容灾性，提高系统应对峰值流量的能力。

文章插图

实际上每年京东内部的正常情况是，领导层会给出一个大概的预期值，就是希望当年的大促中，需要达到几百亿，或者几十亿的预期销售额。那么，根据这个销售额，根据客单价（电商的订单的平均价格，称为客单价）换算成订单量。另外在以往的618、双11中，我们都会统计出订单量和调用量，即前端价格需要访问多少次，购物车需要访问多少次，促销引擎需要访问多少次，整个流程需要多大的量。有了大概的方向之后，就会把具体系统的量换算出来。第一轮会做压测，压测分为线上压测和线下压测两部分。这些都是准备工作，根据一些指标往年的增长量估算出一个预期值。
压测

文章插图

这是真正进入第一波。首先，每年的大促前，都会经历半年业务迭代期，整个系统会有很多变更。我们会进行第一轮的压测系统，压测之后会知道当前线上真正能够承载的访问量有多大，距离预期有多远。压测分为线上压测跟线下压测。压测场景分为读业务和写业务，压测方案有集群缩减服务、模拟流量、流量泄洪。
讲到压测，先说说压测的来历吧。2011年时候没有线上压测，线下压测也不是很全。真正引入线上压测是在2014年，订单量已经接近2000万。之前的大促备战，是通过组织架构师、优秀的管理人员，优秀的技术人员，一起去评估优化系统，因为在迭代代码的同时，我们会知道系统哪里容易出现问题，然后对数据库、Web或者业务服务做一堆优化。
在2014年，订单量到了上千万，换算成为访问量，每天的PV大涨，集群也更大偏大，如果还是只依靠技术人员去优化，可能会不足。于是就衍生出压测，我们想知道系统的极限值。这样，当系统承受不住访问请求的时候，我们就会知道哪里出现瓶颈，比如，服务器的CPU、内存、连接速度等。我们通过第一轮压测找到第一波的优化点，开始了线上的压测。
当时第一波做线上压测是在凌晨一两点，把整个线上的流量剥离小部分机器上。把集群剥离出来，然后再做压测。所有的服务器、所有的配置就是用线上完全真实的场景去做压测，就能够得到线上服务器在真实情况，再优化。
曾经做redis压测，把进程绑定到单核CPU，redis是单进程程序，当时集群的性能就提升了5% 。因为机器的每次CPU切换，都需要损耗资源，当时把进程直接绑定到固定的CPU上，让它高压下不频繁地切换CPU进程。就这样一个改变，性能提升了5% 。当量很大的时候，真正底层细节的小改变，整个性能就会有很大的改进。这是我们从2014年引进线上压测和线下压测之后的一个真实感受。