转载

京东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:多中心交易平台系统高压下的高可用性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

感谢郭蕾对本文的审校。

原文  http://www.infoq.com/cn/news/2016/06/jd-618-multicentertransactionsys
正文到此结束
Loading...