数千个数据库、遍布全国的物理机，京东物流全量上云实录 | 卓越技术团队访谈录

数千个数据库、遍布全国的物理机，京东物流全量上云实录 | 卓越技术团队访谈录

采访嘉宾 | 章华、马琪、张成远、陈春辉

2017 年 2 月，时任京东 CEO 的刘强东公布了未来 12 年的战略：技术转型。当年的演讲里，刘强东首先提到的就是云计算，其次是大数据、人工智能和基因技术。从电商到技术提供商，京东不乏勇气和底气。财报显示，自进入技术战略升级以来，京东体系已在技术上累计投入近 750 亿元。

云计算作为京东技术战略里的重要部分，如今已经独当一面。4 年多的时间，京东云已经为 1500 多家大型企业、152 万家中小微企业提供技术服务。那么，如今京东的云计算实力究竟如何呢？

京东云演进历程：大促和云计算相辅相成

“像十年前或五年前，大家进入云计算领域的时候都是从基础设施开始各自发展，沿着相同的环境，只是选择了不同的成长路径而已。”

自 2006 年提出到现在，云计算已成为世界顶尖互联网公司必争之地。凭借着出色的云计算业务，亚马逊成为全球市值最大的电商公司。而在中国的土壤上，云计算的发展同样跟重度使用 IT 基础设施的“电商业务”休戚相关。

2008 年到 2012 年，是中国本地云计算发展的起始阶段，也是中国电商发展的黄金时期，京东商城的日交易量每年指数级增长：从日均 5000 单，到日均 10 万单，再到日均 50 万。2011 年，瞬间流量峰值已经突破每秒 10 万单。在购物节以及大型促销活动中，电商平台比拼的是后台系统以及相应的 IT 资源是否能快速扩充以应对流量洪峰。

此时的京东系统采用的是集中式的架构，短期内无法进行服务资源补充。2011 年，京东因为一场图书大促活动太过火爆而发生服务器宕机的现象。在这场活动的最后半小时，购物车和下单页面要么打开迟缓要么根本打不开，导致许多用户无法下单。为此，业界传闻负责的研发同事还被公司领导请“喝茶”，京东也不得不在微博上向大家道歉。

业务压力为京东技术架构的云化转变带来契机。2012 年左右，IT 系统采用“分布式架构”进行了重塑，并将物理机转向虚拟化，可以弹性调节 IT 资源，然后进一步地转向了微服务架构。

过去十年，京东成长迅速。十年前京东有两千个员工，收入 40 亿人民币，发展到今年达到 37 万员工，收入达 7000 多亿，与业务发展相对应的是日益增加的基础设施需求。2014 年之后，京东对技术架构和集群建设进行整体评估、重新设计规划。此时 Docker 技术兴起，京东将应用从物理机迁移部署在 Docker 上，采用 OpenStack＋nova-docker 技术架构，用管理虚拟机的方式管理容器，发展形成京东第一代容器引擎平台 JDOS1.0。

京东主要的一些核心应用比如秒杀、配送员订单详情、全球购等都部署在 JDOS1.0 中，2015 年 618 大促前，京东运行的较大规模的 Docker 容器和 KVM 虚拟机集群，经受住了当年流量的考验。

基于复杂场景下的容器化实践，打造京东混合云

2015 年是整个京东技术发展的分水岭，京东一位技术研发负责人表示，在这之前京东的技术一直是服务于业务的发展，而在这之后京东的技术开始驱动业务的发展。

为更好地应对复杂业务场景，这一年，京东对技术做了一次架构调整，将技术部门从业务部门剥离出来，成为一个单独的技术大体系。因此京东的技术部门得到了前所未有的独立性，除了服务于商城业务的应用研发团队，包括云、大数据、AI 等技术研发团队第一次开始了自主的技术研发，也为后来京东技术的对外输出和技术转型奠定了基础。京东云的发展，就是在这之后进入了快车道。

JDOS1.0 中原本采用的是 Docker 容器技术，其调度方式较为单一，只能简单根据物理机剩余资源是否满足要求来进行筛选调度，在提升应用的性能和平台的使用率方面存在天花板，无法做更进一步提升。2016 年，当容器规模逐渐增长到十万、十五万时，京东围绕 Kubernetes，整合了 JDOS1.0 的存储、网络，打通了从源码到镜像，再到上线部署的 CI/CD 全流程（JDOS2.0）。从早期使用较多的 Oracle 和 SQL Server 产品，到全面去 Oracle、SQL Server，开始使用 MySQL 等开源及自研的数据库产品，京东云数据库在 2016 年开始对外提供服务，目前共开放十余款云数据库产品。

容器技术是所有平台服务的基石，京东是容器化最彻底的公司之一。这些对内部基础设施进行容器化、资源池化，以及一些基于开源的中间件体系打造，形成了京东私有云基础，结合 2015 年规划好的公有云平台一起构成京东混合云，于次年正式对外开放。

2017 年京东又利用 Kubernetes 技术来重构相关技术栈，全面对技术进行升级，并将数据库、大数据等业务通过 Kubernetes 部署，在容器化基础上打造了“阿基米德”调度系统，这也是业界比较早的基于 Kubernetes 的混合云统一调度系统。

集团核心业务也逐渐往云上迁移，历经了几年 618、11.11 大促，混合云 PaaS 平台逐渐被锤炼成熟。服务器的算力也能被最大程度化利用，2019 年利用原有基础设施全年没有再采购物理服务器，一举节省 IT 成本数十亿元。

降低复杂度，打造云舰平台

据京东的老员工回忆，京东早期系统很小很简单，只有交易网站、供应链管理系统和一套财务系统这三个系统，那时候做促销活动非常简单：“早晨开早会的时候谈当天做个什么活动，比如抽奖、转盘，聊完了研发去做开发，开发到下午 4、5 点钟，测试看看行不行，到晚上 7、8 点上线就好了。”

发展到现在，京东云底层基础设施相关系统已经变得庞大而复杂，仅以大促为例，在全球，有 3 家云厂商，4 大区域，近 50 个大型数据中心，近 60 朵城市云，77 个离线数据中心，支持数十万智能设备，服务近 5 亿用户，这意味着公有云环境、私有云环境，也有边缘节点、机房服务器并存，甚至还有跑在路上的终端、配送车，这些大规模混合 IT 设施支撑着京东每次大促活动。所以如今做促销活动，难度大了很多，而且像 618 这样的活动资源需要迅速地扩充到平时的 135%。京东云于 2020 年开始做了大量优化，自研了混合云操作系统“云舰”，通过云舰对上提供一个统一的接口来调度 IT 基础设施，屏蔽掉了底层复杂性，同时对外界用户更为友好。

这个混合云操作系统，可以同时调度超 1 千万核的系统资源，在线管理 Pod 数超 200 万，承载最复杂场景的云原生实践。京东科技京东云事业群技术总监，数据库研发部门负责人张成远解释道：“对用户来说，云舰屏蔽掉了下面所有的 IaaS 基础设施，几十核就可以把整个云舰操作系统安装起来，数据库、中间件等所有服务可以像软件插件一样使用，按需安装。”

京东“护城河”业务物流的上云路

京东物流是京东集团的核心资产。从 14 年前刘强东力排众议成立物流部门到今年独立上市，京东物流已经成为京东的一道重要“护城河”。数据显示，2018 年到 2020 年，京东物流营收分别为 379 亿、498 亿、734 亿，特别是 2020 年，营收实现了 43.2% 的爆发式增长。

2018 年，京东开始规划混合云服务。2019 年左右，上云成为整个京东的重要技术战略，这里主要指从私有云转向公有云。京东物流作为重要的事业群，同时拥有相对丰富的场景，上云技术和经验可以反哺整个集团。在公司政策和自身需要的双重驱动下，物流上云成为京东上云战略里的重要一环。

物流上云是一次多部门合作的过程。物流部门把握整个业务上云的节奏，京东云按需求提供云基础设施，两个部门大约半个月做一次进度沟通。

在新设计的物流云基础架构中，之前高度耦合的 Docker、JinDB、ES（Elasticsearch）和 DB（数据库）等通过 VPC 分别放到对公子网、业务子网和数据子网中。因此，上云首先就要解决网络问题。

物流并非纯粹的互联网，其基础设施拓扑结构的复杂性远远大于现在的头部互联网公司。京东物流系统管理着全国大约 1300 个仓库，跟实物流转密切相关，因此有很多系统运行在全国各区域的本地物理机上。不同的 VPC 子网要对应分布在不同的物理机房（AZ）。京东云需要制定具体的网络规划、完全隔离的 VPC 环境和细化不同业务的网络配置等。

上云会使物流从重型资产向轻资产化转变，因此团队部署了 CMDB 来做混合云资产管理，并同步计费信息。为保证整个上云过程可控，团队进行了资源监控和性能监控等。此外，团队还研发了很多自助运维工具和数据同步平台“数据蜂巢”等适应云架构，同时沿用一些传统工具，如 J-one 和 UDBA 等减少研发人员学习成本。

云上迁移：“卡”在了对人的依赖

“迁移之前心里是没底的，因为每个业务系统完全不一样，会遇到什么困难也完全预测不到。”

上云是个大工程，尤其物流系统业务极其复杂，模块之间互相依赖，涉及百万核级别的业务应用、数据库及中间件等需要向云上迁移。“运营过程中，涉及的每一笔订单、每一次交易、每一笔支付、每一个包裹都不能出错，这是非常大的技术挑战，可以说整个物流上云的过程无异于给一架高速飞行的飞机更换引擎。”张成远说。

做好准备后，京东物流没有立即全部上云，而是先对非核心业务做小规模迁移，来验证了各种组件的可用性、继续完善迁移工具。这个“实验”阶段持续了大半年的时间，之后物流系统才迎来了大规模上云。

上云方式基本可以两类：对原系统进行云改造和直接重构。对于物流系统来说，云改造的占比更多。

京东物流技术发展部工程效能组负责人马琪提到，需要改造的系统，有些成本还是比较高的，“说到底，目前业界流行所谓的云原生的概念，但物流有些业务当初打造的时候，并没有考虑未来要跑在云上。”

这在物流系统中体现尤为明显。相对于普通的、只有一两个机房的互联网企业，物流企业的基础设施是本地化的，因为京东在全国的上千个物流仓库，有很多本地化数据库：京东的系统从早期开始就部署在这些对当时来说功能极为强大的物理机上。举个极端情况下的例子，比如某些数据库的规格对物理机的性能要求很高，但到云时代，是可以拆分并分散到不同云主机上的。“千万不要把云上的机器想象成它就是一个物理机”，马琪强调道，这些系统要迁移到云上，面临的改变是巨大的。

经过架构梳理后，京东将需要迁移的服务分为了两种：有状态和无状态的。比如 Docker 服务的部署，那么可以当作无状态服务处理，部署后可以做大量的验证，类似平时的上线验证，通过灰度测试等查看各项指标没有异常即可，这是最简单的。而对于有状态服务，如数据库、Redis、ES 等，得把整个状态迁移上去，就变得复杂了，需要花费较多的精力和成本。

对于物理机到 Docker 容器的迁移，每个团队可以自己做压测、计算前后承载 QPS 的差异，逐步替换对系统影响不大，可维持系统的高可用和稳定性。

中间件层迁移是团队面临的比较大的技术挑战。一方面是公有云产品会有非常标准的 Open API，而之前内部的一些产品基本只考虑业务需求就可以。另一方面是，各种中间件的版本不一样，包括云和本地之间。

其中，遇到的一个比较难的技术点是 Redis 的迁移。有些团队使用的是零售业务的缓存中间件，和公有云的缓存中间件本质差异很大，京东内部 JimDB 分布式缓存产品与跟云上分布式 Redis 产品的协议有区别，前者更加私有化和定制化的性质，对公有云产品而言并不友好。因此，在迁移到公有云 Redis 集群过程中，物流、公有云和 Redis 开发团队都面临着这个差异带来的考验。最终经过几轮商讨，团队研发出了兼容 Jimdb 集群和公有云 Redis 集群的 SDK，在只需修改依赖、URL 等的情况下就可以实现无缝迁移。

整个迁移过程中，“瓶颈”落在了数据库团队上，毕竟比起 Redis 缓存里的数据量，动辄几百 G 或上 T 的数据迁移会复杂很多。

京东大约在 2014 年开始去 SQL Server 和 Oracle，上云之前已经大部分业务在用 MySQL。而物流系统中的本地数据库，虽然大部分是 MySQL，但跟云上的还存在版本号不一样，或一些特性没开启的情况。在公有云 MySQL 版本更高的情况下，跨版本迁移导致新场景下的 RDS 集群无法直接挂为从库。

另外，在低版本直接升级到高版本时，可能会有一些问题发生，比如变量的数据类型发生变化从而导致 Time stamp 精度发生变化。这些都需要 DBA 来协助解决，同时 DBA 也负责了很多部署、监控、备份之类的工作。

迁移上千个物流仓库中的本地数据库，起初，这项工作大量依赖 DBA 团队。当时物流的 DBA 团队只有七、八个人，在紧张的日常任务之外再承担了几千套数据库的迁移工作，项目四处冒烟，几乎需要 24 小时 oncall，团队很快便力不从心，也严重影响了整个上云进度。

京东物流技术发展部首席架构师章华回忆说：“之前更多考虑的是系统架构以及团队的技术能力能不能适应由上云带来的新的运维方式，但确实没预料到 DBA 的人力会成为瓶颈，而且临时也招不到足够多的人。”因此，DBA 团队只能暂停工作去研发自动化工具，来代替人力去做迁移、验证等重复性工作。最后，通过一些 DBA 等工具，将数据复制到 RDS 集群，然后找时间窗口做域名切换。

比起基础设施的迁移，应用实例的迁移相对容易很多，可同时将应用流量打到私有云和公有云的分组上，运行稳定后就可以去掉私有云分组了。

京东也根据不同的物流业务将系统分成了三个等级：零级系统、一级系统和二级系统，这三个等级的系统对业务的影响力依次减弱。影响下单的属于零级系统，而类似一天只跑一次的统计分析任务属于级别低的系统。迁移时，一般会先从对业务影响最低的二级系统开始，之后才是一级系统和零级系统，针对业务划分系统边界，并分步骤实施，还要考虑应用迁移如果出问题是否能够回滚。零级系统还需要有对比测试，灰度切换，会有三天到一个月不等的双活阶段，在验证新架构没有问题后，旧架构才被下掉。马琪建议，迁移到云上后，研发人员要做足够的测试。

物流是云资源使用方，而作为供给方，京东科技技术交付部架构师陈春辉从四个方面总结了迁移时公有云相关部门需要对应做的工作：

第一是提供高可用，保证不同仓储系统的物理机房（AZ）就近接入华东、华南等不同 region 的公有云的机房，从机房层面保证 Docker、数据库、中间件等系统的高可用；第二是保证高性能，保证机器的利用率，比如 CPU 不低于 40-50% 的阈值，让机器、容器、数据库等最大性能地发挥作用；第三是保障高安全，结合 VPC 子网，做 ACL 安全策略、数据库审计以及 WAF、DDOS 防护，保证业务高安全；第四是提供高运维能力，利用云资源提升物流侧运维能力，按部门进行资源使用量的核算以及提供精细化计费。

物流上云，不只于千万级别的成本节约

经过团队两年左右的努力，物流成为京东首个实现全面上云的部门。目前京东物流订单平台等核心业务系统已稳定运行在京东云上，云上日处理订单量达千万级。“全部上云”的标准是什么呢？物流团队也对这个问题思考了很久。最后，团队得出的结论是：以应用为标准，看其依赖的 Redis、数据库和 ES 等资源是否全部上云，如果这些资源全部上云就是应用完全上云。这项标准如今也成为京东上云的标准。

上云带给物流部门最大的改变就是再也不用在基础设施上花费过多精力。

物流系统相对普通互联网企业拥有更多的本地机房，这意味着物流系统的资源使用弹性很小，为 618 大促等购买的物理机在平时用不到造成了很大的浪费，而随着业务发展，物流部门需要的物理机和计算资源只会越来越多，资源浪费也会越来越大。同时，物流部门还需要人力统计数据，花很多精力去维护众多小机房的稳定。

上云之前，物流部门的大部分基础设施是用零售部门的，自己的基础设施相对来说成熟度不高，一些维护工作也是零售团队在做。物流团队要花费很多精力在保证资源充足上。

上云之后，物流部门可使用资源的弹性大幅增加，资源利用率也得到很大提升，这给部门带来了千万级别成本的节省。自动化计费方式也给了研发团队更直观的成本观念。

在马琪看来，上云不是将物理机搬到云上，而是将整个系统和应用打造成适合云的状态，这样才能从上云中获得最大的效益。“如果企业有能力、有资源，上云越快越好。”

物流上云后的第一次大促

今年京东 6·18 大促是物流上云后第一次接受流量洪峰的挑战。“不抗一次大促，心里没底。”章华说道。

京东 618 可以称之为全球最复杂的业务场景之一，涵盖了从零售、物流、金融、健康多个业务形态。每年大促前，京东各个 BG/BU 里的重要负责人会组成备战委员会，重点工作就是保证流量激增情况下系统的稳定。

近两年，物流团队引入了全链路压测，对用户下单到所有参与系统完成任务的整个过程进行流量测试。其中“订单到供应链系统，再下传到物流系统，物流系统又下传到具体库房”的过程，是整个链路的核心，也是改造的重点。压测结果也是京东云做容量规划的重要依据。

一年前，物流团队开发了“捣乱演练”的工具，对各个系统进行梳理，找出薄弱点和高可用的地方，查漏补缺，进一步加强系统的健壮性。

当前京东有百万个微服务化应用，故障排查比较有挑战性。京东根据多年积累的各种故障经验模型化，研发了一套故障分析系统进行自动化筛查。原来多部门联合 20～30 分钟完成的故障定位，一两分钟内即可完成。

异地多活的架构也保证了服务的稳定。一旦某个节点出现问题，流量就会被切到其他节点，整个服务不会受影响。

京东物流系统在大促期间也有一定的性能指标。比如 CPU 如果低于 50% 会被判定非高性能，存在负载量不大等问题。

稳定性的坚强后盾就是充足的资源。今年京东 618 相对平时资源扩充了 135%。上云后，大促“日常化”成为可能，技术团队不必为此消耗过多的精力。

之前京东云评估资源量是以年为单位，但现在是按季度来评测，甚至在供应链方面可以细化到月或周，分批次使用不会造成资源过多积压。在满足日常需求外，云上的资源池一般也会留有剩余，应对大促流量超出预算或其他紧急情况。

京东的单 VPC 内地址规模超过 50 万，有超过百 G 节点网络的大规模网管集群，承载 TB 级专线流量。管理超过 1 千万核资源的云舰支持了大促期间系统快速扩充的需求。另外，云舰的 IT 基础设施调度能力，让物流、零售、健康等系统在统一的调度平台运行，使整体系统拥有了很好的弹性。数据显示，618 期间，京东整个系统资源的利用率提升了 3 倍，单位订单成本下降了 30%。

京东云备战 11.11

今年双十一的特殊挑战

堆资源、保稳定是大促常规保障活动，而今年的双十一有些特殊。

进入 10 月以来，全国多地发布了“有序用电”的通知，各家电商的 IDC 都面临着被拉闸限电的风险。对于京东物流来说，分拣中心分布在全国各地，每个分拣中心都有本地设备，如果某地停电，如何在短时间内恢复运营对其也是一个很大的考验。

为预防万一，京东云做了很多保障工作，保证断电后的 IDC 有备用电源。对于应用层，核心系统都做了双机房部署，一个机房断电后另外一个机房能扛住流量继续运行。

另外，今年京东双十一将时间从零点提前到了晚上 20 点，这种脉冲式流量洪峰也给系统带来严峻挑战。基于混合云操作系统云舰及离在线混部技术，京东云灵活跨平台分配与调度资源，削峰填谷，实现资源错峰与平衡，平稳应对晚 8 点形成的脉冲式流量洪峰。

“并不存在所谓大招或者秘籍，只要把具体的小事做好，大促就能稳定。但如何让整个过程更高效、时间更短才是挑战。”章华说道。为此，除升级基础设施外，流程化、标准化、工具化也是非常重要的。尤其是把大促备战的事情日常化，会更加的重要。

写在最后

“上云是一个趋势。十年前问要不要上云可能还值得讨论，而今天不应该再讨论这个问题了，云是一定要上的。”章华说道。

根据信通院统计数据，2020 年，我国云计算整体市场规模达 2091 亿元，增速 56.6%。其中，公有云市场规模达 1277 亿元，相比 2019 年增长 85.2%。随着云计算在企业数字化转型过程中扮演越来越重要的角色，预计短期内企业将继续加大基础设施投入。这对要走向产业的京东云来说无疑是很大的机会。

就像京东员工说的，“京东内部这些年一直在喊技术、技术、技术，确实感觉到了不少变化。”京东比以前更加注重流程化、工具化、云化，在这样的形势推动下，京东云的打造只用了五年，但京东云的故事远远没有结束，未来要走的路也还很长。

采访嘉宾：

章华，京东物流技术发展部首席架构师，曾负责多个公司级重大项目，包括物流上云、京东 618、11.11 备战等。

马琪， 京东物流技术发展部中台技术部工程效能组的负责人，负责物流计算资源的管理与运维。2021 年，通过技术手段推动物流计算资源整体利用率的提高，为物流带来千万级的成本节省。

张成远，京东科技京东云事业群技术总监，数据库研发部门负责人，带领团队实现京东云数据库产品线从 0 到 1、从 1 到 N 的建设，并承接集团上云工作，负责组织协调各部门各团队间上云工作的推进落实。

陈春辉，京东科技技术交付部架构师，我们团队负责集团物流和零售业务上云工作，在上云过程中提供技术支持和架构优化服务，在 618、11.11 等重大活动前对集团上云客户配合梳理架构提高客户业务稳定性，在大促期间提供重保服务。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。