从0诞生
在物理机时代，应用上线等待分配物理机时间平均在一周。应用混部要看脸看颜值的，没有隔离的应用混部如履薄冰，所以在物理机时代混部的比例平均每台物理机低于9个不同应用的tomcat实例。 从痛点入手可以极大提升新项目的落地实践机会。即刻我们着手规划京东虚拟化平台项目。从痛点以及当时2013-2014年的技术氛围可以容易想到，京东是从openstack开始，那个时代openstack研发人员炙手可热就像今天深度学习人才一样。京东强大的人才自培养传统发挥作用，在6个月内，就组建了一支14人的研发团队，并迅速掌握了openstack的核心代码。 Openstack对VM支持是天生的最好，所以接入第一个核心业务，就发现了问题。业务是一个并发量非常大又对延迟要求40ms以内的0级系统，我们对VM做了所有我们能知道的优化，依然无法达到预期，一直徘徊在60ms左右，但从VM切到物理机上运行性能稳稳的在40ms以内，期间动用了多种性能定位工具，如systemtap等。 在那2周只有黑夜和香烟的日子里面是漫无目的的郁闷，团队骨干已经杀红了眼做各种try。 结果是残酷的，核心系统研发同事安慰着：兄弟，我们等你。在整个2013年夏到2014年夏，退而求其次支撑了几百个非核心系统运行在KVM环境。在团队看来这是一个不小的挫折和压力。这一年是郁闷是压力也是积攒经验；这一年团队对京东业务有了极其深刻的了解，在openstack的掌控能力已经到了极高的段位并在此期间代表京东主导了openstack几个BP研发。 时光来到2014年秋，公司安排研发首席架构师刘海锋带领虚拟化团队，首席架构师带来新的启发和规划。团队重新出发，新的方案，新的思路。Docker进入我们的视野，那时候docker非常单薄，单薄到只有镜像和对cgroup简便的操作等功能是可用之外，其他基本是无法生产环境使用的。稍加改造做了基本性能测试，tp99可以有部分降低到40ms范围，这就是曙光。虽然还不完美，只是部分请求可以满足40ms要求，但是这就是未来。 虽然有了Docker，拿什么来管理数以万计的Docker容器实例。14年秋，没有k8s，没有swarm，没有，，，。通过20132014推广KVM所了解的业务，不难发现，直接彻底按容器的方式太过脱离业务研发的现状。作为最底层的计算层，稳定性，可靠性等质量要求极高，质量承诺坚如磐石。如果自研一套容器集群管理平台，时间是最大的成本，并且团队积累的openstack经验。最终团队选择openstack Docker的架构，并定义为京东第一代容器引擎平台JDOS1.0（JD DataCenter OS）。后面的故事京东研发同事基本是知晓。
研发上线申请计算资源由之前的一周缩短到分钟级，不管是1台容器还是1千台容器，在京东IDC经过计算资源池化后随时不限量秒级供应。京东第一代容器引擎强隔离特点，解决了研发同事再也不用靠颜值来争取和别的业务混合部署了。所有的研发同事从部署艰难选择求合体中解放出来，0级系统不再有vip待遇，应用不分0级和非0级，是否混部完全依靠京东第一代容器引擎平台通过算法预测和部署之后动态调度。 平均部署应用密度提升3倍，近似可以认为物理机使用率提升3倍，带来极大的经济收益。在容器化过程中，我们创造的容器新世界有效借力了京东已经运行了多年的多个稳定系统，包括数据库，缓存JIMDB，JMQ，服务框架JSF等。在容器化之前，基础设施以物理机为主。因此，京东容器落地的第一件主要工作是基础设施容器化，同时在应用的运维方面，兼用了之前的配套系统。 当我们向研发同事讲述什么是容器的时候，常常用虚拟机作类比。在给用户进行普及的时候，我们可以告诉他，容器是一种轻量级的虚拟机。但是在真正的落地实践的时候，我们要让用户明白这是容器，而不是虚拟机。这两者是有本质的区别的。虚拟机的本质上是模拟。通过模拟物理机上的硬件，向用户提供资源。容器的基石是经过隔离与限制的linux进程。容器提供的是性能损失更小的原生物理机的计算能力，容器之间唯一共享的是linux内核。 成长之痛 京东第一代容器引擎（JDOS）1.0版本从2015年开始部署，并在10月份陆续将部分业务迁移到弹性云平台。第一批业务包括核心和非核心系统如单品页，图片处理，订单等。
京东第一代容器引擎基于openstack Icehouse Docker1.3 OVS2.1.3架构简单，可靠。但随着集群规模越来越大，痛就开始显现；
很快openstack就遇到集群规模的问题，发生严重的不可靠问题；如：创建容器消息在MQ传输过程丢失，容器状态挂起，DB连接数过大，计算节点各种agent定时任务hang，部署升级无法核对升级结果。 京东基础平台部团队在openstack领域已经深入遨游许久，社区暂时没有遇到这么大规模，那研发团队只能自己动手创造了。如上图，设计目标单个集群1万台物理节点，对的，单个openstack集群管理1万台物理计算节点。首先改造的是MQ，原理也简单，自己实现一个python版本的RPC（brood），解除对MQ依赖。特别是依赖MQ操作DB的全部替代使用京东自研的python版本RPC框架，对数据库的全部操作均使用RPC自带支持的京东JIMDB（内存缓存集群）。这样计算节点的定时任务无需直接update数据库，支持透明通过京东的RPC update到JIMDB。 我们采用多IDC部署方式，使用同一的全局API开放对接到上线系统。支撑业务跨IDC部署。 可运维性挑战 单个openstack集群京东最大是1万台物理计算节点，最小是4K台计算节点。京东容器化战略是非常彻底的，应用运行环境100%全部容器化。这么多物理机和容器，运维是一个非常有意思的挑战。在研发京东第一代容器引擎之初，即定下来一个特点可运维性，所以目前运维这几万台物理机和几十万容器的运维工程师共2人，把日常运维工作系统归类。
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
