从0诞生2013年初，京东的研发布局在虚拟化技术方向。那时我们从零开始。从几个人的小团队开始。物理机时代，应用上线等待物理机分配的平均时间为一周。应用混合取决于外观和外观。没有隔离的应用混合就像如履薄冰。所以在物理机时代，平均每台物理机混合部署的比例小于9个不同应用的tomcat实例。从痛点出发，可以大大提高新项目落地的几率。随即我们开始筹划京东虚拟化平台项目。从痛点和2013-2014年的技术氛围，不难想象京东是从openstack起家的。那时候的openstack研发人员就像今天的深度学习人才一样炙手可热。京东强大的人才培养传统发挥了作用。6个月内，组建了14人的研发团队，迅速掌握了openstack的核心代码。Openstack对于VM的支持天然是完美的，所以在接入第一个核心业务的时候，发现了一个问题。业务是0级系统，并发量非常大，时延要求小于40ms。我们已经对虚拟机做了所有已知的优化，但仍然不能达到预期。一直在60ms左右徘徊，但是从VM到物理机的运行性能稳定在40ms以内，期间使用了systemtap等多种性能定位工具。在那只有夜晚和香烟的2周里，漫无目的的压抑，团队的骨干们已经尝试了各种方法。结果很残酷，核心系统研发同事安慰道：兄弟，我们等你。整个2013年夏天到2014年夏天，老二支持了上百个运行在KVM环境下的非核心系统。在团队看来，这是不小的挫折和压力。这一年充满了压抑、压力，积累了经验；这一年，团队对京东的业务有了非常深刻的理解，对openstack的把控能力也达到了很高的水平。期间代表京东。时间来到2014年秋天，公司安排研发资深架构师刘海峰带领虚拟化团队，资深架构师带来了新的灵感和规划。团队带着新的计划和新的想法重新出发。Docker进入了我们的视野。那时候的Docker很瘦，瘦到只有镜像和对cgroups的简单操作等功能可用，其他的在生产环境中基本用不上。经过一点修改和基本的性能测试，tp99可以部分降低到40ms的范围，也就是黎明。虽然还不完善，只有部分请求可以满足40ms的要求，但这是未来。虽然有了Docker，用来管理数以万计的Docker容器实例是什么。2014年的秋天，没有k8s，没有swarm，没有，，，通过2013-2014年KVM理解的业务推广，不难发现直接完全跟随容器的方式太脱离业务研发现状。作为第一层的计算层，对稳定性、可靠性等质量要求极高，质量承诺坚如磐石。如果自己开发容器集群管理平台，时间是最大的成本，团队积累了openstack经验。最终，团队选择了openstack+Docker的架构，并将其定义为京东第一代容器引擎平台JDOS1.0（JDDataCenterOS）。京东研发同事基本都知道下面这个故事。京东基础平台部推出的第一代容器引擎平台推进非常迅速，从2015年启动到2016年618完成应用运行环境100%容器化。计算资源的研发和在线申请从之前的一周缩短到分钟级。无论是1个容器还是1000个容器，京东IDC在池化计算资源后随时提供无限秒级供应。京东第一代容器引擎具备强大的隔离特性，解决了研发同事不再需要靠外表与其他业务竞争混合部署的问题。所有研发同事都从部署和集成的艰难选择中解放出来。Level0系统不再有VIP待遇，应用不分为Level0和非Level0，是否混合完全取决于京东第一代容器引擎平台通过算法预测分析。部署后动态调度。平均部署应用密度提升3倍，物理机利用率大致可以认为提升3倍，带来巨大的经济效益。在容器化过程中，我们打造的容器新世界有效利用了京东运行多年的多个稳定系统，包括数据库、缓存JIMDB、JMQ、服务框架JSF等。在容器化之前，基础设施是以物理机为主。因此，京东容器落地的第一块主要工作是将基础设施容器化，同时在应用运维方面，也沿用了之前的支撑体系。当我们告诉研发同事什么是容器时，我们经常会用虚拟机来类比。给用户普及的时候，我们可以告诉他容器就是一个轻量级的虚拟机。但是在真正的实践中，我们需要让用户明白这是一个容器，而不是虚拟机。两者有着本质的区别。虚拟机本质上是模拟。通过在物理机上模拟硬件，为用户提供资源。容器的基石是隔离和受限的linux进程。容器以更少的性能损失提供原生物理机的计算能力，并且容器之间唯一共享的是Linux内核。成长的烦恼京东第一代容器引擎（JDOS）1.0版本从2015年开始部署，10月份部分业务已经迁移到弹性云平台。首批业务包括商品页面、图片处理、订单等核心和非核心系统。JDOS1.0架构京东第一代容器引擎基于openstackIcehouse+Docker1.3+OVS2.1.3架构，简单可靠。但随着集群规模越来越大，痛苦开始显现。openstack集群的大小是有限的，很快openstack就会遇到集群大小的问题，会出现严重的不可靠性问题；如：容器创建消息在MQ传输过程中丢失，容器状态挂起，DB连接数过大，计算节点各种代理定时任务挂掉，部署升级无法检查升级结果。京东的基础平台团队在openstack领域混的时间比较长，社区暂时没有遇到这么大的规模，所以研发团队只能自己创造。如上图所示，设计目标是单集群10000个物理节点。是的，一个openstack集群管理着10000个物理计算节点。首先要改造的是MQ，原理也很简单。自己实现一个python版本的RPC（brood），去掉对MQ的依赖。特别是依赖MQ操作所有数据库，而不是使用京东自研python版RPC框架，所有对数据库的操作使用京东自带RPC支持的JIMDB（内存缓存集群）。这样计算节点的定时任务不需要直接更新数据库，支持通过京东的RPC透明更新JIMDB。我们采用多IDC部署方式，使用全球统一的API开放接入线上系统。支持业务跨IDC部署。可操作性挑战京东单个openstack集群最大10000个物理计算节点，最小4K计算节点。京东的容器化战略非常周密，应用运行环境100%容器化。这么多的物理机器和容器，运维是一个非常有趣的挑战。京东第一代容器引擎研发之初，就确定了一个可操作性和可维护性的特点。所以目前有两个运维工程师在运维几万台物理机和几十万个容器。系统分类。京东第一代容器引擎扩容，一套基于chef的自动部署，是在大促前的集中线上扩容时计算的。从机器上架上电开始，新加入集群资源池的节点可用效率为4000个物理节点/天/人。万一实体机出现硬件故障，值得一提的是，京东的统一监控平台也是由基础平台部设计研发上线的。全新设计，跨IDC，容器化部署，高效监控，故障信息自动收敛。尤其是对硬件故障的感知特别可靠，比如网卡CRC错误、硬件故障的内核信息、从ILO口获取的硬件状态等。我们还与机器学习团队合作，智能预测硬件故障，尤其是磁盘故障。伟大的。这些信息会自动通知机房现场IDC同事处理，自动通知受影响的业务方，预测恢复时间。新一代容器引擎平台本身就有问题，所有组件在设计之初都是无状态的。停止新一代容器引擎的组件不会影响已经运行的容器的正常运行和提供服务。所有星团的每日X光片。从物理机、OS、openstack、依赖组件、内核日志、进程，到京东最新一代容器引擎，一应俱全。性能&稳定性是最致命的。规模大之后，出现很多低概率但真实存在的性能和稳定性问题；如mac表满无法进行网络通信、UDP大包阻塞、丢包、异常中断、系统slab集中回收内存申请锁时间过长等；很快我们就意识到原来的容器其实是一个Linux内核，所有的性能和稳定性问题都回到了最根本的一点——Linux内核。Linux内核团队立即成立。当然，最应该感谢京东研发的各位同仁。有了大家的包容和关爱，京东第一代容器引擎才有机会继续实践和完善。尤其是在LinuxKernel团队成立之前，解决了很多性能和稳定性问题，但不清楚原因。作为京东所有业务运营的基石，不这样做是很不现实的。对于任何性能瓶颈和稳定性现象，您必须能够找到那段代码并知道为什么。这张图是京东优化后的slab回收策略和机制原理。大家都知道容器虽然隔离了CPU、内存和各种IO，但它仍然是一个内核。内核的内存回收是一个统一的策略，类似于很多资源。JDLinuxKernel团队一一梳理，一点一滴的构建和调优，最终维护了JDLinuxKernel分支。一种踏实感油然而生。至此，基础平台部已完成京东第一代容器引擎的研发、推广和运营。快速发展——15万容器助力京东2016年618大促。经过近两年的运营，容器集群团队的技术能力也得到了业务研发团队的普遍认可。京东已将所有业务迁移至容器集群平台，最新一代容器引擎平台也成功保障了今年的618和双11大促活动。目前我们生产环境的容器数量已经超过15万个。这个规模是不是世界最大我们不得而知，但可以肯定的是，这应该是国内最大的集装箱规模。你工作越努力，你就会越好。第一代容器引擎平台获得的不仅仅是成功的上线和运行，还有容器技术研发同仁的认可和信任。在第一代容器引擎风头正劲的时候，团队又迎接了新的挑战，将京东数据库迁移到容器环境，将京东的实时计算Storm和Spark集群迁移到容器环境。在团队内部，京东的数据库容器化叫CDS，也解决了两个痛点，物理机资源利用率和应用DB速度。JDOS1.0解决了这两个痛点，做得很好。只做了两个改进，可以直接支持：本地磁盘使用SSD，优化了磁盘调度算法，更适合SSD。数据库实例创建时间缩短至1分钟，机器资源利用率提升5倍。2016年双十一期间，70%的数据库实例都运行在容器环境中。目前，实时计算平台部署在容器平台上是水到渠成的事情。资源弹性伸缩的便利性是最大的吸引力。目前运行在最新一代容器集群上的***Storm集群拥有1K容器实例、完全可扩展的容器资源和镜像发布，极大地方便了实时计算平台对部署和资源的需求。回首——不忘初心在实现第一代容器引擎的实践中，我们用IAAS思想和VM管理来管理容器。这种方式有利于业务转型，直接从物理机和虚拟机迁移到云端。但缺点是我们是“重”型思维，所以JDOS1.0是基础设施层而不是应用平台。私有云的弹性更多的是空壳容器的弹性伸缩，并没有真正实现应用的伸缩。但是，京东第一代容器引擎的实践是非常有意义的。它的意义在于将业务搬到了容器中，尽可能地踩了应用容器化的坑。容器的网络和存储已经逐渐成熟。而这些都为我们在1.0的经验基础上开发全新的应用平台打下了坚实的基础。不惧未来，不思往事，我们的征途是星辰大海。当JDOS1.0从1000-2000的容器规模逐渐发展到60000-100000的规模时，基础平台部开始了新一代容器引擎平台的研发。我们这次的目标不仅是一个基础设施管理平台，更是一个直接面向应用的容器平台，整合1.0存储和网络，打通从源码到镜像，再到线上部署的整个CI/CD流程，提供从日志、监控、排查、终端、编排等一站式功能。让研发同事专注于产品的快速交付，让运维同事专注于系统的高质量上线运行；京东新一代容器引擎平台已经上线，正处于快速推广阶段。新一代容器引擎项目在原有1.0的基础上，支持应用开发上线全流程：应用构建、镜像仓库、配置中心、应用上线、运维、监控、日志记录、故障排除等。一代容器引擎项目架构版本预发布。新一代容器引擎平台的目标体现在：调度数据中心的所有计算资源；不仅仅是线上生产环境的资源调度，还可以借助京东第一代容器的积累和优势，对整个数据中心的所有资源进行统一调度，包括测试环境和预发布环境引擎在虚拟化网络中，有信心在保证网络隔离安全的情况下，在推广期间使用测试环境和预发布环境的计算能力。极大促进算力贡献。开发者的一站式解决方案平台不仅在应用程序、数据库、实时计算等领域得到广泛应用。我们还计划支持离线计算、深度学习、中间件等系统，成为数据中心计算的统一载体。灵活调度，尤其是抢占式调度，有效支持离线大数据计算任务和深度学习算法训练。基于第一代容器引擎带来的业务100%容器化红利，新一代容器引擎从调度IaaS资源升级为以调度应用业务为中心。【本文来自专栏作者张凯涛微信公众号（凯涛的博客）公众号id：kaitao-1234567】点此查看作者更多好文
