京东 618：多中心交易平台系统高压下的高可用性

对于京东来说，每年的 618 大促都是一年中最重要也是挑战最大的技术考试。去年 618 京东平台单日成交订单量逾千万，同比增长超一倍。京东推测今年下单量将会继续成倍增长，并为此加强了系统处理能力。这千万数量级的成交订单背后，一定是需要够硬的技术支撑。在过去的一年，京东都做了哪些技术突破？如何应对本次 618 大促?

ArchSummit 全球架构师峰会深圳站将于 2016 年 7 月 15 日~16 日在深圳·华侨城洲际酒店召开，大会设置了《电商大促背后的技术较量》专题来深入解读电商大促背后的技术故事，欢迎关注。

InfoQ 记者采访了京东资深构架师吴博，分享京东自主研发的多中心交易平台系统。

受访嘉宾介绍

吴博，应用架构师，京东架构委员会成员。2013 年加入京东，负责应用架构设计和治理工作。有 10 多年的互联网工作经验，参与过大型 B2C 电商平台、搜索引擎、Hadoop 云平台等系统的方案设计。对分布式系统、海量数据分析、高性能系统方向比较感兴趣。

InfoQ：本次 618，对于交易平台，您认为最大的挑战是什么？为了应对这样的挑战，京东都做了哪些准备？

吴博：本次 618 对于交易平台，最大挑战仍然是如何保障大流量下的系统高可用性。为了保障高可用性，618 前我们上线了多中心交易平台系统二期，保证应用系统和数据库的高性能以及多机房多活。而且，今年 5 月份还上线了诺亚方舟二期，全部的应用系统都运行在万兆网络环境的容器上，保证流量超预期时，系统能快速水平扩展。通过各系统配合线上压测不断调整和优化性能，在保证合理的延时指标时，最大化提高系统吞吐能力，有效利用每个容器的资源。

为了进一步提升交易平台的高可用性，我们针对 REST、RPC 两类服务在 nginx、JSF 框架层做了限流保护措施。对于 JSF，实现了基于频次和 CPU 利用率阈值的熔断机制。

对于核心的交易流程链路上的各个服务，交易平台统一了原来分散在各处的流量可视化和故障切换平台，以便提高故障定位能力和切换速度。

InfoQ：您认为在本次 618 准备过程中，京东主要的技术突破、亮点和创新都有什么？

吴博：本次 618 准备，重点在 3 个方向：推进平台化、开展智能化、尝试自动化。平台化目的是保障京东业务变化灵活多样，提升核心系统高可用性；智能化目的是实现技术驱动业务的发展，比如利用大数据分析，指导应用系统和业务流程的优化；自动化是在智能化的基础上，尝试让机器做决策，减少人工参与，提高人效时效。

平台化方向：京东在这次 618 前，完成了多中心交易系统 2 期，保障应用系统和数据多机房多活；顺利实施了诺亚方舟计划，完成 2 个大型数据中心的建设，京东的全部应用系统和部分数据库系统部署在弹性云上，实现资源动态按需分配；深化了仓储平台化，搭建 EDI 平台，理顺与厂商信息交换壁垒。

智能化方向：智能化是这次 618 的一个亮点，重点是用大数据指挥 618 大促，基于京东大脑的画像和知识图谱，搭建智能卖场，让大促更智能。

例如，智能卖场的应用，可视化展示大促中的人货场，实时分析顾客的构成和顾客购物路径：他们从哪里来？想买什么？正在围观什么商品？正在往购物车中放什么？结算的转换率？库销比等等，并在此基础上做矩阵分析。

为了解决智能卖场实时分析难题，我们设计了 JingoBase 实时计算平台，较好地解决了百亿级点击流、十亿级商品、用户和订单数据的实时关联分析问题。数据存储采用定制化的 kudu 列存储方案，解决点击流数据快速读写问题；计算框架采用定制化的 Dremel 框架，做关联分析；利用内存平台做基于 SQL 的主数据投影，进行数据裁剪（例如，商品主数据十亿级，每天动销商品千万级，利用数据投影和主数据更新慢的特点，能大幅提高系统分析能力）。

自动化方向：京东研发一直致力于“仓配客”的自动化、无人化研发。今年 618 的最大创新点是，京东将率先在全国多个省市用自己研发的无人机送货，这将大大提高配送时效，京东的配送无人车、仓储机器人也正在紧锣密鼓的研发中。

客服机器人 JIMI 也取得了突破性的进展，研发团队将深度神经网络嵌入到 DeepQA 框架中，利用深度神经网络的复杂模型表示能力，改善性能。同时，研发全新的场景引擎，通过意图识别模型与记忆模型的整合，使 JIMI 能更深刻的理解业务，并通过和用户的多轮交互收集意图信息，提升服务质量。在本次 618 中，会将该技术拓展到更多的售前售后业务上。

InfoQ：能介绍下你们的压力测试方案吗？

吴博：每年 618 我们会提前预估一个容量指导值，各部门按指导值进行压测，合理配置资源。618 压测主要分为：线下压测、线上压测和全流程压测。

线下压测在测试环境进行，主要是单实例、单机、单集群压测，目的是找到系统的基本性能问题，进行优化改进。并依据压测结果，预估线上系统的容量，并利用线上压测验证。

线上压测是对线上系统按比例隔离，模拟真实访问场景，进行线上的多机房集群压测，找出集群的瓶颈点进行优化，得出线上系统能承受的量，作为扩容和容灾方案的依据。

全流程压测是每年 618 大促必做的功课，观察多系统在峰值流量下的相互影响。

InfoQ：在这么大规模的集群中，京东是如何保证数据一致性的？

吴博：大规模分布式系统的一致性问题一直都是业界关注和讨论的焦点，也是系统设计上的一个难题，如何保证数据水平拆分，冗余多份存储的同时不引入数据不一致的问题，各厂均有自己的解决方案和经验总结。

京东在这个问题上，从存储层和业务层都解决了这个问题，同时保证数据严格的一致性。

1）在存储层，我们同时使用主流的开源数据库 MySQL 和我们自主研发的分布式存储系统，来保证海量数据的可靠存储和高性能访问。针对 MySQL，我们在半同步复制基础上做了一些优化和定制，很好的保证了主从切换以及数据访问的一致性问题。针对京东自研的分布式存储平台，我们引入了诸如 Paxos 等主流强一致算法来保证多副本之间的一致性问题。

2）在业务层，不同业务域对数据的一致性要求不同，例如交易环节，对系统的可用性要求高，需要优先保证用户能快速下单，数据要求最终一致性；履约环节的可用性要求没有交易环节高，但对订单状态数据的一致性有较高要求。针对数据一致性要求很高的业务会自己再做一层对账机制，来严格校验和补齐数据，保证数据一致性问题，部分极端情况，也有业务会牺牲掉可用性问题来换取一致性，比如单机 Scale Up 的方案，这样也可以天然屏蔽一致性问题。

InfoQ：为了保证用户体验，在资源有限的条件下，我们必须保证关键系统的稳定性，这也就引入了响应的服务降级方案，能谈谈你们这块是怎么做的吗？

吴博：每年 618 大促的一项重要工作是，研发各部门的预案起草、演练和评审。各部门会针对大促中可能出现的各种问题，提出扩容、限流、降级和故障转移等解决方案，并逐条演练和评审。目的是保障商城业务黄金流程的稳定性，出现故障时，能有条不紊地快速按预案执行，减少故障影响时间。

我们先将系统分层：业务层、应用层、数据层和基础层。其中，业务层上的系统比较轻、靠前；应用层上主要是一些平台级系统，如交易系统、商品系统、用户系统、履约系统等；数据层上主要是生产库相关的系统；基础层上是一些缓存、消息中间件和存储基础件等系统。并制定各层间的依赖原则：上层可以依赖下层，下层不能依赖上层，同层之间尽量异步解耦，避免循环依赖等。

再将系统分级：按业务的重要程度以及故障的影响范围进行分级，分成 0 级系统、1 级系统、2 级系统等，并区分系统中的核心服务与非核心服务，从服务治理的角度进行规划，对服务进行分级分层治理，重点保障 0 级系统核心服务的稳定性。同时制定系统间的依赖原则：0 级系统不依赖 1 级系统，核心服务不依赖非核心服务等。

经过以上的治理措施后，主业务链上的核心服务发生故障的可能性和影响范围已大大降低。但是在资源有限条件下，还是可能会有影响稳定性的事件发生。这就需要有依赖关系的各服务之间约定好 SLA，超过约定时或者出现特殊事件时，可以进行报警和降级处理。

在制定降级预案时，解除服务依赖并不是唯一的选择，而是根据业务特点、系统特点和具体场景制定多级降级策略。客户端可以采取的降级策略有：解除对非核心的服务依赖，降低服务调用频次，优先处理高优先级和紧急的业务，使用内置简易逻辑处理简单数据。总原则是保证主流程顺畅，降低事件影响范围。服务端可以采取的降级策略有：对相对次要的流量进行限制，对整体流量进行限制，启用备用服务，总的原则是保障服务可用。

实际降级措施后，可能会引起数据不一致现象，所以需要事先准备好数据一致性维护机制，借助日志、状态机等工具，找到不一致的数据，进行补偿，达到数据最终一致。

InfoQ：能谈谈你们的峰值系统的监控架构和方案吗？

吴博：监控系统是技术人员的眼睛，好的监控系统就像一台 CT 机一样，能够透察系统的运转情况。京东的业务具有两个显著特点，一个是业务链条长，一个是促销带来系统的动态性大，因此京东从很早开始构建全方位的监控系统，来实现对系统的洞察力，保障大促和业务的日常运转。

京东的监控系统分为三个层面：业务、系统、基础设施。

1）业务层面的监控，主要侧重在公司的核心业务指标及其多维度的细分，比如公司的实时订单量，以及订单在渠道、省份、运营商、机房、品类、活动等各个维度进行监控，从而在及时发现核心业务指标变化的同时，能够快速定位到问题可能的位置。

2）系统层面的监控，主要是实现系统间各个调用关系及核心处理过程的监控，比如对于两个系统间典型的交互过程，会给出从双方角度看出的调用次数、各分位值的 Latency、成功率等，特别是，对于一个长链条的复杂调用关系，能够从前到后实现贯穿，从而实现在系统角度的快速问题定位。

3）基础设施的监控，主要是机器和网络层面的监控，这是所有业务运行的基础环境，我们会从交换机、服务器、容器上采用黑盒和白盒两种方式来收集对应的指标数据，黑盒数据用于效果的监控，白盒数据用于细化的问题追查，双管齐下，快速协助业务确定基础设施是否正常，以及问题在什么位置。

从监控系统的设计和实现角度，可分为采集、传输、存储与查询、异常检测、Dashboard、报警收敛等各个层面，京东在传统监控系统基础上，结合京东的业务特点进行定制和针对扩展性的研发。比如，我们在京东的 RPC 框架中都植入了统一的 SDK， 能够自动统计 RPC 的调用次数、成功率、时延等指标，在业务层面，我们基本上也按照一套统一的基础设施，多套业务自定义的 Dashboard、数据关联等业务逻辑的方式进行监控系统的收敛和扩展，保证灵活性的同时，避免重复造轮子。

InfoQ：对于超卖，目前京东是如何解决的？这个方案是最优的吗?

吴博：京东有独立的库存系统，分别从业务规则和技术两方面解决超卖问题：

1）从业务规则的上进行防超卖。先根据商品编码查询库存主数据；再计算各个库存项，包括现货、预售、在途等等，按照一些设定的业务规则，进行扣减前校验；然后做库存扣减，库存扣减后校验（回滚）。

2）从技术上防超卖。随着订单量的增长，传统单数据库已经无法满足我们需求，我们将库存扣减数据都放到 redis 进行处理，利用 redis 只能顺序执行命令的特性，进行订单号防重提交处理 ; 然后利用单物理机进行内部数据流转、关键数据闭环处理来保证数据准确性；同时将各阶段的关键数据落地，统计已产生的各项数据并汇总，进行差异比对和数据核查。

这个方案也不一定是最优的，但能满足京东目前的需求。根据目前比对情况来看，库存差异很小，超卖情况基本没有。一些微小的差异，基本也是由于一些新老业务冲突问题或程序更新的 bug 导致的。

InfoQ：您是如何看待微服务架构的？可以介绍下京东商城的微服务化落地流程和方案吗？对于电商平台的微服务化，您有什么可以传递给读者的经验吗？

吴博：微服务是一种较实用架构思想，早在“微服务”提出之前，一些大公司就有不少类似的架构实践，比如腾讯的“大系统小做，分而治之”做法。大的互联网公司很少照搬传统 SOA 架构中的 ESB 企业服务总线，而是结合自己公司的实际情况做一些改进。

京东商城的架构并没有强调微服务化，平时的架构规划中或多或少地有这方面的体现。目前的京东架构的重点是平台化：保证底层的基础平台基础稳固，中层的应用平台高可用，上层的业务轻薄敏捷。每层服务的要求不太一样，对于中层和底层服务，更重视基础服务的隔离、解耦和高可用。

互联网公司看重的是架构“落地能力”，找到适合自己公司特点的架构，并让架构能在公司业务的快速发展中不断完善，没有一种架构能适用所有公司短中长期发展。不建议过多强调架构的先进性。

“三流的点子加一流的执行力，永远比一流的点子加三流的执行力更好。”

感谢郭蕾对本文的审校。