电商大促特辑： 揭秘京东历经多年的"618"架构核心

"618"作为京东一年最重要的大促之一，每年 6 月 18 日京东将遭遇记录历史级别的流量挑战。如何成功保障交易平台高并发高性能已经成为包括京东在内的众多电商念念不忘的念想，而京东作为国内电商领军企业之一，在架构积累上成就了如何领先的技术底蕴？

2016 年 7 月 15-16 日， ArchSummit 全球架构师峰会将在深圳举行。本届大会，我们邀请了京东商城交易平台架构师李尊敬，前来分享《京东交易系统618 保卫战》的内容，讲述的是京东数次架构升级的实践内容和期间遭遇了怎样的技术教训，以及更多地将讨论如何面对一年更胜一年的大促流量和阐述为此深耕多年的架构核心。

现在我们就来采访李尊敬老师，让我们看看京东给这个架构世界带来了怎样的惊喜吧？

受访嘉宾介绍：

李尊敬，京东商城交易平台架构师，负责京东商城购物车、结算页、订单中心等核心系统架构设计和重构工作。先后负责和参与过订单中间件系统去IOE、订单中心架构重构、多中心交易系统中订单交易系统设计和改造工作。对大流量高并发系统性能瓶颈诊断、架构重构和高可用方面有丰富的经验。

InfoQ： 能否简单介绍京东商城交易平台的业务，其中您的主要工作是什么？

李尊敬：交易平台为京东商城提供交易平台化的服务，涉及到购物车、结算页、订单中心、促销价格、商品、库存等一系列平台化的服务，PC、APP、微信手 Q 都依赖交易平台提供的服务。我主要负责订单交易相关环节的技术保障、架构升级和性能优化等工作。

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"与前几次大促相比在技术准备上存在哪些不同？如何通过数据预测今年"618"的情况以及承受压力？

李尊敬：每年"618"在春节后就会启动技术备战，通过完整的预案和演练来应对"618"的压力。架构层面我们准备的工作分成以下几点：

1. 交易相关系统架构梳理，风险点评估；
2. 系统机房部署情况核对，是否遵循流量闭环原则，有无跨机房调用情况存在；
3. 检查各系统和渠道服务器资源分配情况，资源利用率是否合理；
4. 交易核心流程调用链梳理，各渠道终端的用户整个请求链耗时情况分析。

今年"618"和去年大促技术上准备有很大的不同，本次"618"交易系统全面接入到弹性云 docker 平台，诺亚方舟机房全面启用。接入弹性云后系统扩容和缩容变得更加简单和便捷。

为了保障从物理机到弹性云安全切换，我们在弹性云环境做了大量压力测试，针对弹性云环境做了参数调优和性能优化工作。今年也会启用多中心交易二期项目，多机房热备，同时承担用户流量。

在预测方面，我们通过最近单量的分布情况，以及促销力度和数量，结合机器学习算法实现对"618"当天单量以及核心系统调用量和性能预测。

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

李尊敬： 今年"618"交易系统面临的挑战有以下两点：

1. 成倍增长的访问量对交易系统的挑战
   交易平台核心交易系统按照 20 倍日常流量的规模来备战，通过全链路压测模拟在 20 倍流量的压力下系统的表现，事先找出系统薄弱点，提前做好系统的优化和扩容准备工作。对来自非正常用户的恶意流量将建立风险分级策略。
2. 弹性云
   今年"618"交易系统首次全面接入弹性云，为了保障交易系统在弹性云环境下安全稳定运行，我们在弹性云环境做了多轮全面压力测试，对于较难实现的部分通过写流量压测、采用憋单演练的泄洪的方式，用真实的用户订单来考验弹性云下的订单交易系统。

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

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

InfoQ：2015 年 10 月上线的多中心交易系统成功通过了双 11 的考验，能否简单介绍多中心交易系统，它有怎样的优势，实现起来有什么难点？在这次"618"会承担怎样的角色？

李尊敬：多中心交易系统设计类似实体商超：多个交易中心按用户分流，每一个交易中心建在不同地区，用户直接访问本地区的交易中心。多中心交易系统不仅响应速度快，用户体验更好，并且每个中心服务一定数量的用户，用户则不用跨地域访问数据中心，水平扩展性好，进一步降低单个中心的数据压力。多中心交易系统能支撑更大的交易规模，可支持异地容灾，进而降低灾难的影响和风险，更加安全。

数据一致性是实现多中心交易系统最大的挑战，数据写错了无法恢复。其次要保障用户从进入京东商城到浏览商品，到访问数据库，该全链路的路由规则都是完全一致的。

今年多中心架构在性能、可视化等多方面进行了较大的改进，而今年多中心交易主要有三个目标：

1. 多数据中心支持交易流程；
2. 异地容灾，实现无缝切换；
3. 用户体验提升，保障就近访问和交易。

InfoQ：感谢李尊敬老师接受我们的采访。期待您在 ArchSummit 全球架构师峰会上的分享。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。