京东云靠什么撑起618大促？

作者 万佳

今年的618前夕，何小锋显然没有以前那么紧张，人更放松，说话也更淡定。一方面，作为京东科技京东云云原生平台负责人，他已经参加过19次大促备战，积累了丰富的经验；另一方面，从2014年使用Docker到2018年建成全球最大规模Kubernetes （以下简称K8s）集群再到全面拥抱云原生，京东在容器和云原生领域有着多年的技术实践与经验积累。这些无疑给了他十足的信心！

根据最新消息，6月18日凌晨，京东云发布618当天首份战报，在从容应对高并发数亿级流量洪峰的同时创下多项纪录。数据显示，京东云以超高弹性应对海量并发需求，其中，每秒用户访问峰值较去年同期提升152%。在此次京东618期间，京东云混合云操作系统——云舰（JDOS）在线管理POD数量超过200万，运行容器峰值核数超过1000万个，保证了有限计算资源在不同任务间的无缝切换，护航用户流畅的购物体验。

何小锋是软件行业的老兵。从1998年毕业至今，他从事软件研发工作已有22年。回顾京东云云原生多年历程，他最大的感触是“每年都在快速迭代，当时感受不深，但近十年的快速积累，我们已经走在行业前面”。

2011年，他加入京东，在公司的基础架构团队负责Paa S平台建设。那时，京东的业务正处于高速发展期，但是却面临严峻的技术挑战：京东当时有很多单体应用（单体应用系统性能差，吞吐量小，且扩展性差），无法支撑高速发展的业务。

为解决问题，技术团队开始进行架构调整，采用分布式架构，把原来的单体应用拆成微服务。相比单体架构，分布式架构不仅可以增大系统容量，提升系统性能，而且能消除单点故障，提高整个系统架构的可用性。简言之，分布式架构可以很好地应对京东越来越大的业务量。

改造初期，京东采用开源技术，何小锋表示，“先用现有的开源项目试试能不能有效支撑系统。采用（开源项目）后，我们发现（系统性能）确实有所提升”。

但好景不长，新问题又来了。随着业务的进一步发展，更大的流量进来，现有系统又遭遇挑战，“从技术角度，你很难进行改造。即使要改造，所需的工作量跟重写差不多”。为此，他们走上自研之路，开始自主研发微服务框架、高性能消息中间件等。不过，自研挑战不小，因为业界相关的开源项目很少，缺乏参考。

事实证明，自研虽然很难，但却是一件正确的事情。在使用自研产品后，系统吞吐量得到明显提升，“可以扛住更大的流量，新系统具备水平弹性扩容，一旦业务的量上来，我们就增加机器资源，让前端自动知晓后端服务，极大提升吞吐量，很好的支持起业务”。

Docker技术的早期采用者

2014年注定是一个神奇的年份。这一年，先是Docker发布1.0版本，然后谷歌宣告K8s项目的诞生。此后，容器和云原生领域，K8s “一统江湖”，成为容器编排领域的事实标准。

这一年对京东来说很重要，因为它开始走上容器和云原生之路。

据何小锋介绍，京东在2014年前主要用物理机，使用虚拟化技术，但是问题在于其性能无法满足业务需求。以应用上线为例，“如果要上线应用，需要先申请几台物理机。一旦申请成功，就能上线应用，使用这几台物理机资源，但是实际上，这几台物理机空闲资源很多”。

如何进一步提高资源利用率，这是摆在何小锋他们面前的重要问题。

为解决这个问题，他们希望使用一些新技术提高资源利用率。在经过技术评估后，“我们发现Docker与Linux进程的技术差不多（容器其实是一种特殊的进程）”。于是，他们开始使用Docker技术。“最初，我们不敢在下单、交易等核心业务上使用Docker技术，我们团队有一个图片系统，业务流量也较大，另一方面，技术团队对它很有把控”，所以图片业务成为京东使用Docker技术的试点。

作为Docker技术的早期采用者，何小锋表示，他们在2014年使用Docker技术时面临不小的挑战。

第一，最初使用Docker技术时，它缺乏一个很好的调度系统。鉴于京东在Open Stack上有丰富的经验，所以他们当时对OpenStack进行改造，让它直接调度Docker。但是，Open Stack有两个问题，一是Open Stack在调度过程中出现一些问题；二是Open Stack基于KVM虚拟化技术，整个平台的延伸能力比K8s差。相比之下，后起之秀K8s“更轻量级，设计更合理，并且符合未来技术的发展方向”。

第二，Docker刚出来时，他们也在逐步摸索，“镜像怎样做得更好，针对镜像分层，摸索怎样分层会更好，让镜像尺寸更小，更方便分发”。

第三，在调度上，他们考虑怎样可以更好地调度。“我们希望使用容器，提升资源利用率，（让系统）具备一些弹性、伸缩的能力，从而支持水平扩容和垂直扩容”。

此外，为了解决容器使用过程中伴随的运维问题，京东打造了一整套运维系统。在应用上，他们做了监控和报警，涵盖主机、容器、APM；其次，打造CI/CD、Dev Ops的综合能力，让研发人员既能做研发，又可以做运维，大大降低对运维人员的压力。

从2015年开始，京东的其他业务逐渐用上Docker技术。当年的618，京东启用了基于Docker技术的容器技术来承载大促的关键业务，包括图片展现、单品页、团购页等。

2016年，再进一步，京东所有业务接入容器，容器实例达到10万左右。

全球最大规模K8s集群

2年后，即2018年，京东建成全球最大规模K8s集群，并基于K8s建成全球最复杂的分布式数据库——Vitess集群，京东容器规模达到几十万级。

为什么京东能建成这么大规模的K8s集群？这离不开技术团队所做的大量改造工作。据何小锋介绍，K8s的早期版本能力相对较弱，扩展性不足，用于生产环境需要做很多定制开发。

“对我们而言，网络、存储和调度能力都要改造、系统迁移等等，这些都是不小的挑战。”他说。

围绕K8s，他们对关键点进行了重点改造，包括调度、监控等。以调度为例，随着集群规模越来越大，调度成为瓶颈。“早期，它的调度算法需要遍历所有匹配节点才能选出一个合适节点，如果节点数过多，遍历的性能就很慢，调度性能满足不了大规模应用上线的需求”。于是，他们通过一些算法，无需遍历所有节点，就能快速创建容器。

为了进一步提升资源利用率，京东还在K8s基础上开发了阿基米德调度系统。这个系统会通过历史数据结合机器学习算法给应用打标签，“打完标签后的数据，形成了应用画像。在这个基础上，平台可以实现精细化调度”。

在监控层面。他们最开始主要是“定时去拉，一分钟拉一下容器节点的数据”。但是，后来随着业务量的增加，分钟级监控无法满足整个业务需求，尤其是秒杀业务，“非常快，它有没有出现问题，分钟级监控经常发现不了问题”，因此，他们需要秒级监控。

何小锋说，“到秒级监控时，原来的模式调度不过来。因为随着规模增长，公司有近100万容器。因此，我们要进行改造，把原来拉的模式改成推的模式，期望监控的粒度到一秒钟，数据采集后，直接推到后端。这样才能实现秒级监控。”

从资源角度看，K8s集群光有容器资源的监控，无法满足应用监控的需求，因此还要做APM应用监控，掌握应用在K8s集群中的性能情况。这样出现问题后，才能知道是应用问题，还是节点问题或容器问题。

但是这样还不够，网络也是一个关键。让何小锋记忆深刻的是，多年的618大促，网络问题一直是“令人头疼的问题”。因为618大促期间，一旦网络出现问题，很难进行定位，并快速找到问题根源。他称，“618大促，一旦各种流量上来后，整个网络环境其实挺复杂。这么多机器，不管是哪个节点，还是哪个交换机出现问题，都会对后端业务产生影响”。他们在2019年决心着手解决这个问题：搭建详细的网络监控能力，可以快速诊断出问题所在，比如交换机故障或网络丢包等。

他说：“最后，我们实现全链路监控，一旦出现问题，就能快速定位问题源头。”

回顾京东的K8s实践，在何小锋看来，他们选择了一个正确的方向，“无论是容器，还是K8s，我们很早采用了云原生。我们觉得这是未来的发展，并且业界也在往这个方向发展”。

多年的容器实践真正给京东带来了好处。一方面，大幅提升了交付效率。“围绕云原生，我们打造了一整套Dev Ops体系，包括监控、日志、CI/CD，真正让研发人员做了运维人员，提高了响应速度，优化了线上发布流程，提升了效率”。另一方面，通过充分的资源调度，大幅提升了资源利用率，降低了公司成本。

1年节省IT成本数十亿元

据何小锋介绍，容器和云原生的应用在2019年为京东节省了IT成本数十亿元。他说：“业务向前发展，流量不断增加，但现在却没有新增资源指标，因此只能充分利用现有资源，扛住公司流量型业务。”

为了充分利用公司资源，他们主要从三方面着手。

应用画像

首先，他们通过阿基米德调度系统，掌握应用的画像，“它是CPU型，还是内存型。基于大量的应用历史数据进行数据训练得到”。对应用完成画像后，会盘点现存的应用的资源申请。

他说：“以前，大家经常申请资源，但不清楚该申请多少资源。为保险起见，一般会多申请资源，比如申请8核资源，但根据后来的数据分析，我们发现它只需要4核。”这样，多余的资源就能被释放出来。基于应用画像，了解应用的历史负载情况，进而判断应用目前的资源使用情况。“如果发现这个应用申请的资源过多，我们就会把资源降下来，空出来的资源就可以补充到压力更大的应用上”。

解决碎片化问题

其次，解决调度过程中产生的大量碎片问题。何小锋解释，假如一台机器是64核，256G内存，如果它上面跑很多大内存应用，消耗了很多内存，剩下10核CPU，但内存只剩下4个G，10核的CPU分不出去就会产生碎片。

因此，他们要对这些碎片进行梳理。有了应用画像后，再进行一些腾挪。举个例子，有三个都装了一些水的杯子，但是都不满，现在要拿走一个杯子，这怎么办？解决办法是把三个杯子的水全倒在两个杯子，这样就空出了一个杯子，相当于碎片化处理。

在线业务与离线业务的资源复用

此外，他们还在尝试在线业务和离线业务的结合。充分把在线业务和离线业务的资源复用起来。因为以前在京东，在线业务的资源和离线资源的业务是分别申请的，双方的资源不能互相利用，通过迁移实时计算作业到在线业务集群，分时调度部分批处理作业到业务集群，把资源充分利用起来。

“基于阿基米德调度和应用画像的数据，我们提高调度能力，从而提升利用率，满足当年的资源需求”。

全面拥抱云原生的京东

如今，云原生越来越火，已经成为云计算的未来发展方向。

在何小锋看来，云原生落地要有两大支撑：

· 一是技术上要有一个云原生平台，“项目要真正落地，要有很好的企业化平台，帮助大家把这些东西整合在一起，提供一些企业化的能力”。

· 二是团队要拥抱云原生，拥抱新技术，更好地推动项目落地。“习惯传统技术的团队如果立即拥抱云原生，可能会出现抵触情绪，即使有了团队，还必须有创新精神”。

他指出，云原生落地面临的第一件事是“它对现有系统会产生怎样的冲击”。因为如果对现有系统进行改造，会采用云原生技术，更强调容器，使用微服务架构。

从2014年到现在京东全面拥抱云原生，“我们通过实践证明了云原生确实是云计算未来的发展方向”，并且，云原生给京东带来很多便利，包括提升效率、降低成本等。

当前，京东在云原生领域做一些新尝试，打造混合多云产品——混合云操作系统云舰（JDOS）。他说：“我们想打造一个对内对外一致的技术栈。它是多云一致，可以屏蔽底层的异构基础设施，让这个平台跑在任意的云上，包括公有云、私有云。我们想建立一个Paa S生态，基于京东实践过的Paa S进行改造，放在这个平台里，全部进行云原生化。云原生化后可以快速地向客户进行输出。”

他也强调，会引进一些合作伙伴，一起打造Paa S生态，再结合内部Dev Ops能力，打造混合多云平台。

写在最后

从启用Docker到全面拥抱云原生，京东云多年的技术实践不仅夯实了自己的技术底座，沉淀了越来越多的技术能力，而且多次护航618大促，成为京东618的技术基石。