Golang 在阿里集团调度&集群管理系统 Sigma 中的实践

阿里系统软件技术 · · 4230 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。


阿里巴巴 9 年双 11 经历下来,交易额增长了 280 倍、交易峰值增长 800 多倍、系统数呈现爆发式增长。系统在支撑双 11 过程中的复杂度和支撑难度以指数级形式上升。双 11 峰值的本质是用有限的成本最大化提升用户体验和集群吞吐能力,用合理的代价解决峰值。始于 2011 年建设的调度&集群管理系统 Sigma 就是为了支撑如此庞大的体系而建立的。


本文作者李雨前(花名鹰缘) ,阿里巴巴技术专家  2015 年开始参入调度系统的建设,参与和推动调度系统的多个版本的演进以及支持双11大促资源的分配和管理。


如果您是资深架构师、Docker/Kubernetes/CloudNative 技术专家,对阿里系统软件事业部感兴趣,欢迎投递简历到 yingyuan.lyq@alibaba-inc.com 。

Sigma 有 Alikenel、SigmaSlave、SigmaMaster 三层大脑联动协作,Alikenel 部署在每一台物理机上,对内核进行增强,在资源分配、时间片分配上进行灵活的按优先级和策略调整,对任务的时延,任务时间片的抢占、不合理抢占的驱逐都能通过上层的规则配置自行决策。SigmaSlave 可以在本机进行容器 CPU 分配、应急场景处理等。通过本机 Slave 对时延敏感任务的干扰快速做出决策和响应,避免因全局决策处理时间长带来的业务损失。SigmaMaster 是一个最强的中心大脑,可以统揽全局,为大量物理机的容器部署进行资源调度分配和算法优化决策。

整个架构是面向终态的设计理念,收到请求后把数据存储到持久化存储层,调度器识别调度需求分配资源位置,Slave识别状态变化推进本地分配部署。系统整体的协调性和最终一致性非常好。我们在 2011 年开始做调度系统,2016 年用 Go 语言重写,2017 年兼容了 kubernetes API,希望结合生态的力量,共同建设和发展。

Sigma 总览

Sigma 的业务有两块,一块是对内,一块是对外,对内是所有的 BU 都接入了Sigma 的系统,我们的规模会有百万级别。Sigma 的内部有一个 logo,很容易理解,就是数学求和,Sigma 是很大的生态系统,需要很多人和系统配合完成。

这个业务分了几个层次,上层业务偏运维,下层业务偏系统,从接入层,到中心的 Master,到Slave,到最底会有一个 PouchContainer(阿里开源的富容器引擎)。

这是

Sigma 的架构

可以看出来,颜色有三块,一块是 Sigma 的,一个是 0 层,还有一块是关于 Fuxi 的,通俗的理解就是 Sigma 管在线,然后是 Fuxi 管离线的,中间是一个协调层,这样理解起来就跟 Mesos 比较接近一点。这个架构肯定不是最优的,但是它存在有它客观的原因。

我会从 Sigma 这边抽象的四个案例。我会给大家展示是什么的同时,讲背后我们的故事。

案例1

首先看一下 APIServer

我们平常写代码经常会接触到这些事情,在业务领域、调度领域稍稍不同,背后要做发布、扩容、销毁、启停、升级,还有云化,特别是双十一到阿里云买服务器,所以会有混合云需求。我们规模很大,就会要求所有简单的事情,怎么样让它在规模化的场景下面依然能够工作。我们调度系统跟运维有关,核心的内容就是怎么样做到运维友好。还有就是我们做在线的容器服务,肯定要做到高可用,还有一致性。

解决思路

1.数据一致性

数据的一致性上面我们是用 etcd/redis,我们会用一个实时+全量的方式做到数据的一致性

2.状态的一致性

想做到很好是很难的,但是我们把状态的一致性转为存储一致性来做,就会降低处理问题的难度。

3.简单的

我们没有追求技术看起来非常完美的方案,先把业务推起来能够用就好了。

4.高可用-无状态

我们要做到前面说的高可用,有几种方案,一个是多 Master 结构,还有无状态,还有就是快速的 failover,我们希望做到无状态。

5.降级-抢占

规模大了以后就会有一个问题,很多人都要资源,这个时候肯定会有一些稀缺的资源,系统要支持降级抢占。

6.内外兼容:一个团队两块牌子

要做到上云,所有的思考都要考虑到对内对外是一班人马,一个团队会有两个牌子,这是我们整个出发点的思路。

之后我们选择由 APIServer 把前面的发布、扩容等都放在 task,丢到 Redis 里,底层的 Worker 消费一些任务,做到无状态,得出来的结论就是架构整体的设计大于语言的选择。

数据一致性里面,如果能做到了实时,数据应该就是一致性的,为什么还要加全量来弥补这个过程?背后一个重要的原因就是物理机的硬件或者是软件会经常出故障,系统多了之后,很难保证故障的事件跟整个链路 100 闭环起来,就导致总有一些地方的数据不知道为什么不一致,有很多硬件、软件的故障导致实践的层面做不到一致性,就只好加一个全量弥补。还有另外一种方案不要全量,我们定时同步,但是有一个问题,时间窗口怎么定,定几分钟。同步的一瞬间,数据会有一些比对,这个时候加锁,成本维护会多一点。

状态一致性问题转为存储一致性的问题最好的就是转为存储一致性,我们为什么说要面向 etcd,在很大的系统里面有很多的设备系统,没有办法面向事务去做,最好是分布式的存储把这些问题兜掉。

为什么说简单够用,后面会有数据给大家看一下,要承载的量很大,没有办法做到 95%以上才上线,大家等不及,可能做到 85%就要上线了。

还有就是降级,前面我提到了阿里这么多的 BU,每一个 BU 都提了很多的预算,去采购,这就浪费很多资源,这中间有一个共享的 buffer,肯定会有抢占,这个在开源里面也会有一些策略。

内外兼容,如果是创业公司会有体会,一部分东西是基于内部的服务器,还有一些是购买上云的服务,这个时候管理起来,不可能上云的是一套管理方式,自己内部又是一套方式,至少在开发理解上是一模一样的,在设计和架构的时候要屏蔽很多的差异。基于这样的思考,我们觉得这种方式相对来说会比较好一点,不然尝试换其他的方式,问题解决可能会稍微麻烦一点。

前面讲了设计的架构,接下来讲的案例是一个真实的场景。

我们在阿里要做一次发布,比如说一开始要拉镜像,就要关闭告警,可能有一些应用要下线了,还要停止应用。然后开始容器升级,还要做业务逻辑的检查,检查完之后才把告警打开。不管是上云还是内部,这套流程肯定是公共的,具体对接的时候又不一样,内部和云上不一样,云上提供一个 SDK,云上的接口的异步性的流转和内部也不一样,所以要抽出来。

内部和阿里云上面都是这样的事情,阿里云比较特别的是什么呢?在 before 会做一些处理,我们核心的架构是很固定的,在阿里主流的语言是 JAVA,我们讨论架构的时候,没有局限于上来就用 JAVA,Golang,或者别的,我们把架构想清楚,之后才选择用什么样的开发语言。

这是我们数据的表现:

这个表现是任务量,数字隐去了,发布的量非常大,平常的量比较小,可以看到它有周期性的规则,因为阿里的体量有发布窗口期,那一天整个的发布量大了,会有一个全局的管控。

案例2

调度里面核心的模块之一是 Scheduler,在很多物理机上面选最佳的物理机,把容器布上去,常规的做法就是要有过滤链,过滤完之后会有一个权重的链,最后拿到我想要的机器上去创建这个容器。因为规模大,一个请求在一个机房里面去扫,这一个机房可能就是万级别的节点,肯定要考虑到性能的优化,所以筛选的规模比较大一点。它是一个链式的,首先要选择哪些服务器作为点,在这一块,我们的想法就是要并发起来,怎么样从工程上面做一个实践。绿色的框是顺序过程,红色的框是并发的阶段,或者是关键资源的锁的过程。每一个并发的粒度看成是一个物理机,相当于每一个物理机去筛选这个是否要,这是一种模式。

另外一种模式是说在整个机器的顶层加一个 glock,是顺序还是并行都不用管,这个锁加在上面,前面的锁是加在下面,两者看起来好像没有太大的区别,测试下来发现性能不一样。有几个因素,一个是下面要做过滤链或者做 weight,看开销;还有每一次筛选的规模,比如一天下来有十万的请求,每个请求背景物理机是好几万的规模还是几百的规模,最后对整体的性能要求是不一样的。

粗粒度并发的性能比较好,我们选择了第二种场景。深入的思考的时候,我们发现第一种场景行不通,原因是有些全局的资源没有在一个协程里面更改,另外一个协程不能立即可见。

案例3

Golang 最近几年非常的火爆,但是在阿里大的氛围里面更强调的是 JAVA 语言,我们引入 Golang 不可能一上来就大规模,需要有一个成功的案例,或者是小规模实践的过程。在这种环境下面,我们想让 Golang 有一席之地,首选的方式就是如何做到快速的打磨,跑得很慢的时候,语言构架系统可能就会被淘汰掉了。这是我们上一个版本,有大概五个链路,有一个架子,每一条链路是做的过程当中,一步一步完善出来。今天我们把链路搬出来跟 K8S 做比较的时候,很多地方都是相通的,但是具体框架的编码实践上面来说是有很大的差异。我们早些时候摸索的这些东西,可能就是业务驱动或者概念驱动,没有真正做到工程或是回馈社区的驱动。未来我们换了一种方式,我们可能是以工程的方式驱动,就是回馈社区。

案例4

我讲一下怎么解读这个图。分几层,上面这一层更强调的怎么样编排任务,中间的这一个层是讲整个容器的;纵向有三个部分,最左边是讲怎么样调度的,中间是一个容器的引擎,再后面是容器的运行时。

在 PouchContainer 里面,官方写了很多的 Features,这些 Features 是源于阿里真实的实践。为什么叫富容器,容器经典的代表大家可能想到 Docker,那 Docker 之前呢?比如阿里的虚拟机比较流行,从虚拟机过渡到容器,这么大的规模,需要适应运维的习惯,要有这样的感知、理念,这个时候容器的技术肯定要做很厚。然后再编排,现在我们了解的有 K8S,大家觉得很完美,但是那在 K8S 之前是什么,阿里的体量并不是 2015 年那一刻才长大的,2015 年之前就很大了。

我们有一个强隔离,为什么说强隔离?我们平时和别人探讨问题的思路有两种思路,第一种思路是一上去就排查,把问题解决掉。还有就看自己的系统,拼命的证明不是我的问题。在这个时候你强隔离就好说了,问题排查或者是黑盒子,特别是规模很大的时候就需要隔离很强,每个人在我的领域范围内很容易定位。从去年到今年,阿里做了很多混部的宣传,混部没有强隔离也有问题的。

还有就是为什么要引入 P2P?最早 P2P 是在流媒体里面,为什么又跟容器关联起来了,就是因为互联网里面有很强的思维,如果你慢的话,别人就会忍无可忍的。量少的话比工作更快一点。但是规模大的时候没有办法快,在链路上面来,包括业界也是一样,连路瓶颈已经在拉镜像,由此阿里很自然的就推了 P2P 加速。

还有内核的兼容,外界有一个说法——CTO 说阿里的商业成功,掩盖了阿里的技术成功,这个话确实有道理。有些业务我们是在 2011 年的时候拿到 2.6 版本,现在业务最新的到了 4.10,那些老的业务每天服务的人群量很小,不能说这个业务不赚钱或者没有前景。把它下掉了也不行,要给一个缓冲期,该升级了,这个没有办法一步到位。这个时候要做规模化的升级,或者技术的换代,内核必须要做兼容。

前面的内容只是把阿里巴巴自己的问题解决了,并没有把这些赋能给社区,所以要做标准化的思考,这个是为了未来把好东西回馈社区,所以必须要做标准化的兼容,再反过头来比这张图,就知道这个架构怎么思考,为什么要兼容 CRI。

代码1

前面我说最难调的 bug 是低级错误造成的,这个低级错误什么意思呢?

Golang 一开始很多人用 map 循环的时候,就受到了指针变量的误用,典型的表现就是,一个对象循环之后就会发现中间的所有的值一模一样,大家首先想到的是业务逻辑是不是不对,根本不会想到 for 循环是不是出了问题。后来我们发现我们对语言本身的理解还不是特别的到位,犯了低级的错误,这个 PPT 下面有详细的代码案例。

代码2

还有 map 对象的异步序列化,现在看来本质上是我们用法不对,当时理解跟业务场景有关,我们每次筛选服务器有上万的规模,为什么选择这条服务器,要用日志把它记下来。后面的优化、迭代要进行消息分析。我们就想到异步做这个事情,把对象存在异步里面去刷盘。但是我们犯了致命的错误,就是 Goroute 对同一个 map 执行了读写并发,这样就出现了 map 读写的冲突。如果知道对象是共享的资源,我们就会加锁,但是这种场景下面我们没有考虑到这个资源也会导致问题。业务场景,特别是异步对象持久化的,要有这样一个意识,规模大的时候要考虑这样一个问题。

代码3

我们做的过程当中发现有一个资源泄露的问题,是场景导致的,我们起了很多 Goroute,我们有个主任务,主任务会起很多子任务,子任务做一些循环的操作。到阿里云买服务器,阿里云是异步接口,现在起很多任务去买服务器,买完之后把请求发货去,它返还我一个异步的 ID,我再请求他状态执行结果。比如说我先请求,完了之后它分配我一些资源,启动这些资源。比如发起申请,然后 start,看看这个 start 是不是完成,start 也是有一个过程。比如阿里 90 分钟再建一个淘宝,要拿到资源,肯定要很快。

我们为什么会遇到泄露呢?我们主任务要申请 200 个实例,我会发起 200 或 50 个并发的请求到阿里云,但是不可能等 200 个请求全部完成了,200 个来了 15 个就已经向业务交付,用户的体验就很好。但是这种滚动式的交付,不可能无休止的等待,你得一分钟之内完成。

除了滚动式的交付,还有总体任务时间的控制,这就涉及到两级的 Goroute,第一级 Goroute 是总任务,子任务也是 Goroute,这就会涉及到泄露的问题。假设主任务超时了,就不管子任务,子任务一直在跑就会把资源耗完。

如果大家对 K8S 里面的代码,关于定时任务的框架有所了解的话,就会有更强的体会。当时我们如果看到这个的话就会借鉴他的方式,就不会采取我们自己造轮子的方式。这个案例最重要的就是以后写 Goroute 的时候要注意是不是有泄露。

代码4

我们为什么要做 Pod 打散?Pod 概念在阿里有几级,第一级是物理层级,第二级是机框打散,往上还有核心交换机的打散。比如我有两台服务器,其中有一台服务器挂掉以后,可用性一下子降到了 50%,其实创业公司还是可以接受的。但是在阿里,如果今天挂了 1%,就有非常多人投诉,所以要求非常高,所以哪怕是 1%的流量受到损失了,客服的量就一下子多很多。硬件故障和软件故障是天然的,我们无法规避怎么办呢?所有的服务不要扎堆,物理机,核心交换机上面也不要扎堆,这就是 Pod 打散。

Pod 打散背后还有一层思考,比如说这台机器已经有了相同的 Pod,另外一台 Pod 一定不会往里面部署,有很强的隔离,要么是 0,要么是 1,这个打散是强制的。但是这里讲的 Pod 打散不是强制的,是尽力交付。默认情况下尽可能地打散,如果打散不了,只能在一起,但是一旦有打散的机会,一定给你打散,我们的打散是在得分之后再做的事情,这个跟 K8S 不一样,K8S 是强硬的,要打散就一定打散,要不然交付不成功。

阿里的服务量很大,服务器各个地方都有,其实它可以有一定的容忍度。假设有一万个实例,可以允许 1%的实例有波动偏差,这个时候 Pod 就可以满足它。之所以能够接受就是因为它的体量太大了,有扛波动的能力,这个跟我们接触到的 K8S 完全不一样,这是规模化的视角看到的东西。

3.总结

设计层面:整体架构层面优先语言选择

性能层面:任务粒度选择

数据驱动:状态一致性转移为存储一致性

语言理解:Map 异步序列化,Map 循环指针

多层并发:可控超时

调度算法:规模下 pod 打散

Pouch Container:拥抱开源,回归社区

【提问环节】

提问1:我想请教一下,你是利用 redis 实现数据一致性,数据一致性代替状态移植,这个什么意思?

李雨前:比如说在 K8S 里面是面向结果交付的,我要三个实例我把数字改了你就可以扩出来,但是在 K8S 没有出来之前,阿里已经存在了这些需求,那个时候是面向过程的,什么意思呢?我要拉镜像,我要关报警,这一系列的动作从容器交付周期来说,就是事务的一部分,这个时候是有状态的。比如说,你想一种方式是每一个状态都带一个 ID,一连串的串回去,不可能是并发的。每一个状态都是并发的往前做,到一个阶段再并发做另外一个阶段的事情,这个我们理解为是有状态的,这些状态我们做的时候,做不出来很好效果。

为什么要放在 redis,我们做之前尝试过一点一点去做,最后我们怎么做呢?每一个状态做完了就丢到 redis 里面去。下一个任务做的时候就知道上一个任务是什么,只要状态满足了就做下一个事情,最后你后面写很多的任务,做的事情就很简单,上一个状态任务是什么就完了,中间做什么事情,也不需要看到全局的交互关系,这个就放到存储,包括维护的一致性。

提问2:其实 Sigma 的思路好像跟 K8S 有点像,我不知道 Sigma 有没有像 K8S 这种封装吗?是怎么暴露服务的?

李雨前:你觉得他们两个很像,那说明你对 K8S 或者 Sigma 有不错的理解。实际上包括 Sigma,包括 mesos,包括 Omega,包括 yarn,这些东西你比较的时候,很多地方有相似之处,从整体上架构来理解,他们确实是相似的,但是我前面提到了Sigma 肯定是在 K8S 出来之前,那个时候就有自己演进的思路和方式,解决的问题都是一样的。第二个问题,我们有没有社区里面大家看到的方式方法,比如说前面讲的 PouchContainer 最后一项就是标准化的兼容,这已经反映了我们跟社区一些好的东西已经要开始吸收,把社区好的理念拿到阿里的场景进行实践,实践好了就回馈给社区,从这社区里面学到的东西有很多很多,我们也努力向社区做一些反馈。

提问3:Sigma 底层可以用 PouchContainer,Docker 这种吗?

李雨前:可以的,前面我说了现在出了一个 CRI,那个已经兼容了,实现了 CRI 的协议,你用起来是一样的,你把 PouchContainer 起来的话,你用 Remoteruntime 配一下就可以了,我推荐你看一下 PouchContainer 官方文档,里面有一些案例。









有疑问加站长微信联系(非本文作者)

本文来自:51CTO博客

感谢作者:阿里系统软件技术

查看原文:Golang 在阿里集团调度&集群管理系统 Sigma 中的实践

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

4230 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传