京东618:商城交易平台的高可用架构之路

据腾讯科技报道,6月18日零点,京东全民年中购物节拉开了高潮的序幕。第一个小时的销售额超过去年同期的250%。从凌晨开始的海量订单让6月1日就拉开序幕的京东年中购物节奏出最强音,大量用户瞬间涌入,峰值订单被不断刷新。为了应对如此大规模的流量增长,京东研发团队几乎全年都在高筑墙、广积粮,一直着力从技术层面为用户提供流畅的交易体验,以保证在峰值交易时期系统的高可用性。在京东整个电商体系中,交易系统占据着其中的半壁江山,购物车、结算、库存、价格等相关的环节都包含在其中,可以说交易系统的高可用能力基本上决定了整个京东商城的高可用能力。在过去的一年时间里,京东的交易系统做了哪些迭代和优化?今年又有哪些创新?整体的交易系统规划是怎么样的?InfoQ记者带着这些问题采访了京东商城交易平台高级总监王晓钟。

ArchSummit全球架构师峰会深圳站将于2017年7月7日~8日在深圳·华侨城洲际酒店召开,京东商城运营研发部总架构师者文明策划了《低延迟系统架构设计》专题,将会为大家分享目前各大互联网企业在低延迟系统架构设计上都有哪些新思路,欢迎关注。

下面是往年京东618以及双11交易平台相关的文章:

受访嘉宾介绍

王晓钟,京东商城交易平台高级总监,京东交易黄金流程与智慧营销生态系统的掌舵人,带领的产品与研发团队为京东商城提供了核心交易的系统保证。

InfoQ:能否整体介绍下交易平台目前的架构体系?

王晓钟:交易平台负责商品、价格、用户、库存、订单等电商核心基础信息的中心化管理,以及对购物车、结算页、优惠券/礼品卡、订单中心等黄金交易流程的管控和平台化服务。交易平台致力于技术改变生活,打造智慧营销的交易平台。为用户提供黄金交易流程;为客户提供智慧营销解决方案包含促销建议、智能库存定位等智慧营销工具;为研发团队提供稳定、可靠的交易服务。

  1. 渠道是交易的流量入口来源,目前主要包含几大部分,PC、APP、微信、手Q等。目前APP入口已经占据了整体流量的70%以上。
  2. 组件完成对现有基础服务的抽象与整合,将现有服务资源以多元化的方式展示给外界,灵活的组织并支持多种协议的交互,最终实现了系统的模块化、服务平台化、功能配置化。组件最大限度的减少外界对内部逻辑的耦合,从而实现对需求快速响应。
  3. 基础服务位于整个黄金流程的最底层,其扮演者交易平台心脏的角色。其中商品服务、价格服务、库存服务、用户服务、购物车等更是核心中的核心。
  4. 中间件、基础设施是基础服务的基石,对业务系统提供高性能,高可用的技术支撑。

InfoQ:过去一年,交易平台在保证底层的基础平台稳固方面做了哪些事情?有哪些点读者是可以参考学习的?

王晓钟:除了我们一直在做的、已经形成常规的工作,比如线上压测、性能优化、扩容、故障切换、限流、降级之外,过去一年,我们在系统维稳方面做了一些精细化的工作。

  1. 核心调用链监控。在黄金交易流程中的各个服务入口点和服务相关依赖、调用方等进行联合监控。当服务性能下降、可用率下降时,可以快速的定位到故障点。把监控和故障解决方案联动起来,比如一键切换、服务降级、限流等,可以快速的发现和解决问题。
  2. 自动切换。对于成熟的切换流程,比如数据库、缓存、服务等节点的客户端,当检测到故障时,可以根据策略自动切换到健康的节点,同时在故障节点恢复后自动切换回来,减少人工操作的错误和耗时,提高系统的可用率。
  3. 异步化编程模式。部分服务通过彻底的异步化改造来提升吞吐量,还是有一些效果。但是由于纯异步化对于现有系统的改造还是挺大的,所以目前还在尝试前行阶段。
  4. 共享资源池。提前准备一些资源共享池,各服务混用,平时设置较低的权重。当某个服务的常规资源组不足时,则增加其在共享池中的权重,这样可以快速的使用资源,而不用临时扩容。
  5. 全链路压测。从入口开始模拟用户的行为进行压测,流量通过依赖传递,从浏览、搜索,到提交订单以及最后的生产,自动覆盖到链路中的所有环节。配合上面提到的核心调用链监控,解决以往只是单服务的压测,覆盖面不全的问题。

随着业务的发展,功能的复杂度也在不断增加,定位故障原因变的困难了起来,很多时候线上发生故障大部分的时间都在定位问题,故障的解决只要有预案就可以很快处理。调用链监控就很重要,可以站在全局的角度,快速的定位问题,和故障预案处理结合可以解决我们的痛点。

随着服务的不断扩容,机器数量的增加,出现问题时,故障修复的速度变慢,自动化的故障切换可以使人工解放出来,处理更重要的事情,可以让大家不用总是在半夜起来处理故障。

InfoQ:目前交易平台的服务是依据什么维度进行划分的?

王晓钟:目前交易平台主要依据业务能力来划分服务的:购物车、结算页、促销、价格、库存、商品、用户等,为PC,手机,微信等渠道提供高可靠的大中台服务。

这种划分模式好处在于:

  1. 架构稳定,因为业务能力相对稳定和相互独立。
  2. 开发团队是自主的,围绕着交付业务价值而不是技术特性来组织。
  3. 服务之间共同合作,松耦合。

InfoQ:能否分别从业务、系统、基础设施三个层面谈谈你们的监控体系方案?

王晓钟:在京东这样的大规模分布式系统面前,每时每刻服务器可能都宕机,网络随时可能都在抖动,大量接口调用量日均过亿,同时具有流量聚集效应的促销每天都会有好几波,如果没有一套强大的监控体系,我们就像睁眼瞎一样。经过多年的努力,京东目前已经形成多套监控系统,建立了比较完善的监控体系,时刻监视着系统的健康状态,并在发现问题时第一时间进行预警:

1)业务层面的监控,主要是核心业务指标,比如实时订单量,并按渠道、省份、运营商、机房、品类、活动等各个维度进行细分,从而在及时发现核心业务指标变化的同时,能够快速定位、排查问题,并做出应急响应。

2)系统层面的监控,主要是方法或代码块的调用量、成功率以及响应时间。同时,不同语言平台有特定的监控指标,例如Java应用,我们也非常关心JVM GC 情况。这些指标我们会按实例、集群、机房等进行逐级汇总计算。对于响应时间,我们更关心的是TP99甚至TP999任何一指标低于预设阈值都会触发报警。在采集单一接口性能数据的基础上,我们将请求访问链经过的一系列子调用串起来,包括RPC服务之间、访问缓存、访问数据库等等,实现调用链条薄弱环节的快速发现,快速解决。

3)基础设施的监控,主要是网络质量和机器健康度的监控,像常规的带宽、丢包率、重传、连通性,CPU、内存、磁盘等等。在网络方面,除了内网,我们也非常关心公网网络质量,一旦发现运营商或者区域故障,就会做立即出预案响应,7*24小时确保用户购物体验。

在监控指标完善的同时,我们更多在解决监控自身的延时性。京东自身访问量大,所以在提高监控的延时性同时又不能影响业务自身性能,本身就是就一个挑战。目前我们在业务层面、系统层面都做到了秒级粒度,基础设施方面的重要指标也有了秒级数据。在预警方面,除了传统的邮件、短信,我们集成了京东内部IM工具,同时还有手机语音呼叫。

在这么多指标,这么精细的数据面前,传统的监控仪表盘也会让我们再度迷失,因此我们开发了天眼系统进一步将各个监控子系统进行集成,结合前述的调用链,在一个大屏上多个核心主流程的各环节、各调用层次的当前健康状况一览无遗,一旦有故障我们可以在短时间内快速响应并恢复。

InfoQ:对于恶意的流量攻击,京东做了哪些准备工作?准备如何预防?

王晓钟:恶意流量攻击,是每个互联网企业都必须面对的难题。目前我们把流量攻击分为两大类:网络协议层和应用逻辑层。

网络协议层的,主要是SYNFlood、UDPFlood、DNSFlood、HTTPFlood这些4层或7层协议的各种流量攻击,主要以带宽或服务资源消耗为主。目前我们通过京东云平台自研的流量分析和清洗系统能够防御主流的恶意流量攻击。除此之外,信息安全部门也会联合外部力量进行上百G的流量攻防演练,确保合作和联动等实战能力。

应用逻辑层的恶意流量的范围和影响则比较广泛。狭义上,恶意流量利用应用系统的软件漏洞,做拒绝服务攻击;广义上,能够利用应用的实现逻辑或规则漏洞,非法实现各种商业利益的,无论流量大小,都属于恶意流量攻击。这一大类型攻击由京东的多个部门配合进行整体防御。

1)信息安全部门会通过开展安全自查和外部合作报告漏洞的方式,由各业务研发部门实施安全漏洞消除,比如SQL注入、代码执行、水平越权、信息泄露等。 
2)风控部门会通过数据分析,建立各种等级的风险控制模型,形成动态的不同风险等级的账户池,供业务系统使用。 
3)业务研发部门则根据业务特性、用户风险等级、系统压力等因素,提供不同策略的限流实现。

InfoQ:以商品的实时价格为例,聊聊你们的读逻辑和写逻辑流程?

王晓钟:京东实时价格面临几大挑战:一是数据量大,几十亿的商品;二是调用量大,日峰值上百亿;三是实时性要求高;最后是业务复杂度高,并不是单一的京东价,不仅要综合计算各类促销规则,还要对PC、手机、第三方合作渠道以及区域进行差异化运营。这里,我们运用读写分离、异步化策略,选择支撑大并发、高性能的开源组件进行设计,确保可水平扩展、高稳定性。 

1)写逻辑流程:当采销在后端调整价格或建立促销时,同步写入MySQL数据库,然后通过异步任务更新促销主Redis数据,并同时更新价格主Redis的过期时间戳,通过Redis自身复制机制,将数据传播到从节点。 
2)读逻辑流程:当用户在前端浏览商品列表、详情等页面时,异步访问价格实时服务,此时内嵌Nginx 的Lua程序直接读取本地Redis(从)中的价格数据,无过期则直接返回用户;若过期或不存在,则回源访问价格实时计算服务,即刻返回最新价格给用户。 
3)回源写逻辑:价格实时计算服务读取促销主Redis,在返回最新价格给用户的同时,异步写价格主Redis集群,价格主Redis同步数据至前置Nginx节点的从Redis节点。

InfoQ:今年618京东的交易平台都做了哪些技术上的改进或者创新,以及未来将会考虑哪些优化和升级方向?

王晓钟:除了上面提到的主要用来维护系统稳定的技术改造之外,今年交易平台也投入了更多的精力在做提升用户体验、提升GMV的改进和创新工作。比如利用大数据技术和机器学习模型,来提供千人千价、千人千促的体验。

我们也在尝试利用大数据和机器学习等在系统维稳上做一些工作,比如:

1)SQL注入和恶意代码执行方面引入了机器学习模型,通过对已有的攻击行为进行学习,训练特征。引入半监督学习,让模型可以通过学习,自动发现新型的攻击。大大提高了攻击的发现效率和新攻击的识别能力。各项指标已经完全超越传统的规则识别。

2)使用有向图模型对恶意攻击进行溯源检测,更加准确快速的进行溯源分析,并且得到了非常好的效果。

下一步,我们会继续尝试在这个方向上做一些创新,比如:

1)在人机行为检测方面进行优化。使用聚类和nlp模型对恶意刷单行为进行识别,提高恶意刷单行为的验证级别,从而极大地降低后台接口压力。

2)评论价值评定模型,识别真实评论和刷出来的评论。让评论产生更大的价值。

3)我们将在故障智能预测上进行探索。目前很多监控和预警都是事后的,我们希望能做到事前。通过分析历史性、周期性故障数据,结合当前实时健康度,快速识别出“濒死”的机器、实例,真正做到监控预警智慧化

时间: 2024-10-17 04:49:00

京东618:商城交易平台的高可用架构之路的相关文章

亿级商品详情页架构演进技术解密 | 高可用架构系列

亿级商品详情页架构演进技术解密 | 高可用架构系列 --http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=1&srcid=UfXZNNOVZZyZjQmp0VOh&from=groupmessage&isappinstalled=0#rd 此文是开涛在[三体高可用架构群]之分享内容

CentOS 7 部署百万pv项目(高可用架构)

PV简介 PV(Page View,页面浏览量)即点击量,通常意义上说PV的多少是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标.pv的解释是这样的:一个访问者在24小时(0点-23点)内到底看了网站的几个页面.需要注意的是:同一个人浏览网站的同一个页面,不重复计算pv量,点击100次页只算1次. 百万pv网站架构 本次实验设计采用四层模式实现,主要分为前端反向代理层.web层.数据库缓存层和数据库层.前端反向代理层采用主备模式,web层采用集群模式,数据库缓存层采用主备模式,数据库层采用

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

存储系统高可用架构

1 存储系统高可用架构 1.1 系统整体架构 2 主要部件相关机制 2.1 pacemaker + cman + corosync 这部分主要工作有以下方面:(1)关于高可用架构的选型 2.1.1 IBA网络 IBA虚拟化 2.1.2 Lustre文件系统 双控盘阵支撑 盘整MMP参数调整 lustre服务脚本改造 Lustre resource脚本 2.1.3 虚拟机及内lwfsd管理 Lwfsd resource脚本 虚拟机服务加入到pacemaker 2.1.4 高可用图形界面展示 2.2

drbd+heartbeat+nfs高可用架构搭建

一.客户需求 1.需求描述 有些客户有自己的存储设备,但是并没有集群文件系统服务,所以如果我们多个节点(计算节点)如果想同时使用其中的一个块且要保证高可用的话,就需要我们自己来完成类似集群文件系统的服务组合,在此我们使用的服务组合是:iscsi共享+drbd+heartbeat+nfs. 2.服务说明 Iscsi共享:这里通过iscsi共享服务将存储设备上的存储块共享出去,提供节点(NC1+NC2)使用,此处我们将在iscsi服务短创建两个镜像充当块设备. Drbd   :服务器之间镜像块设备内

企业中MySQL主流高可用架构实战三部曲之MHA

老张最近两天有些忙,一些老铁一直问,啥时更新博文,我可能做不到天天更新啊,但保证以后一有空就写一些干货知识分享给大家. 我们如果想要做好技术这项工作,一定要做到理论与实践先结合.我一个曾经被数据库虐得体无完肤的过来人给大家一些建议:就是只看书,背理论真的行不通,到时遇到棘手的问题,你还是一样抓瞎.一定要在理论理清的基础上多做实验. 给自己定个目标,3个月做够100-500个实验.然后整理在做实验过程中的各种报错,认真解读分析报错原理,做好笔记.最后再拿起书,重新阅读之前有些可能理解不了的理论知识

数据库高可用架构 转载

数据库高可用架构对于我们这些应用端开发的人来说是一个比较陌生的领域,是在具体的数据库产品之上搭建的环境,需要像DBA这样对数据库产品有足够的了解才能有所涉及,虽然不能深入其中,但可以通过一些经典的高可用架构学习其中的思想.就我所了解到的有以下几种: MySQL Replication MySQL Cluster Oracle RAC IBM HACMP Oracle ASM MySQL Replication MySQL Replication就是通过异步复制多个copy以达到提高可用性的目的,

单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构(转)

转自http://www.php1.cn/Content/DanBiao_60_YiJiLuDengDaShuJuChangJingDe_MySQL_YouHuaHeYunWeiZhiDao_%7C_GaoKeYongJiaGou.html, 更多详细资料请参看原文 此文是根据杨尚刚在[QCON高可用架构群]中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计.前新浪高

高可用架构篇--MyCat在MySQL主从复制基础上实现读写分离

点击链接加入群[Dubbo技术交流2群]:https://jq.qq.com/?_wv=1027&k=46DcDFI 一.环境 操作系统:CentOS-6.6-x86_64-bin-DVD1.iso JDK版本:jdk1.7.0_45 MyCat版本:Mycat-server-1.4-release-20151019230038-linux.tar.gz MyCat节点IP:192.168.1.203      主机名:edu-mycat-01  主机配置:4核CPU.4G内存 MySQL版本: