对于京东来说，每年的618大促都是一年中最重要也是挑战最大的技术考试。去年618京东平台单日成交订单量逾千万，同比增长超一倍。京东推测今年下单量将会继续成倍增长，并为此加强了系统处理能力。这千万数量级的成交订单背后，一定是需要够硬的技术支撑。在过去的一年，京东都做了哪些技术突破？如何应对本次618大促?
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企业服务总线，而是结合自己公司的实际情况做一些改进。
京东商城的架构并没有强调微服务化，平时的架构规划中或多或少地有这方面的体现。目前的京东架构的重点是平台化：保证底层的基础平台基础稳固，中层的应用平台高可用，上层的业务轻薄敏捷。每层服务的要求不太一样，对于中层和底层服务，更重视基础服务的隔离、解耦和高可用。
互联网公司看重的是架构“落地能力”，找到适合自己公司特点的架构，并让架构能在公司业务的快速发展中不断完善，没有一种架构能适用所有公司短中长期发展。不建议过多强调架构的先进性。
“三流的点子加一流的执行力，永远比一流的点子加三流的执行力更好。”
