聊聊调度和编排

前言

最近在和不愿意透露姓名的 anrs 结对编程，在 Eru 上实现 Virtual machines 和 Container 混合调度，以及对 NUMA 架构的支持，因此南门口技术指说北说好的一月一更快变成年更了。和同事一次闲聊中聊到了中台这个概念，阿里创造了这个名词后各种牛鬼神蛇依葫芦画瓢。事实上中台的本质是什么，什么业务中台，什么数据中台，其实不就是标准化嘛。抛开所有那些奇奇怪怪的概念和技术细节，好的「中台」应该是缺了谁都行，本身应该是一个中立的标准。而调度和编排系统，在我看来就是把这个标准落地后那个「中台」最核心的组件之一。

所以，今天就聊聊几个调度和编排的系统。

Mesos

因为在我眼里 docker 系的 swarm 已经死了，就直接跳过先从 mesos 开始。

平心而论，Mesos 很不错。某种意义上来说 Mesos 是那种从出生开始就盯着大一统平台这个目标而去的调度和编排系统，架构和实现上还保留着一些科研界的理想主义气息，也是目前已知开源圈里面唯一能支持超大规模集群的编排系统。但只有 Mesos 还不能称之为调度和编排平台，一般来说是需要搭配一个或者多个上层框架来一起使用。Mesos 负责调度，Framework 负责编排，坏就坏在这个中二气息爆表的双层调度上。

首先，DRF 是一种非常优秀的资源调度策略，尽可能的保证了公平。抽象的来看，Mesos 只需要关注与资源本身，然后切割成不同的 offer 按照一定策略给 Frameworks 选择。因此在 Mesos 的层面上，资源利用率在理论上是比其他系统要优秀得多的，怎么使用这些资源 offer 就是上层的事情了。这里 Mesos 忽略了一个问题，那就是 Frameworks 间本身是有亲和和反亲和属性的。当然你说我就用一个 Frameworks 行不行，当然行，Twitter Aurona 的就是这么做的。不过当你这么做的时候，就产生了一个直击灵魂的问题：如果只有一个 Framework 我为什么需要双层调度？

既然选择双层调度是为了资源公平以及最大化利用率，但又为了真实世界的各种情况不得已统一框架或者用筛选器直接选择，降低了资源利用率也使得所谓的资源公平性荡然无存，用人话说，就是破功了。好处没占上，还比隔壁的 k8s 麻烦。因此，这几年 Mesos 式微，不是没道理的。

K8s

K8s 虽然赢得了战争，但很多实现上的出发点是「商业」原因。比起楼上 Mesos 来说，没那么中二，接地气并且被大多数公司摩擦出了一整套生产经验，大体上是没有什么问题的。坏就坏在，k8s 的有些设计，太商业化了，反而限制了它的想象力。

比如 CRI 这种东西，说实话是没必要有的。本身 Kubelet 就是监听反馈机制，通过 Watch 能力把 etcd 当成了多 channel 的 message queue。假如真的把这个 「message」标准化，每个人都可以通过这套 protocol 来实现自己的执行器，至于这个执行器之后是 Container 还是 virtual machine 亦或是一组云服务器 API 都无所谓，优雅又实用，还灵活得很。比现在的 Kubevirt 那个先起个容器，容器里面起控制器，控制器再起 VM，不知道高到哪里去了。

这种绑定 Kubelet 的策略，个人觉得其实就是死也不放 executor 的标准，其他家的竞品可以做一个链路上最末的 engine，但做不了 executor。怎么解释协议都是 executor 定的，engine 只能被动的接受。然后为了扩展这套体系搞出来的 CRD 等东西，你看本来一个简单的事情慢慢的就变得越来越复杂，CRD 不够就用 operator 凑。前几年觉得 Docker 真是强势，占着事实标准为所欲为。现在再看，论怎么最大化标准的利益，还能让用户拍手叫好，G家面前在座的各位都是弟（la）弟（ji），Docker 在 Google 面前，就是个弟中弟。

Nomad

Nomad 说真的可惜了，要不是 HashiCorp 相对来说是小公司，Nomad 本应该获得更多关注的。抛开只存在于论文中 Omega 系统和微软 Apollo 系统的 mvcc 调度，nomad 应该是已知唯一可以摸得到的使用了 mvcc 方案进行资源调度和编排的系统。

加上丰富的 Task drivers 使得 Nomad 不仅仅可以调度和编排容器，进程，虚拟机等都可以直接调度，真正意义上实现了大一统平台。在我看来 Nomad 唯一的短板就是，mvcc 这类乐观锁不太好确定状态。不出事的时候一直爽，出了事要人命。随着集群大小的线性递增，资源冲突和分配失败的概率也是增加的。因此集群在一个时间点的状态并不确定，调度和编排时间越长，应用不确定的因素就越多，可控性就差了。

哪有悲观锁抢占式一把嗦来得痛快。

尾声

其实这部分我是想写自己的 Eru 的，创建于大家都在摸着石头过河的年代，机缘巧合之下之下一直续一秒续到了现在。石头摸着摸着就走上了 Nomad 的路子，不过换成了一直抢占一直爽的悲观锁。比 k8s 而言了标准化的 executor 抽象，这也是为什么这次接原生 vm 调度和对 NUMA 架构支持如此顺利。但同时又缺乏 k8s 那么多 PaaS 的能力，比如自动保持 N 个容器在集群中，还有各种磁盘管理。对于调度编排肯定是够了，至于未来怎么办，可能这就是 Eru 最大的短板了吧，毕竟我这么懒。

回到最开始谈的中台这个概念，标准化不是一个系统一个组件能够定义的。即便调度和编排在这个标准中是非常重要的一环，但也不必过度神话其作用。阿里过去那么多年没自动化调度和编排不也没垮是吧，选适合架构的就好。至于未来的话，我觉得大体上所有的调度和编排系统都会往大一统平台这个目标发展，不会仅局限于容器以及线上业务，有兴趣的话可以多关注下吧。