京东研发【资深架构师的实战真知】大型促销项目备战思路和方法

转自京东研发-“大型促销项目备战思路和方法”

作者：林世洪

京东营销研发部，零售平台

架构师

备战，不一定要到大型促销时，京东已发展到了一个比较大的体量，无论是大促还是平时，都容不得出现大问题，需要做到：积极预防、及时发现、快速处理，但要做到这十二字方针并不容易，有两个要素不可或缺：日渐成熟稳定的团队、日趋完善的流程和规范。
 

1.积极防预问题

        可以遵循PDCA方法　　
        1.分析系统职责，确立系统备战的首要目标
　　2.进行需求评估，然后进行系统现状评估，找出系统瓶颈。
　　3.针对系统瓶颈，进行系统改造
　　4.梳理系统间的依赖关系，各系统之间达成SLA，以保证整体性能指标
　　5.对系统进行压力测试，验证处理能力，确保达标。
　　6.*特别地，如果是大促前夕，则要对系统进行全面体检
　　如果系统改造达不到评估要求，则需要修正方案

↑每个系统都会有自己的边界，各系统负责人应该分析清楚系统的使命和职责是什么，分清主次，这同时也是制定应急预案的最重要依据，这点尤其重要。　　举例说明： OFC，其最重要的是保证订单生产部门有订单可生产，尽量不影响其产能，在这个前提下，可以采取各种灵活措施。例如，假设某个库房的最高生产能力为10万单，而当时产生的订单有20万，这时系统保障把10万订单送给这个库房生产就能满足生产要求了，此时可以把系统处理能力分配给POP订单处理。

 

↑1.2.1. 性能需求评估　　

    总体思路：
　　首先要有业务量的初估，然后各个团队可以根据此值分解到所负责的系统的吞吐量指标。
　　吞吐能力评估：
　　假设一个系统是订单处理系统，每一个订单向它输入2条处理请求，并向外界输出4条信息，如果一天的订单量是1000万，则这个系统要每天接收2000万个请求，输出4000万条信息。另一个评估方法是参照以前的实际吞吐能力，按业务量同比扩大（称为参照法）。
　　评估时需要高度重视峰值，可以用参照法评估; 如果是一个新系统，可以让上游系统协助评估。
　　并不是所有系统都要承担高峰值。例如，在订单处理流程中，OFC扮演了这一个稳压器的作用，OFC订单峰值进行了平滑，后面的系统只需要按平滑后的流量进行设计，大大节约了建设成本。所以吞吐能力的评估也需要团队合作。
　　容量规划：
　　吞吐量的提升，往往伴随着容量提升，需要做好容量规划，主要考虑的因素有：
　　1.主业务对象的量（如订单）以及到大促前的增长量
　　2.每个主业务对象会占用多少容量
　　3.数据要在线上主系统中存留的时间
　　4.出现高峰时，允许积压的数据量和积压时间
　　流量规划
　　吞吐量的提升，也往往伴随着流量的提升，需要做好流量规划，这时主要考虑峰值时流量即可，可以按参照法评估。

↑1.2.2. 系统性能评估与验证的一般方法　　

    1.通过UMP来查看响应时间、吞吐量
　　2.对于worker，根据其实际输入输出的数据量来统计
　　3.线下压力测试。梳理出所有开放的接口，在线下进行接口压力测试。测试用的数据可以根据业务逻辑进行编制，也可以利用TCP Copy等技术获取。
　　4.线上读接口压力测试
　　5.线上写接口压力测试。这种测试应该非常小心，注意不要产生垃圾数据，对业务造成影响。常用的避免影响业务的方法有：
　　    a)给数据打上测试标签，所有参与测试的系统都要根据此标签识别出正式数据和测试数据。
　　    b)设计好数据处理流程，在这个流程的最后一步才是真正地把数据提交到正式的主业务库，而测试流程不执行这一步，或者结合标签的方法，在这一步过虑掉测试数据。
　　6.减少线上服务器数量，让更少的服务器承担压力，从而增大单台服务器的负载。
　　7.*如果面临大促，则可以考虑在线上做跨系统主流程压测：在上游积压一定量的数据，以设计好的速度下发请求，验证后面的流程在设计的并发请求量下是否畅通。这种方法不但需要跨研发团队沟通，也需要和业务团队进行沟通，因为可能会影响到生产时效。

SLA确认上下游系统之间必须进行SLA确认，如果被依赖的系统性能不达标，则依赖方的系统不可能达标。确认工作应该及早进行。

　　其中，”是否可降级”请参照应急方案一节中的描述。
　　“超时”指服务调用方的超时设置，如在设置时间内未得到响应，调用方可以重试。如果存在多级依赖关系，如A调用B，B调用C，则超时设置应该是 A>B>C，以避免引起DDOS攻击效果。

系统改造

↑系统改造的目标是将吞吐量指标提高到评估的水平，同时其它性能指标仍能满足业务要求。 这样兼顾了性能和成本。
　　架构委员会发布的架构白皮书，系统地介绍了架构的原则和方法，非常有指导意义。本文不再重复，只从应用角度出发，列举最常用的方法。

↑1.4.1. 提高系统处理能力　　
    －硬件升级。　　
    －使系统具备水平扩展能力，并进行扩容，甚至以集群为单位进行扩容。这一点最为关键。
　　－多维度的系统拆分
　　－提高响应速度。详见保持响应速度一节。
　　－使用编程技巧，如串行变并行、单个处理变批量处理等

↑1.4.2. 保持响应速度
－Review系统并针对问题进行改造。对系统的每一层，甚至硬件都进行审查。
　　－使用缓存。从客户端到服务端的全路径上，每个节点都可以设置缓存。
　　－优化依赖。常用的优化方法有：同步改异步、依赖倒置。
　　－方法职责单一化
　　－清理历史数据
　　－读写分离

↑1.4.3. 保持可用性
－流量限制
　　－分流
　　－任务分级，当系统处理能力下降时，尽量保持高优先级任务的执行
　　－数据分类，当某个服务不可用，那些不依赖这个服务的数据应该得到处理
　　－降级
　　－容错，系统多活，一个节点出现故障时，其它节点还可以工作
　　－故障转移

↑系统性能评估与验证的方法同样适用于本工作。

 

↑就像运动员备战运动会一样，需要进行体检，以保证系统以优良的状态迎接大促。

 

2.及时发现问题

　　互联网企业，业务发展和变更速度比较快，系统变更频繁，难免出现问题。问题发现的越早，才能越早介入处理；如果能在问题发生之前就发现问题的趋势，并及时介入处理，就可能避免问题发生。　　常见的应用级别的监控有：

 

3.快速决策和处理

　　系统运行时可能遇到各种各样的问题，如果有对应的应急预案，并演练到位，则可从容面对。当出现紧急情况时，最要紧并不是去寻找问题的根源，而是果断采取措施控制住影响。越早决策，影响就越小。
 

↑3.1.1. 风险分析　　系统运行时可能遇到各种各样的问题，常见的有：

↑3.1.2. 常用预案和处理方法

快速决策和执行

　　－提前收集好各类信息，尽快判断问题是否真的发生
　　－提前打开工具的操作界面
　　－优先控制问题影响，然后排除问题
　　－进行培训和演练
　　－*特别地，大促时，建立统一指挥机制，并严格执行现场值班制度
 

4.成熟稳定的团队

↑由于互联网业务发展变化较快，系统变更也比较频繁，不适合开发和运营分家的模式，而是自己建设的系统，自己负责运营。这样，不但能提高运营效率，而且团队可以在运营过程中发现问题，体验问题带来的痛苦，然后会想办法改进设计，避免问题再次发生。这样的团队建设的系统会更易于运营，性能更加稳定，团队的设计能力也会显著提升，团队也就会趋于稳定和成熟，形成了良性循环。
 

5.流程和规范

　　备战大促，涉及到许多团队，需要大家通力合作，也就需要遵循一定的制定和流程规范，下表列举了几个。

 

6.小结

我们回顾一下备战的思路和方法，平时就要认真做好：
　　－积极预防，遵循PDCA模型，在系统建设之初就注重非功能设计，注重如何方便日常运营，并持续改进系统
　　－提高发现问题的能力，能及早发现问题，甚至在问题发生前就介入处理
不断完善监控，增强趋势分析能力，是最关键的方法。
　　－提高问题决策和处理问题的速度，迅速控制住问题影响，并解决问题。
　　不断积累应急预案，并进行演练，是最重要的、最实用的快速处理问题的手段。

如果面临大促，则有必要采取的措施有：

　　－用大促的业务量预估来对系统进行评估
　　－采取更加严格的检查措施，考虑进行跨系统的线上军演；大促前夕对系统进行全面的健康体检。
　　－大促来临时，执行严格的现场值班制度
　　－建立统一统一指挥机制

   要能很好地执行以上方法，应该具备两个要素：
　　  －日渐成熟的团队。开发团队即运营团队，团队在运营过程中发现问题，并通过系统设计解决问题，设计和运营能力一起提升。
　　    －日趋完善的流程和规范，保障备战措施的顺利实施，促进团队进步

下图是对如上内容的总结：