《京东大促备战思路2.0大揭秘》要点：
本文介绍了京东大促备战思路2.0大揭秘，希望对您有用。如果有疑问，可以联系我们。

文经授权转自公众号：开涛的博客(kaitao-1234567)

作者简介：

林世洪

毕业于北京交通大学,2011年加入京东,先后负责京东订单履约体系和零售平台架构工作,连续两届架构委员会成员,此期间主导和参与了京东研发若干规范的制定.

着力推动电商核心系统架构升级,总结形成了大型促销备战方法论,保障了电商主流程系统的稳定性,降低了整体系统建设成本.个人技术方面更多关注根据业务特点和技术要求对系统进行可运营化改造和治理.

前言

提到备战,实际上不一定要到大型促销时,工作应该做到平时.京东已发展到了一个比较大的体量,无论是大促还是平时,都容不得出现大问题,我们的思路和方法是：积极预防、及时发现、快速处理,这正是本文前半部分要介绍的.但要做到这十二个字并不容易,本文后半部分会介绍背后的两个要素：日渐成熟稳定的团队、日趋完善的流程和规范.

下图是对本文内容的描绘：

1. 积极防预问题

在预防措施上,需要遵循 PDCA 方法：

P阶段：

1. 分析系统职责,确立系统备战的首要业务目标；

2. 依据业务量评估,对系统处理能力要求进行评估,根据评估结果和系统运行状况,找出系统瓶颈.*特别地,如果是大促备战,则要先给大促时的业务量评估.

D阶段：

3. 针对系统瓶颈,进行系统改造；

4. 梳理系统间的依赖关系,各系统之间达成 SLA,以保证整体性能指标.

C阶段：

5. 对系统进行压力测试,验证处理能力,确保达标.特别地,则可以考虑在线上进行跨系统军演；

6. 特别地,如果是大促前夕,则要对系统进行全面体检.

A阶段：

7. 如果系统改造达不到评估要求,则需要修正方案.

1.1. 确定每个系统的首要备战目标

每个系统都会有自己的边界,各系统负责人应该分析清楚系统的使命和职责是什么,分清主次,这同时也是制定应急预案的最重要依据,举例：

1. 订单交易系统,其最重要的是保证下单,这是刚性的要求,其它的都是有弹性的,例如很多不影响下单的检验逻辑,都可以放到下单之后来补偿；
2. OFC,其最重要的是保证订单生产部门有订单可生产,尽量不影响其产能,在这个前提下,可以采取各种灵活措施.例如,假设某个库房的最高生产能力为10万单,而当时产生的订单有20万,这时系统保障把10万订单送给这个库房生产就能满足生产要求了,此时可以把系统处理能力分配给 POP 订单处理；
3. 物流生产系统,其最重要的是满足工人的作业需求,保证生产效率,其它的逻辑,如生产数据跟踪数据处理,可以异步处理.

1.2. 系统性能评估

总体思路：先进行需求评估,然后进行系统评估,找出差距.

1.2.1. 性能需求评估

总体思路：

公司层面首先要给出一个业务量的初估,然后各个团队可以根据此值来把总的业务量评估分解到自己的系统的吞吐量指标上,接下来就是方案设计的问题了,目标就是将吞吐量指标提高到评估的水平,同时其它性能指标仍能满足业务要求.这样兼顾了性能和成本.

吞吐能力评估：

吞吐能力,指的是单位时间内处理请求的数量限制,一般用tps来衡量,指的是每秒处理请求的数量.

前面提到过要把总的业务量评估分解到自己的系统的吞吐量指标,可以把系统看成一个黑桶,看这个桶上边界输入的量和下面输出的量.

假设一个系统是客户订单处理系统,每一个订单向它输入2条处理请求,并向外界输出4条信息,如果一天的订单量是1000万,则这个系统要每天接收2000万个请求,输出4000万条信息.

对于直接面对客户的系统,输入的评估需要更多的维度(如促销、推广),但也有简单的评估办法,那把上一次大促作为参照,按业务量同比扩大.

当然,实际评估时,不能只看一天的业务量,还要看峰值,而且要高度重视峰值.前端系统的峰值评估需要考虑比较多的维度(如促销方式和力度等),后端相对简单,用于平均值乘以一个系数即可,这个系统可以根据系统以住大促时统计而来,如果是一个新系统,可以让上游系统协助评估.

并不是所有系统都要承担高峰值.如果一个业务处理流程比较长,则上游的系统可以平滑峰值,让下游系统享受一个平滑得多的请求流,这样可以大大减少系统的建设成本.

例如,在订单处理流程中,OFC 扮演了这一个稳压器的作用,OFC 把上游订单和峰值进行了平滑.所以吞吐能力的评估也需要团队合作.

• 容量规划：

吞吐量的提升,往往伴随着容量提升,需要做好容量规划,主要考虑的因素有：

1. 主业务对象的量(如订单)以及到大促前的增长量
2. 每个主业务对象会占用多少容量
3. ?数据要在线上主系统中存留的时间
4. 出现高峰时,允许积压的数据量和积压时间

有了上面这几个数据,就比较好评估了.特别是针对4进行说明,有一些过程数据,处理完就不必要在主系统中存留了,所以在评估时不必考虑,但当出现高峰值,且系统处理无法及时处理时,可以积压一部分数据慢慢处理.

• 流量规划：

吞吐量的提升,也往往伴随着流量的提升,这时主要考虑峰值时流量即可,评估时可以按峰值吞吐量同比扩大.如果这个值比较大,应该和运维同事一起评估并寻求解决办法.

• 响应速度评估：

响应速度,是衡量服务对请求响应时间的指标,一般用毫秒计量,通常用 tp999,tp99,tp90 这几个指标,其中 tp999 指 99.9% 的服务请求的响应时间不会高于这个值.

提高响应速度,可以提高系统吞吐量.假设一个服务的响应时间为100ms,允许的并发数是500,则理论上这个服务的吞吐量上限为 5000(500*1000/100)tps；如果响应时间降低到50ms,则理论上的吞吐量上限会降为 10000tps.

但是提高响应速度会增加成本,一般说来可以采用类似下面的标准：

前端系统：

后端系统：

（编辑：ASP站长网）