从 2014 年开始，InfoQ 就一直在追踪京东 618 相关的技术报道，在我们的系列文章中，你肯定也能察觉到京东在技术上的成长速度。5 年之前，每逢大促，我的朋友圈中好似有很多人在看笑话，因为在高并发大流量面前，那时的京东总是有些脆弱，特别是对于淘宝 / 天猫。

几年时间，一晃而过。这次 618，我刻意搜索了下自己的朋友圈，发现基本没有人再去吐槽京东『逢促必挂』的技术笑话了，转而大家都在夸赞京东的送货速度以及服务品质。是的，当用户的目光聚焦到一家公司的业务本身时，这也证明他的技术已经相对成熟，起码足以支撑业务的发展速度。也就是说，对于京东来说，技术已经不再是业务增长的瓶颈。

我现在还清晰记得自己在 2015 年 618 当天去京东总部采访京东商城总架构师刘海锋时的情景，他当时激情澎湃地向我介绍了京东基于 Docker 容器和 OpenStack 的弹性计算云项目的种种优势，并笑着说，再过几年，随着这个项目的成熟，京东的技术人员面对大促，再也不用这么辛苦，这么紧张了。

我应该也是被他的话所感动，亦或者作为一个外行，我似乎也能理解一个技术人应有的技术信仰。所以在当时的采访文章里，我写下了这样的话：京东弹性计算云项目将深刻影响京东未来几年的基础架构。

然而，一年之后的 2016 年京东 618，当再次采访弹性云项目负责人鲍永成时，我们才明白，弹性云对于京东的真正价值和意义。永成说，这一年是弹性云在京东全面战略落地的重要一年，它也将全面提升京东的基础设施利用效率。

紧接着的 2017 年，京东的业务，以及相关的中间件已经全部迁移到了弹性云之上，并且永成表示，他们开始了新的技术升级，将会引入 Google 开源的 Kubernetes 技术来重构相关技术栈，并且自己也会为开源添砖加瓦，回馈社区。

2018 年 4 月底，我看到了京东宣布加入 CNCF 云原生计算基金会的消息。这时，我才明白，京东的 Kubernetes 集群已经是全球最大了，并且没有之一。

感慨之余，我又翻出了过去几年 InfoQ 对京东 618 的特别报道，当我站在历史的角度去审视这些采访时，我也才真正理解媒体记录的价值。我想，若干年后在去看这一系列的技术升级，你只要看这几年 InfoQ 的文章标题就足以理解变化的关键点。

• \\t

  2015 年京东 618：Docker 扛大旗，弹性伸缩成重点

  \\t\\t
• \\t

  2016 年京东 618：15 万个 Docker 实例，所有业务全部容器化

  \\t\\t
• \\t

  2017 年京东 618：容器技法日趋娴熟，数个项目即将开源回馈社区

  \\t\

2018 年的 618，鲍永成和他的同事们写下了这篇文章，他们希望能够系统梳理过去几年京东在基础架构方面的点击探索，也希望这系列文章能够帮助到更多的中小公司少走弯路。以下为系列文章的第一篇。

不在江湖久已。这两年来我们（京东）完成了从Kubernetes的落地、推广，到大规模运营的历程。走过了那些山水，看过了那些风景，现在，我想，是时候讲讲我们的故事了。

故事要从四年前讲起，JDOS(Jingdong Datacenter Operating System) 1.0于2014年推出，基于OpenStack进行了深度定制，并在国内率先将容器引入生产环境。经历了2015年6.18/11.11的考验。团队积累了大量的容器运营经验，对Linux内核、网络、存储等深度定制，实现了容器秒级分配。

2016年，我们将精力集中与了完善容器的监控、网络、存储，镜像中心等容器生态建设，并积累了丰富的运营监控数据。也是在这一年，我们渐渐意识到了OpenStack架构的笨重，启动了新一代容器引擎平台(JDOS 2.0)的研发。

2017年，JDOS2.0全面推出，JDOS从基础设施升华到应用平台。2.0推进了业务从源码到编译打包构建镜像到上线的全流程，建设了一站式应用运行平台。 这一年，我们逐步完善了容器的监控、网络、存储，镜像中心等容器生态建设，开发了基于BGP的Skynet网络、ContainerLB、ContainerDNS、ContainerFS等多个项目。

并将其中部分项目进行了开源()。我们为我们的容器生态起了一个全新的名字：阿基米德，意为撬动数据中心的人。

罗马不是一天建成的。在容器化的过程中，我们经历了很多，在这里我认为有必要回顾一下我们的经验和教训，有资于后来者借鉴与参考。

1. \\t

   不轻易放弃用户。如果大量的改造工作都由业务方来承担，那么容器化的推动将会是一件极其艰难的事情。许多老的业务可能没有那么无状态，甚而有一些诸如ip不变等的特殊需求。为用户的定制和改造，不仅是一种妥协，更是提供一个兼容老的业务方式以使其容器化的方案。如果总是拒绝用户，那么在失去用户的同时，也失去了与他们一起成长的机会。贴近用户，了解用户的需求，进行分析、归类和适应性的改造。在成就了业务的同时，也是成就了自己。

   \\t\\t
2. \\t

   幻想一蹴而就和急功近利，都是容器化过程中的大忌。对于应用进行改造的理想很丰满，现实却总是很骨感。因为这需要业务的大量的人力、物力、财力的支持。我们在容器化的过程中，采用了渐进式的策略。在开始，允许用户将容器以虚拟机/物理机的使用方式进行使用，由其传统的应用运维使用以往的工具进行部署和维护。同时，我们也提供了编译构建上线的一站式服务，支持滚动升级、灰度发布、负载均衡、域名解析等等服务。用便捷的运维管理方式吸引用户自主进行转变。再后来，我们放开了镜像的构建过程。已经有越来越多的用户愿意自己去学习Dockerfile，以便构建起属于自己业务的镜像了。

   \\t\\t
3. \\t

   对于技术上的质疑要用技术来解决。新技术的推广难免受到质疑与挑战。要用于接受这些质疑和挑战，并用技术和数据来证明自己。当然这也对团队自身提出了更高的要求。对于新技术不是了解就可以了，而是能够吃深吃透，进而根据场景进行定制。

   \\t\\t
4. \\t

   架构要能化繁为简，易于维护运营和排障。社区的功能总是大而全，而对于我们具体的落地实践来说，我们更多要做的是减法，将原本繁杂的架构和流程梳理清晰，剪除不必要的功能，保证整个平台良好的可维护性。

   \\t\\t
5. \\t

   守住稳定的底线。稳定才是作为平台赖以生存的基础。将平台进行加固，确保其稳定，不是说说而已，这其中有大量的工作需要做。稳定不是保守，不是守住现在的版本不再研发。而是要对于整个平台的每个环节都能进行代码级的精准掌握，对于上线前功能、性能进行充分测试，对于突发状况有预案处理。从流程上能抑制雪崩问题的发生，并能够控制故障的影响范围。这些我们的具体工作将在未来的章节进行详述。

   \\t\

调度的意义与难点

在实现了99.9%的业务容器化后，阿基米德迎来了全新的挑战。近几年硬件成本上涨带来的ROI压力以及建设异地多活的数据中心的实际需求，使得阿基米德JDOS的重点从容器集群管理转向了调度，JDOS也从集群管理平台的角色逐渐转换为了调度平台。

调度的意义从微观上来说，是为每个容器寻找到一个合适的落脚点，也就是节点。但是从宏观角度来说，其意义在于将整个数据中心计算效能的提升。具体来说，调度可以在缩减资源碎片，资源时空复用，节能降耗以及提升计算效率方面取得巨大收益。而且该收益随着集群规模的扩大，会有更为明显的提升。

调度虽然收益颇丰，但是要实现也非轻而易举。调度不是空中楼阁，它依赖于大量的基础工作。这其中一些典型的问题，需要一一解决，比如异构、隔离、监控、评估等问题。

在JDOS 1.0中，因为容器更多的是以胖容器的形式存在，因此容器的使用相对来说是静态的，也就是一次调度完成后容器不会轻易迁移。除非节点故障、维护等特殊情况，则将其迁移到别的节点。而在JDOS 2.0中，情况就变得更为复杂了。JDOS 2.0允许用户自动或者手动地进行应用的扩容缩容。并且，由于大数据、AI、serverless等任务的引入，平台在将其与业务容器进行混合部署的同时，也需要具备对相关任务进行实时监控和异常驱逐的能力。而这些，对于调度平台的动态处理能力、时间规划能力都提出了更高的要求。

接下来，我们将用一系列的文章，深入解剖阿基米德调度平台。下一章预告《第一章：事非经过不知难，Kubernetes的定制与优化》，欢迎关注聊聊架构微信公众号，第一时间阅读系列文章。