速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

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

  • 2016-06-17
  • 本文字数:5035 字

    阅读完需:约 17 分钟

对于京东来说,每年的 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 企业服务总线,而是结合自己公司的实际情况做一些改进。

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

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

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

感谢郭蕾对本文的审校。

2016-06-17 18:005576

评论

发布
暂无评论
发现更多内容

Flutter与Dart-入门

android 程序员 移动开发

Flutter开发之——运行卡在gradle assembleDebug

android 程序员 移动开发

Flutter版-WanAndroid-App

android 程序员 移动开发

Fragment的使用

android 程序员 移动开发

Google Pay支付遇到的问题

android 程序员 移动开发

Flutter如何实现下拉刷新和上拉加载更多(1)

android 程序员 移动开发

Flutter实战1 --- 写一个天气查询的APP

android 程序员 移动开发

Flutter绘制-11-旋转小人儿造成的视觉错效

android 程序员 移动开发

Fragment add与replace的区别(1)(1)

android 程序员 移动开发

Flutter集成高德定位和地图功能

android 程序员 移动开发

google vr 入门之制作简易的VR播放器(二)

android 程序员 移动开发

GridLayoutManager这么用,你可能还真没尝试过

android 程序员 移动开发

Flutter动画:用Flutter来实现一个拍手动画

android 程序员 移动开发

Flutter教程(二) 了解Dart语言

android 程序员 移动开发

Flutter状态管理--Getx学习2

android 程序员 移动开发

Flutter填坑全面总结(包括Flutter1

android 程序员 移动开发

Fragment极度懒加载-+-Layout子线程预加载,奇妙的APP启动速度优化思路

android 程序员 移动开发

GC 回收机制与分代回收策略

android 程序员 移动开发

git 补丁 - diff 和 patch 使用详解(1)

android 程序员 移动开发

Gson用户指南

android 程序员 移动开发

Flutter如何实现下拉刷新和上拉加载更多

android 程序员 移动开发

Github标星3-2K-2020BATJ数据结构与算法笔试题及其答案吐血整理!

android 程序员 移动开发

Flutter开发之——Menu

android 程序员 移动开发

Flutter开发之——事件监听

android 程序员 移动开发

Flutter:基于video_player实现视频相关手势控制、全屏播放

android 程序员 移动开发

Github TOP100 Android开源

android 程序员 移动开发

Flutter开发中的一些Tips(二)

android 程序员 移动开发

Flutter的原理及美团的实践(中)

android 程序员 移动开发

Glide的简单封装GlideUtils

android 程序员 移动开发

HashMap及HashTable源码解析

android 程序员 移动开发

HashMap源码分析 —— 一篇文章搞定HashMap面试

android 程序员 移动开发

京东618:多中心交易平台系统高压下的高可用性_架构_穆寰_InfoQ精选文章