电商的11.11大促,既是一场全民运动,也是顶级团队和技术的对决。

王晓钟,京东商城技术研发体系交易平台副总监,11.11大促,他介绍说基本的原则是保证主要的交易系统没有任何故障,这是多部门合作的结果。运维部门从网络层开始就准备了很多预案和容量规划,负责处理外部的流量,特别是恶意流量的甄别和处理。

 

交易系统瓶颈

谈到交易系统的瓶颈,他认为,随着系统数据和状态的变化,它不是一个固定的点。

以线上交易为例,依赖的逻辑分支特别多,包括用户信息、商品信息、价格计算、库存信息、虚拟资产使用情况等等,这些信息都来源于不同的服务,所以整个交易系统的逻辑特别复杂。

在前期准备中,京东内部进行了大量的压力测试,尝试找出可能的瓶颈点;在实际运行过程中,工程师密切监控,每个热点都有预案。处理的思路要么是提前准备很多组机器,分担流量,要么是临时开启一些细微的降级,增加一些缓存

 

监控系统

京东的实时监控系统基本上都是通过日志分析来完成,包括软硬件多个维度,硬件包括CPU使用率、网络连接数等等;软件包括某个接口的响应时间、异常抛出的次数等等,当然监控系统也要做11.11备战,比如对于重要系统的数据隔离等等。

关于响应时间,目前瓶颈都在公网上,国内的互联网质量比较差。从服务器这边讲,每一百次调用中,最差的一次也只有15毫秒,但是到了公网上,根据测试,好的也是100多毫秒,差的甚至到1秒左右。

监控系统是京东自己开发的,所有的第三方的东西,它都造一个通用的轮子,京东以前还是一辆大卡车,用通用的轮子就可以了。目前这个业务量可以说已经是一辆跑车了,对轮胎的要求特别高,所以轮子都自己定制的,适合自己的业务、系统、软件、硬件,包括适合自己的人和管理。

 

云平台与容量规划

京东的底层系统其实分为两块,一块是内部的虚拟云,有不少系统是在用虚拟云系统;还有一部分,比如说交易,像这种交易也有一部分在用虚拟云,有一部分在用硬件,都是不一样的,看业务是否适合。因为云不适合所有的业务场景。比如说有状态的应用,对数据一致性要求高的,它就不太适合。有些像购物车的价格计算,完全没有状态,就适合。

云平台,第一,部署和管理上和以前相比要方便很多;第二,在故障处理上,有很多底层的可以自动切换的功能,合理的调配资源。

容量规划,主要依靠各个团队对于自己的未来业务的预测,京东的团队主要依靠自己的大数据系统。从大数据团队里获取业务增长数据的趋势。大家对这些趋势进行分析,可以合理的判断自己用户的增长量大致是多少。比如对用户团队来说,关注的是用户的登陆量和注册量,对交易团队来说,关心的是订单的增长量。商品团队关心的每天商品的更新量,还有商品的增长量,每个团队不一样。他们根据自己量的趋势来做自己的容量规划。

 

数据一致性

交易系统数据一致性,交易依赖的用户、商品、促销、库存这些接口,首先没办法做异步,只有同步的来做,而且如果做同步的话,分布式事务是很难绕过去的话题,对电商来说,简直是一个技术上的恶梦。

目前京东的做法很简单,提交的时候就做强一致性检查。提交完了,在强一致性检查的基础上,再做异步的一致性检查。某一单如果没有提交成功,那没有一致性问题。只要这一单成功了,系统肯定会保证数据一致性。

举个具体例子,交易一旦成功,用户余额如果扣了,那肯定就是扣了。不会存在交易成功,但余额实际上没扣的情况。还有优惠券也是一样的,必须是强一致性的。

 

线上测试

做线上的性能测试怎么不影响其他用户?举个例子,假设线上是两组系统,如果要做线上的性能压测,会把用户导到其中的一组上去,物理上和做压测的那一组隔绝。

因为对交易来说,现在交易已经做到分布式交易,各个组之间,包括数据都做了隔绝。如果一组压力过大出现问题,哪怕整组宕机的情况下,其他几组机群还是好的,快速的把入口流量一切换,保证用户体验。这一招就可以用在线上性能测试中。每次线上性能压测的时候,把用户导到一组隔绝的机器上,用户在上面跑。然后剩下的那几组就用各种工具进行压测,跑出的数据特别真实。

 

秒杀隔离

秒杀系统是今年从主交易系统中剥离出来,服务器和数据系统都是独立部署的,秒杀用的库存和商品信息都是单独推送到秒杀系统里,完全隔离。系统本身又做了很多针对秒杀的优化。

 

 

原文InfoQ