武汉的开发者们注意啦!AI技术战略、框架以及最佳实战尽在Azure OpenAI Day 了解详情
写点什么

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

评论

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

TOGAF企业架构框架4-内容框架

Marvin Ma

架构 TOGAF 企业架构框架 内容框架

Baklib知识分享|企业知识管理难,该如何解决?

Baklib

真正的高效能RPC框架Focus

dinstone

json RPC 高性能 protobuf 跨语言

Spring Boot「21」JPA 中的 Entity

Samson

Java hibernate Spring Boot 学习笔记 11月月更

Java | IO流介绍

陌上

Java 编程 11月月更

基于 Grafana LGTM 可观测性平台的快速构建

Grafana 爱好者

可观测性 Observability

融云钜惠来袭,新客尝鲜首月 2.7 折起,超值套餐 6 折起

融云 RongCloud

产品

FFmpeg-ffplay播放器分析(1).md

Changing Lin

音视频 ffmpeg 安卓

云原生生态 我们选择了哪些

Rayzh

Docker Kubernetes, 云原生, eBPF

Baklib经验分享 | 一些搭建帮助中心的攻略

Baklib

帮助中心

SAP UI5 BarcodeScannerButton 的初始化逻辑 - feature 检测,Cordova API 检测等逻辑

Jerry Wang

前端开发 Fiori SAP UI5 ui5 11月月更

融云通信云服务,助力医疗招聘平台构建行业护城河

融云 RongCloud

通信 医疗 融云

JavaScript刷LeetCode拿offer-滑动窗口

Geek_07a724

JavaScript LeetCode

使用Vmware创建Centos7虚拟机(安装和配置网络环境、xshell连接、防火墙、yum仓库、磁盘挂载、重启命令)

A-刘晨阳

Linux 运维 vmware 11月月更

Go语言入门11—接口

良猿

Go golang 后端 11月月更

JavaScript刷LeetCode拿offer-双指针技巧Medium篇

Geek_07a724

JavaScript LeetCode

如何写成高性能的代码(三):巧用稀疏矩阵节省内存占用

葡萄城技术团队

前端 稀疏矩阵

Nginx配置中root和alias分不清?本文3分钟帮你解惑!

wljslmz

nginx 服务器 root 11月月更 alias

以开发之名|线上家装新美学——梦想之家,由你来定

HMS Core

AR HMS Core

MongoDB源码学习:mongod如何处理请求

云里有只猫

mongodb 源码学习

Linux常用基础命令(巨全)

A-刘晨阳

Linux 运维 11月月更 基础命令

前端工程师leetcode算法面试必备-二分搜索算法(上)

js2030code

JavaScript LeetCode

前端工程师leetcode算法面试必备-二分搜索算法(下)

js2030code

JavaScript LeetCode

TOGAF企业架构框架5-企业连续统一体

Marvin Ma

TOGAF 企业架构框架 架构分区 企业连续统一体 架构存储库

TOGAF架构框架3-ADM架构开发技术

Marvin Ma

架构 TOGAF ADM架构开发方法

前端工程师leetcode算法面试必备-二分搜索算法(中)

js2030code

JavaScript LeetCode

透过关键基础设施安全事件谈SBOM

安势信息

Gartner SCA 软件物料清单 SBOM 清源CleanSource SCA

EDAS 流量入口网关最佳实践

阿里巴巴云原生

阿里云 分布式 云原生 网关

云渲染是CG的最后一道工序,四个特性让你的渲染更高效

Finovy Cloud

云渲染 云渲染农场

软件测试面试真题 | 讲讲 OSI 七层模型,每层模型具体干嘛的?

测试人

物联网数据分析(上篇)——业务系统架构类

阿里云AIoT

阿里云 数据分析 物联网 业务架构 数据存储

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