写点什么

京东 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:006115

评论

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

一个草根的日常杂碎(9月27日)

刘新吾

随笔杂谈 生活记录 社会百态

PPT画成这样,述职答辩还能过吗?

小傅哥

Java 小傅哥 流程图 架构师 PPT

查看mac电脑的温度信息, 并且给mac电脑降温

lmymirror

macos Mac terminal

华为全联接2020:环信AI领跑,输出5大行业最佳实践

DT极客

奈学开发者社区分享:Java - 设计模式的7个设计原则

古月木易

Java 设计模式

一文纵览向量检索

华为云开发者联盟

数据 搜索 检索 检查

数字货币是大势所趋,新冠疫情后必须率先发展DCEP

CECBC

数字货币 银行

大学四年我是怎么写操作系统和计算机网络的?掏心掏肺的分享!

小林coding

学习 程序员 计算机网络 操作系统 计算机基础

关于互联网留存和收益你知道多少—带你走近用户成长体系

滴滴普惠出行

第 0 次面试

escray

程序员 面试 面经

H5选图预览到上传最佳实践

阿里云金融线TAM SRE专家服务团队

android H5

关于深浅拷贝

西贝

Java 大前端 基础

Electron 快速入门及最新安装教程

程序员学院

Java html 大前端 Electron node,js

初学源码之——银行案例手写IOC和AOP

Java架构师迁哥

中国Prime会员独享巅峰64小时超长跨境网购时间

爱极客侠

融云技术分享:基于WebRTC的实时音视频首帧显示时间优化实践

JackJiang

音视频 即时通讯 实时通信

Binder那么弱怎么面大厂?

博文视点Broadview

Java android 通信 移动开发 Android进阶

实践分享丨物联网操作系统中的任务管理

华为云开发者联盟

华为 数据 物联网 进程

深入理解MySQL中事务隔离级别的实现原理

X先生

MySQL 数据库 后端 事务

牛皮!应届生面试阿里Java岗,七轮过后定级P6,薪资44.8W

面试 计算机基础 编程开发 架构师技能

for-range造就循环永动机?快来看看go中for-range的那些事!

Gopher指北

后端 for Go 语言

戴尔G系列游戏本助玩家激战英特尔大师挑战赛

E科讯

区块链会替代大数据吗?

CECBC

区块链 大数据

三年筑一“用”:长跑中的智能IP网络

脑极体

一文领略 HTTP 的前世今生

yes

互联网 网络 HTTP 阿帕网

奈学开发者社区分享:Java - 设计模式的7个设计原则

奈学教育

Java 设计模式 设计原则

世界的下一个主宰——人工智能

CECBC

人工智能 智能时代

bug 回忆录(一)

志学Python

一个草根的日常杂碎(9月28日)

刘新吾

随笔杂谈 生活记录 社会百态

架构1期第三周作业一

道长

极客大学架构师训练营

公有云厂商哪家强?本月UCloud、百度云、阿里云位居三甲——2020年8月云主机性能评测排名

博睿数据

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