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

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

过去十年，京东成长迅速。十年前京东有两千个员工，收入 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 基础设施，几十核就可以把整个云舰操作系统安装起来，数据库、中间件等所有服务可以像软件插件一样使用，按需安装。”

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 集群，然后找时间窗口做域名切换。

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

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

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

●  第四是提供高运维能力，利用云资源提升物流侧运维能力，按部门进行资源使用量的核算以及提供精细化计费。

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

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

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

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

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

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

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