本文讲的是为什么我们要开源自己研发的高性能容器编排系统 Eru2【编者的话】原则上来说 Eru 只是将 Docker 作为容器最小单元引擎，并不做过强的耦合和依赖。通过架构层面上的设计和优化，使得 Eru 可以支持上千甚至上万台物理机器集群，满足小型到大型公司平台层面的调度编排需求。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
作为自己 30 岁之前的一个「小目标」，白天我提交完最后一个大特质修正后， Eru2 的开源计划就走入了倒计时阶段。2007-2017 眨眼 10 年。启蒙于 hongqn 的豆瓣后端体系介绍而步入了系统工程师的深坑，受教于金山快盘的工程化实践，又有幸与启蒙自己的豆瓣平台组共事两年一起做 Douban App Engine，在 (*)aaS 的道路上越走越远。14年洲际旅行回国，从芒果TV 到 ENJOY ，从最初的 DAE Copy on Docker 到理论上国内首批大规模使用 Redis Cluster 并提供了 Cerberus 和 容器化解决方案 ，这后面驱动的都是我一直想做的大一统平台。
幸运的是，有 Docker，DAE 当年隔离的问题再也不是问题 。不幸的是，有 Docker，容器的不稳定在大集群下面对管理提出了更高的要求。Docker 就像一把双刃剑，关键是你怎么去用它。 Borg 提供了一个视角，而它的亲儿子 Kubernetes 以压倒性的优势成为了平台层面的事实标准。在它的身后，角落里 Docker 的亲儿子 Swarm 还在负隅顽抗，而它的身边，是一个叫 Mesos 的尸体。
那么问题来了，为什么我们要做这个东西呢？
让我们把眼光放回 2014 年，就以当时的业界视角来看，其实你是没多少选择的。当年的 Kubernetes 江湖传闻就一个人全职开发，除了 Google 爹的光环以外复杂的概念和尚不稳定的特性，没有全知全能的视野当时的你会知道终有一天它终将为王？甚至 Mesos 上的 Marathon 在先发优势上都能把 Kubernetes 按在地上摩擦，但一想到以 Apache 之名下 Mesos 那「笨重」的结构你会轻易去尝试？至于 Docker 的亲儿子，它的爹还在忙于 1.0 的 stable，它的妈还不知道是在世界的哪个角落，所以造轮子并非一个不可理解的选择。我们再把时间拨到2015年，半个前豆瓣平台组还能有机会在宜信大数据给我们带来基于特定工程的最优解 Lain 。即便到了 2017 年，从我的个人角度来看，虽然 Kubernetes 几乎一统江湖，但自建平台也还是有一定土壤的。
如 Kubernetes 吧，Google 二儿子，Borg 血统最为纯净的继承者，万千资源于一身的编排调度平台集大成者，早期用户也不得不面对其架构复杂部署困难的问题。对于小公司而言，上 Kubernetes 带来的成本远高于其带来 DevOps 效率提升而降低的成本。对于中大型公司而言，Kubernetes 本身相对而言的排他性对于已有基础设施重建以及业务适配又是一个需要额外成本的地方。至于超大公司以他们的人力物力财力，就我某几位不愿意透露姓名的P8/P9基友所言，早就脱离社区自己玩自己的去了，毕竟业务才是来钱的大爷。你不能说它不行，乐观锁的分配能力完全能满足一家豆瓣类似规模的中大型公司，Pod Service 的概念抽象使得所谓的微服务化变得前所未有的简单直观。但一个东西不能说它好就要去上对吧，自己的业务模式 Workflow 要不要改造，如何改造，对于 Kubernetes 本身的运维经验有没有积累，现有的基础设施怎么办，这都是需要考虑的问题。况且线上用了 Kubernetes 了，离线任务要不要用，怎么用，如何和 Apache 全家桶搅一起，都要摸索。
其他的几种选择来说，Lain 对于特定工程来说是最优解，没有比一个能自举的平台更加迷人了。然而就我对他们的了解，如果你的团队没有豆瓣那种我要打10个的素质，学习成本还是蛮高的，需要严格的遵从 Workflow 和开发范式，需要有相当高的 DevOps 能力。已经死掉的 Mesos 系而言，光是 Apache 之名就足以吓跑很多人，已经到 2017 的今天，Hadoop 的部署使用还能出书出课程收费教人，让人不得不对其同门 Mesos 的易用性打上一个问号。况且就以资源分配来说，悲观锁资源邀约的设计在大集群下的性能还是比较堪忧的，就不说这也是一套强侵入式的架构。至于 Docker 亲儿子，在 Engine 尚未表现出足以服众的稳定性前提下，把编排直接结合进其中作为一个 Mode，作为一个平台特性的东西来讲，这是大忌。同样的，Swarm 除了原生这一个「吸引人」的地方以外，无论是资源分配，Workflow 的集成和服务抽象均不如 Kubernetes。
还有一个就是，就以上几个平台而言，离线服务均都没考虑在内。当然 Mesos 会好些，但需要额外的框架支持，这种二元结构是它的优势也是它的劣势。如 Yarn 的离线计算如何结合容器平台，如怎样结合各类不同的 Fault tolerant job scheduler，这都需要使用者自行摸索。
那么我们又做了什么？
Eru2 本质上不是一揽子解决方案，结合在芒果TV 时期的经验，我们并不想做成特定工程类的最优解，而是一个尽可能减少对现有基础设施侵入的基础组件，因为这不是一个技术问题，这是政治问题。它的设计目标有：
在芒果 TV 的时候，我们全自动化无人管理过上千容器的单一 Redis 集群，而这种集群还有另外几个。在 ENJOY 的时候整个公司的看得到的看不到的甚至开发机都由我们驱动。不能说我们做得多好吧，毕竟这几年在互联网荒漠的长沙全职在做的除我和不愿意透露姓名的 tonicbupt 以外只有在 ENJOY 期间的 timfeirg，dante 和 wrfly 了。再能1个打10个，多少资源干多少活，我们只是想给这个浮躁的技术圈增加那么一点新的可能性。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
作为自己 30 岁之前的一个「小目标」，白天我提交完最后一个大特质修正后， Eru2 的开源计划就走入了倒计时阶段。2007-2017 眨眼 10 年。启蒙于 hongqn 的豆瓣后端体系介绍而步入了系统工程师的深坑，受教于金山快盘的工程化实践，又有幸与启蒙自己的豆瓣平台组共事两年一起做 Douban App Engine，在 (*)aaS 的道路上越走越远。14年洲际旅行回国，从芒果TV 到 ENJOY ，从最初的 DAE Copy on Docker 到理论上国内首批大规模使用 Redis Cluster 并提供了 Cerberus 和 容器化解决方案 ，这后面驱动的都是我一直想做的大一统平台。
幸运的是，有 Docker，DAE 当年隔离的问题再也不是问题 。不幸的是，有 Docker，容器的不稳定在大集群下面对管理提出了更高的要求。Docker 就像一把双刃剑，关键是你怎么去用它。 Borg 提供了一个视角，而它的亲儿子 Kubernetes 以压倒性的优势成为了平台层面的事实标准。在它的身后，角落里 Docker 的亲儿子 Swarm 还在负隅顽抗，而它的身边，是一个叫 Mesos 的尸体。
那么问题来了，为什么我们要做这个东西呢？
让我们把眼光放回 2014 年，就以当时的业界视角来看，其实你是没多少选择的。当年的 Kubernetes 江湖传闻就一个人全职开发，除了 Google 爹的光环以外复杂的概念和尚不稳定的特性，没有全知全能的视野当时的你会知道终有一天它终将为王？甚至 Mesos 上的 Marathon 在先发优势上都能把 Kubernetes 按在地上摩擦，但一想到以 Apache 之名下 Mesos 那「笨重」的结构你会轻易去尝试？至于 Docker 的亲儿子，它的爹还在忙于 1.0 的 stable，它的妈还不知道是在世界的哪个角落，所以造轮子并非一个不可理解的选择。我们再把时间拨到2015年，半个前豆瓣平台组还能有机会在宜信大数据给我们带来基于特定工程的最优解 Lain 。即便到了 2017 年，从我的个人角度来看，虽然 Kubernetes 几乎一统江湖，但自建平台也还是有一定土壤的。
如 Kubernetes 吧，Google 二儿子，Borg 血统最为纯净的继承者，万千资源于一身的编排调度平台集大成者，早期用户也不得不面对其架构复杂部署困难的问题。对于小公司而言，上 Kubernetes 带来的成本远高于其带来 DevOps 效率提升而降低的成本。对于中大型公司而言，Kubernetes 本身相对而言的排他性对于已有基础设施重建以及业务适配又是一个需要额外成本的地方。至于超大公司以他们的人力物力财力，就我某几位不愿意透露姓名的P8/P9基友所言，早就脱离社区自己玩自己的去了，毕竟业务才是来钱的大爷。你不能说它不行，乐观锁的分配能力完全能满足一家豆瓣类似规模的中大型公司，Pod Service 的概念抽象使得所谓的微服务化变得前所未有的简单直观。但一个东西不能说它好就要去上对吧，自己的业务模式 Workflow 要不要改造，如何改造，对于 Kubernetes 本身的运维经验有没有积累，现有的基础设施怎么办，这都是需要考虑的问题。况且线上用了 Kubernetes 了，离线任务要不要用，怎么用，如何和 Apache 全家桶搅一起，都要摸索。
其他的几种选择来说，Lain 对于特定工程来说是最优解，没有比一个能自举的平台更加迷人了。然而就我对他们的了解，如果你的团队没有豆瓣那种我要打10个的素质，学习成本还是蛮高的，需要严格的遵从 Workflow 和开发范式，需要有相当高的 DevOps 能力。已经死掉的 Mesos 系而言，光是 Apache 之名就足以吓跑很多人，已经到 2017 的今天，Hadoop 的部署使用还能出书出课程收费教人，让人不得不对其同门 Mesos 的易用性打上一个问号。况且就以资源分配来说，悲观锁资源邀约的设计在大集群下的性能还是比较堪忧的，就不说这也是一套强侵入式的架构。至于 Docker 亲儿子，在 Engine 尚未表现出足以服众的稳定性前提下，把编排直接结合进其中作为一个 Mode，作为一个平台特性的东西来讲，这是大忌。同样的，Swarm 除了原生这一个「吸引人」的地方以外，无论是资源分配，Workflow 的集成和服务抽象均不如 Kubernetes。
还有一个就是，就以上几个平台而言，离线服务均都没考虑在内。当然 Mesos 会好些，但需要额外的框架支持，这种二元结构是它的优势也是它的劣势。如 Yarn 的离线计算如何结合容器平台，如怎样结合各类不同的 Fault tolerant job scheduler，这都需要使用者自行摸索。
那么我们又做了什么？
Eru2 本质上不是一揽子解决方案，结合在芒果TV 时期的经验，我们并不想做成特定工程类的最优解，而是一个尽可能减少对现有基础设施侵入的基础组件，因为这不是一个技术问题，这是政治问题。它的设计目标有：
- 高效而精确并且多维度的资源分配和实时再分配
- 尽可能的复用现有基础设施，尽可能减少对现有基础设施的排他性和侵入性
- 不提供全家桶
- 满足离线需求，提供接口满足离线计算，做大一统平台
- 无论多大规模，尽可能的易维护
- 对业务而言改动小，易接入
- 使用者心智负担低
在芒果 TV 的时候，我们全自动化无人管理过上千容器的单一 Redis 集群，而这种集群还有另外几个。在 ENJOY 的时候整个公司的看得到的看不到的甚至开发机都由我们驱动。不能说我们做得多好吧，毕竟这几年在互联网荒漠的长沙全职在做的除我和不愿意透露姓名的 tonicbupt 以外只有在 ENJOY 期间的 timfeirg，dante 和 wrfly 了。再能1个打10个，多少资源干多少活，我们只是想给这个浮躁的技术圈增加那么一点新的可能性。
原文链接：https://zhuanlan.zhihu.com/p/28961390
原文发布时间为：2017-09-08
本文作者：尼古拉斯
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：为什么我们要开源自己研发的高性能容器编排系统 Eru2
