当前位置: 首页 > 网站架构 > 正文

京东交易平台架构核心

1 星2 星3 星4 星5 星 (暂无评分)
Loading ... Loading ...
baidu_share

infoq对京东交易平台架构师李尊敬进行了采访,讨论交易平台如何面对一年更胜一年的大促流量和阐述为此深耕多年的架构核心。

InfoQ:您在大流量高并发系统性能瓶颈诊断方面有丰富的经验,能否简单谈谈一般系统内部存在几种瓶颈,哪种瓶颈是“木桶短板”?能否举例阐述判断系统瓶颈的过程?

我接触过的系统中瓶颈点大致有以下几类:

1.CPU瓶颈:序列化和反序列化、高频日志输出、大量反射的应用是CPU飙高的主要原因。

2.网络带宽瓶颈:在大流量高并发系统中,网络带宽也会成为瓶颈点,交易平台这边解决带宽瓶颈的方式主要有压缩输入输出内容、使用双网卡和升级万兆网卡等方式。

3.磁盘IO瓶颈:App中的磁盘IO飙升主要是高频和大量日志输出导致的,可以通过增加日志缓冲区、精简日志来优化。数据库类IO瓶颈主要是通过优化查询、使用Fusion-IO、水平Sharding 分库分表等方式优化。

4.数据库连接数瓶颈:随着流量的暴增,应用服务器也在不断增加,这时数据库、Redis等连接数就会出现瓶颈,导致前端应用拿不到连接数。

木桶短板:CPU、网络、磁盘IO瓶颈通常都可以通过单纯增加资源、升级设备解决,但是数据库连接数容易形成木桶的短板。目前我们主要通过服务隔离和解耦、数据库垂直拆分、分布式数据库集群来解决连接数问题。

目前我们是通过全链路压力+全链路监控来实现快速发现系统瓶颈的,全监控链路实现对各层应用瓶颈点监控。

InfoQ:京东交易系统历经多次重构和改造,能否举例说明每次重构是如何突破上次重构的瓶颈的?能否分享重构中过程中的经验与教训?

2014完成独立秒杀系统,将秒杀和交易主流程彻底解耦,解决了秒杀影响交易主流程的问题;2015开始诺亚方舟计划和多中心交易项目,分别实现了突发流量下系统弹性扩容和交易系统同城多活。

多中心交易项目核心功能需要实现MySQL数据库、Redis的多机房写的问题。在解决多写的问题上我们关注了开源社区的实现,例如Linkedin的Databus、阿里的Otter,在这些基础上自主实现了适合京东交易系统的组件。

架构升级改造经验和教训:架构升级最大的风险是业务风险,通常单纯的架构升级是不改变原有业务流程的,但是架构升级势必涉及到代码变更,因此架构升级后的系统功能性测试非常重要。交易平台多个系统架构升级采用基于用户流量比对测试方法,完成系统升级安全切换。

InfoQ:能否谈谈你们订单中间件系统去IOE的影响,为什么要去IOE,目前使用了什么技术代替,效果如何?

订单中间件系统是订单生产环节核心系统,早期存储用的Oracle,随着订单量的突飞猛进,Oracle数据库连接数和IO出现明显瓶颈。

我们去IOE的方式是将Oracle等商业存储设备换成MySQL集群方式。去IOE在架构上最大的工作量是SQL转换,Oracle和MySQL的SQL语法有差异,而且Oracle单机性能远好用单台MySQL,之前在Oracle跑的很好的SQL到MySQL会很慢。解决这个问题的方法是优化和拆分SQL,将压力分摊到客户端。

大量变更SQL业务风险很大,因此需要全方位的功能和性能测试。在这个项目中我们首次尝试将用户流量完整copy到升级后的集群,将订单生命周期全过程回放到新集群,然后通过比对新老集群响应结果进行性能和功能测试,很大程度上缩减了去IOE工作量。

目前交易核心业务都实现去IOE,立足点是满足业务的需求,同时节约成本,发挥最大的效率。这也是京东一直保持业务与技术双向驱动的态度:业务发展推动企业规模,进而规模的扩展推动技术成长;另一方面,技术创新的成果能够更有效地保证业务发展,甚至引领业务的发展,这一直是京东所遵从的原则。

InfoQ:去年”618″当天访问峰值达到了什么级别,同时当天暴露了哪些架构短板?在平时的大促中如何保证数据一致性?大促当天性能如何在原来基础上再度提升?

去年”618″当天京东商城的订单量突破1500万单,实时价格、商品等核心接口峰值调用量达到上千万/分钟。去年”618″按照10倍流量标准备战,经过多次军演和预案演练,当天系统表现稳定。订单交易系统对数据一致性要求极高,像订单号、下单核心系统都是采用不带缓存的无状态化架构设计,采用水平扩展的方式对抗线上的流量。

对于订单中心等应用采用最终一致性原则来保障数据一致性。大促当天主要工作就是预案的执行,通过执行清洗恶意流量、分流和限流预案,降低系统负载,保障整个交易系统的高可用。

InfoQ:什么是无状态化的架构设计?与一般的架构设计有什么区别和优势,实现上有什么挑战?

无状态化架构设计是指各服务之间完全独立,地位均等,不存在状态化数据交互和同步。无状态化最典型的例子就是WEB服务器。

无状态化的架构优点:天然高可用,可以水平扩展,底层依赖的数据不需要相互同步,无状态的架构是系统高扩展性的基石。交易平台订单号服务,接单服务等都是采用无状态化架构设计。

以接单服务集群为例,各个接单服务独立运行,数据完全独立,一台服务或者数据库宕机后会从服务中自动下掉,整个服务保持高可用。

无状态具体实现上的挑战是需要根据业务将系统拆解成底层数据相互独立的单元。要求SOA化的时候服务的力度要足够细,另外在有些场景下服务必须是有状态的,因此并不是所有系统都可以做到无状态。

InfoQ:你们预测”618″当天会给你们带来哪些方面的挑战?能否介绍你们预先准备的解决方案?是否存在可用的“四两拨千斤”技巧?

今年”618″交易系统面临的挑战有以下两点:

1.成倍增长的访问量对交易系统的挑战
交易平台核心交易系统按照20倍日常流量的规模来备战,通过全链路压测模拟在20倍流量的压力下系统的表现,事先找出系统薄弱点,提前做好系统的优化和扩容准备工作。对来自非正常用户的恶意流量将建立风险分级策略。

2.弹性云
今年”618″交易系统首次全面接入弹性云,为了保障交易系统在弹性云环境下安全稳定运行,我们在弹性云环境做了多轮全面压力测试,对于较难实现的部分通过写流量压测、采用憋单演练的泄洪的方式,用真实的用户订单来考验弹性云下的订单交易系统。

对应大促期间的洪峰访问,有几个基本技巧:

1.分流,将核心系统和非核心系统流量分离,按照用户访问特征分流。
2.限流,按照用户安全等级分级限流,清洗恶意流量。
3.异步化,非交易核心功能尽量异步化处理,削弱访问量峰值。

本文固定链接: http://www.chepoo.com/jingdong-trading-platform-architecture-core.html | IT技术精华网

京东交易平台架构核心:等您坐沙发呢!

发表评论