learn-tech/专栏/超级访谈：对话毕玄/09统一调度：只是问题非常多而已，摔出来就行了.md

                            
                            因收到Google相关通知，网站将会择期关闭。相关通知内容
                            
                            
                            09 统一调度：只是问题非常多而已，摔出来就行了
                            
你好，我是叶芊。-
　-
上节课我们聊到16年毕玄拆完运维去带系统软件事业部跟研发效能部的经历。-
　-
对于高层根本不感兴趣的研发效能团队，定位是个大问题，做了一通现状分析之后，他终于找到了清晰的发力点：短期做代码智能化，长期解研发模式和环境干扰。-
　-
对于另一个团队——系统软件部，虽然高层给了明确目标，但他说做的也很不顺利，最后能做成也很难讲，可能时机比较巧。-
　-
作为自己在阿里14年的第三大亮点，统一调度的成功居然归因于“时机”？为什么？让我们跟着亲历这个集团级项目的总架构师，看一看当时有哪些障碍？他又是怎么处理的？


　-
极客时间：你当时带两个团队，研发效能之外就是统一调度，这个部门的目标是什么？

毕玄：本质也是成本，阿里内部以前有好几套调度系统，这次想做成一套统一的，我们叫Sigma，向Borg的下一代Omega致敬。

调度我们做了很多年，2011年做容器化T4就是，核心目标就是为了控制成本，当时我们做了两三年，大概知道了在这方面Google的Borg做得非常好。

那个时候传闻Google认为自己的核心竞争力是什么？最早他就做搜索，他认为自己最重要的竞争力是，一我排序结果的准确度比多数公司好；二做同样的效果我付出的成本是你们的1/10。这确实是，成本如果差这么远，商业上就没办法做下去了，这里面，Google觉得调度系统Borg承担了很大角色，类似它的Page Rank算法，是整体竞争力的一部分。

所以外部很少有Borg的信息，保密性做得非常好。后来我们知道一点是，2015年Google发表Borg论文，那其实几年前就写好了，只是内部一直摁着不让发，觉得可能对业务的核心竞争力有影响。

极客时间：所以13年你们了解到的信息是什么，可以具体说下吗？

毕玄：就是个思路。我们知道了以后都觉得哇这个思路简直太完美了，其实大家都能想到，但我们需要有人给信心，因为这个思路大家都觉得太难。

是这样，因为多数公司的机器会分成很多个池子，最典型的是一个机器池子用来跑在线业务，另外一个用来做大数据的业务。

大数据这个软件的核心设计思想就是尽量并行化，把一台机器的资源全部吃光，所以大数据特别吃资源，能把池子用得特别满。而在线业务，不是不想吃资源，它必须考虑的是什么？是稳定性，如果出问题了，我最好要有足够的冗余，加上一天还有很多不确定的高峰，所以我机器的余量一定是为高峰准备的，利用率就没有办法很高。

极客时间：在线的机器量，可以根据高低峰来伸缩吗？

毕玄：但事实上这是一个悖论。因为对在线来讲，稳定性是最重要的，如果你不断伸缩，万一出问题了，可能得不偿失。很多高峰是无法预测的，即使是淘宝看起来都是做大促才有高峰，但如果有个社会热点，除了微博，淘宝也会受影响，以前比如谁出了名，有了件衣服同款，那立刻爆。这种事情是没有办法预测的。

除非你可以做到秒级以下的伸缩，那可以。我后来带调度，也给了人去探索这个方向，但必须说真的很难，至少目前我们觉得从技术上来讲很难突破，伸缩的风险不那么可控。

极客时间：所以一方面是大数据机器用满，一方面是在线空闲，在线也不好伸缩。

毕玄：很多公司到了一定规模，在线机器增长其实还好，因为在线跟业务基本成正比，就是QPS，比如说现在100，明年你希望做到200，那我就加机器；同时，因为每年的机器比上一年更好，所以从预算角度来讲，公司觉得是合理的，业务增长20%，你机器增长比如15%，那当然可以，至少没多出钱，能接受。

但大数据就有问题了。通常大数据机器只要开始用了，每年的增速会越来越快，因为存储量一直在那，而大家想采集的数据细节会越来越多，这样才能更精准地画出特征，所以大数据的机器就会多；另外公司的经营一定会越来越难，以前增长比较容易获得，可以粗放式，但后面你肯定要精细化，但精细化对大数据的要求又越来越高，所以机器会越来越多。

这个时候，技术层面大家都很容易想到一个方案：既然在线这边这么混，大数据这么满，能不能合在一起，让大数据用在线？这就是当时Borg给大家的核心思路。

极客时间：把在线和离线混部？

毕玄：对，但其实Borg自己压根就不是这样，它诞生的时候就认为这两个本来应该在一起，我们以为一组机器跑大数据，一组机器跑在线，它一开始就认为干嘛要分？所以这就是Google。

极客时间：理念先进，都是机器，我只是时而跑离线时而跑在线。

毕玄：你说对了，Google觉得反正我机器在这儿了，该跑啥就跑啥，哪有说这个机器只能用来跑这个，没有。

Google当年有一个高管跳槽到百度，他第一次看预算的时候发现还分大数据机器和在线机器就很疑惑，为什么还要分机器类型？他说我们从来不分。所以百度后来做了Matrix，拿了两次一百万美金的百度最高奖。其实百度Matrix的思路就来源于Google。





　

极客时间：在离线混部，这个思路倒很直白。

毕玄：这个思路大家确实也能想到，也都觉得应该这么干，很多人就会问了：为什么不这么干？那肯定是有原因的。

从技术上讲，大数据跑到在线确实有很多问题。首先机器以前是分开的，最典型的就是通常在线机器是1块盘，大数据机器是12块盘，因为它跑的时候需要算非常大的数据，但在线以前数据量非常小，大数据上去跑的时候，存储不够，大家觉得没法搞。

另外物理的基础设施条件也有要求。

第一在线机器和大数据机器要在同一个城市。比如从A到B的网络我们叫城际带宽，如果不在同一个地方，意味着要走这个，但城际的网络带宽非常贵，你如果跑大数据就更不得了，要求非常高，这条路是不可能的，所以首先要的是大数据和在线搬到同一个机房。

而且当时物理基础设施除了机房，还有网络的问题，以前我们的网络是千兆，对大数据来讲不够用的，它需要万兆以及更高。千兆就要搞各种限制，所以也很痛苦。我们2014年只能在上海机房搞个小的试验环境，去做一些试验。

除了基础设施，还有干扰的问题，因为大数据任务会吃光所有的资源，如果你在线也同时跑，会不会影响到在线业务的稳定性？如果被干扰了，导致你的响应时间下去了，就完蛋了，在线业务会不惜一切代价保稳定性，你想如果业务都挂了，省钱有什么意义，对不对？

极客时间：以前机房分开也是出于成本考虑吧？

毕玄：对中国西部城市比如说内蒙古，电非常充足，电费非常便宜，加上温度通常比较低，建机房就很好，很省钱。但问题是互联网的出口通常又在一线城市比如北京、上海这几个点，做在线业务是需要互联网出口的，我必须在这些城市或者附近。

这就奠定了以前大数据、在线都在不同机房，所以Google这个思路一开始在中国就做不了。当时我们面临的第一个挑战就是这个，怎么说服高层阿里建一个大机房，让在线和离线搬到同一个地方去？

但这对任何一家公司都是一个非常大的决定。建一个大机房是几十亿的投入，要找到一个地方电费便宜，也要在互联网出口附近，也要探讨清楚ROI到底是什么？因为开始肯定要增加投入，以前没有这些，现在砸好多钱，你到底能不能省回来？这就是又是那个论证问题。

极客时间：所以机房问题，团队也没办法，只能等公司决策？

毕玄：那没办法。现在阿里是建在张北、南通等几个地方，但你看这几个地方显然都不是大城市，但离大城市又不远，既享受到了电费、气候，又享受到了互联网出口，这就是非常好的选择。百度最早在阳泉也是，建了一个30万台机器的大机房，然后是阿里15年建的张北，腾讯也开始，后来思路就全部统一了。

极客时间：后来阿里建了大机房，是因为说服了高层？还是看别人做了？

毕玄：那倒不是，阿里有很多原因，主要是因为云起来了，对我们来讲小机房效率不是很好。所以后来统一调度能做，也很难讲，可能是时机比较巧。

反正后期走这个方向的公司都很痛苦，因为你前期物理设施不是按照这个来的。像Google是一开始就是这么来的，所以它不存在这些问题。我们后走这条路的都很尴尬。

　



　

极客时间：在离线混部这么多问题，当时感觉都没有解法，你们做的时候有信心吗？具体进展是怎么样的？

毕玄：信心是有的，因为统一调度说实话跟做异地多活不一样。

这次有参考对象，只是资料不公开而已，但大思路在，所以你的大方向是有的，异地多活是没有大方向的，纯靠自己摸索，完全不知道能不能走通，很可能会走挂，但调度，我们觉得Google能干成，至少这条路走下去应该没问题，不会走不通，只是要解决的问题肯定非常多而已。

但在阿里，必须说我们做这件事情难度比百度更大。百度是高层Push大家这样做，而且大数据团队有很强的动力，在阿里，我们有很强的动力，但我们是在线业务团队，不是大数据团队，这个事想做成，很多工作是要大数据团队做的，当年他们还有别的很多事情要干，觉得这不是我的重点。

所以各种原因，尽管我们从14年开始做，但进展一直比较慢。

物理上的限制，是等15年建大机房了才有可能性了，然后网络要升级到万兆，上面升级到25G，40G，100G，到了16、17年那个时候网络都具备了，也没有问题。剩下要解的核心问题就是大数据对在线的干扰，还有两边机器的磁盘不一样。

极客时间：磁盘问题，后来网络好了是不是就解决了？

毕玄：网络升级上去之后我们可以走计算-存储分离。

但计算-存储分离内部当年也争论非常大。原因是大数据软件在一开始的核心设计思想，除了高度并行、充分使用资源，还有一个是“存储和计算一体化”，就是调度的时候会尽量让任务和存储在同一台机器上，这样算起来最快。但你现在告诉大数据团队不要放在一台机器上，这其实挑战了大数据的很多思想。

所以内部争论非常巨大，但我们反正可以逼着你必须走这条路，比如说卡预算各种。

极客时间：跟以前异地多活一样不给你分机器？

毕玄：对，因为我所有机器是没有磁盘的，你必须走分离，否则我在线给你机器你也跑不了。

所以基本等16年阿里开始大力提统一调度，也有了正规军，很多问题才慢慢被解决，一是物理条件具备了，其实是18年才具备的，但大家在16年开始探讨，觉得这个方向可行，基础设施就去配套准备，所以大机房、网络都在那两年完成了。

极客时间：到16年那个时候，对在离线混部方案的价值，大家的认知也统一了？

毕玄：我觉得很大的原因是预算上大数据对成本的压力已经非常大了，必须要控制。

但控制的思路我们探讨了很久，觉得最好最完美的仍然是Google。你想，在线有一大堆机器在手上，如果能把大数据跑上去，相当于不用花钱的，大家拍脑袋想都觉得能省好多钱，是个好方向。

极客时间：现在就剩下干扰问题。

毕玄：对，就是阿里的操作系统团队。系统软件部在我一开始组建的时候，操作系统团队可能只有10个人左右，人很少，然后到2018年的时候大概有100人，主要就是为了解决干扰问题。

极客时间：你们当时遇到了哪些问题，业界有参考吗？

毕玄：Google尽管在论文里提及一两句，但不会讲更多细节，他论文的风格一般是这样，只是告诉你我很牛，但要怎么做到这么牛不会讲。你只能自己实践。

我们就必须靠大量人力去堆，在这个过程中肯定会出问题，但只要出了问题以后我有专业的人，可以把问题迅速解决掉就能做。所以我们其实是这样摔出来的，也没有什么。

这因为一方面公司信任，另外一方面是我们的在线业务有回滚、容灾各种策略，也有异地多活可以切流量，相对来讲是在比较安全的情况下做尝试，所以我们也不太在乎，出问题了就把流量切走。





　

极客时间：你们当时尝试的结果怎么样？

毕玄：从2016年到2018年，我们大概跑到了1万台机器，相当于在线有1万台可以给离线用，那一年离线少采购了5000多台机器，1台假设10万，所以一年省了5个亿。

关键是不光这一年，下一年我只要继续扩大在线规模，就能继续省钱，到后面每年省的钱会越来越多，因为技术已经是成熟可以被复用的了。方案上、技术层面上肯定不会有太大问题，剩下全是工程，工程是很缓慢的，你就算技术走通了，工程要完全落地也要个周期。

这可以用一个指标直接体现，公司所有服务器全天的平均利用率，像Google就只看这个指标。大部分公司应该都小于10%，阿里16年开始做的时候是8%，Google发表论文的时候利用率大概是50%，这意味着Google只用1/5的机器就可以做同样的业务，离它讲的核心竞争力非常接近。

极客时间：为什么业界、阿里和Google差距这么大？

毕玄：中国公司更难是因为我们不是全球化的，大数据是很高，但晚上没有流量在线就是零，所以你平均一下就完蛋了，利用率就很低，但国外很多公司会好一点。

以前我们问Facebook这个问题，因为Facebook没有学Google走统一调度。我们问为什么？Facebook说因为我的在线业务全天流量都还挺高的，因为它是一个国际化的网站，全时区覆盖。那我们没有，中国公司这一点确实是个问题。

极客时间：所以从那之后，利用率就成团队重点关注的指标了？

毕玄：阿里每年就在不断地推进利用率指标，我们甚至讲到连财务都理解了，财务挑战研发线的服务器成本，他不关注其他，只看利用率要拉上去。

以前，研发的服务器投入，财务线的人是没有方法挑战的。你说要采购100台，财务说太多了，你说业务有多少需求、量多大，所以需要采购，然后财务听完晕倒了，他没有办法反驳你，因为你是拿业务在说事。但后来我们的财务就说看看你们利用率才多少，为什么要采购？不给批。我们训练了他们怎么挑战研发，就很好，连我们CFO都懂。

极客时间：利用率，阿里现在做到多少了？

毕玄：我是2019年初不带这个团队了，当时从原来的小于10%做到了20%左右，相当于翻倍了，就意味着成本有可能减半。

Google这两年据说已经推到了60%，我们以前认为50%是天花板，不可能再多。以前财务也问，你们说利用率可以低，但得告诉我多少是合理的。我们总不能说小于10%是合理的，这解释不过去，从技术上也得编个理由，但50%我们说是可以解读的。

一是因为这是全天的平均，如果说50%，意味着高峰肯定会比较高，平均一下已经很少了。第二是多数CPU的设计原理都是超线程，你看到两个核，物理上只有一个核，只是说软件层面具备跑出类似两个核的能力，但其实是不可能跑得出来的。所以我们说就打个折，当然这有点忽悠，但财务线非IT的人可以理解，觉得比较有道理（笑）。

极客时间：但是现在Google推到60%，这套解释又说不过去了（笑）。

毕玄：没想到Google竟然又突破了，做到60%左右还是很稳定，所以我们觉得它就是天花板了。

现在阿里这个团队还在做，去年做到了30%左右，天花板是60%，阿里规模这么大，我们假设50%是天花板，那30-50%也还有很大空间值得努力，ROI还是非常高的，所以这个团队一直评价都非常好。

　



　-
极客时间：调度系统Sigma，你们当时做的挺早的，看报道K8s生态起来了之后，你们就把Sigma的技术栈换到上K8s了？

毕玄：那是后来，我们2016年做的时候，Docker最火，K8s还没起来。当时在调度上的竞争非常激烈，因为调度其实会把下面的容器屏蔽掉，Docker觉得如果自己不往上做调度很危险，就开始做Swarm，然后Mesos是另外一家，Google刚把K8s开源出来。

而且Google以前也不做开源，他的套路是发论文然后什么都不干，但他在大数据上的伤害比较大，之前他发了MapReduce那几篇三驾马车的论文，发现自己啥也没得到，然后什么Hadoop公司全起来了。

关键是后来他做云，云上放MapReduce，但所有开发者用的接口全部是Hadoop接口，导致Google不得不去兼容Hadoop接口，简直太搞笑了。他们内部觉得我MapReduce做的比Hadoop好太多了，我是个成熟的很牛的东西，你们竟然不用。

那之后Google才发现重要的不是发论文，是做开源抢占开发者，所以在K8s上，Google吸取了教训，开始对新套路有点概念了，我先发论文占领影响力，然后再发一个论文实现的开源产品。但Google不擅长做开源，就找了擅长开源圈子玩法的RedHat，联合起来做K8s，因为Borg跟内部很多系统搅在一起，没办法开源，只能重做。

极客时间：那16年你们刚做的时候，技术怎么选的型？

毕玄：我们当时选择了Swarm做Sigma，但2018年的时候K8s就基本垄断了，我们很多的业务方用的是K8s的API，访问Sigma就不通，导致我们必须兼容K8s的API。

但在兼容上面，我们在很多开源路线上都犯过错误，一开始其实有一个开源的东西，但是我们先自研，然后等开源的那个拥有了最多的用户，我们就不断兼容，但是你兼容会越来越痛苦，因为开源一旦起来以后是一个很健康的社群，有非常多公司的合作，会越做越好，到了那个阶段你是抗衡不了社区的。

所以兼容这条路其实是走不下去的，我们就决定不做兼容，把Sigma扔掉，基于K8s把Sigma做的有些东西放到里面去，就是ASI。

极客时间：兼容的痛苦是指什么？

毕玄：因为社区的关键问题是控制不住，我们当年经历过很多次这个过程。

比如说一开始对我来讲这个阶段非常重要的需求，对他来讲可能一点都不重要，那我们肯定觉得开源做的不好，需求又很急，我们就大量自研做了很多Patch的东西。但后面发现开源一旦起来节奏太快，它增加了很多东西，其实覆盖掉了以前我们做的很多改进，这个时候就很尴尬了，到底是升级成它？还是保留自己？我们后来觉得应该尽快升级成开源，因为会被它拉得越来越大。

极客时间：所以Sigma的事大家都能接受？当年大家也不太能预料到K8s会迅速起来，所以后来Sigma换到K8s上是比较必然的事？

毕玄：大家能理解也能接受。确实肯定有些人会很不舍，毕竟做了几年，而且业务效果也在，最后不得不扔掉。

但这确实是我们当年判断的失误，如果更早选择K8s会更好。但16年的时候我们看Swarm和Mesos，加上K8s不成熟，不觉得开源有绝对优势，觉得自研有优势有机会。

所以我们后来反思，做技术选型的时候，如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好，没必要挑战。阿里在开源这条路上吃过很多亏，因为以前都自研，HSF和Dubbo也是典型。

极客时间：HSF和Dubbo是指什么，可以具体讲下吗？

毕玄：HSF是我们自研的产品，Dubbo是开源的，在整个开发者群体里肯定有最多用户。但阿里收购完一家公司会告诉他，你把Dubbo换了，换成HSF。

很多公司觉得很尴尬，你们进来之后，业务啥也没干，先把技术换掉了，阿里以前经常这么做。我们后来说像这种，就不应该让别人换掉，应该把我们自己换掉，所以HSF后来新版本的目标就是换成以Dubbo为核心，支持内部HSF协议的解析，这样以后收购就非常简单。

极客时间：我们现在站在事后看，当时你们判断开源不成熟，选择自研Sigma，是不是因为大厂不可能说等两年，等开源成熟？

毕玄：不可能等，而且大厂确实挑战也比较大，要解决的问题很多，所以如果开源如果不是很成熟，很难说我一开始就选择开源。

极客时间：但一个领域，开源如果已经成熟了，大厂才开始用，是不是说明你们没有更前瞻地看到这个领域的问题？

毕玄：大厂很有可能比开源看到更快，所以确实就是你说的很尴尬，现在大厂的自研走上了一条很尴尬的路线。

开源反噬自研是之后业界的长期话题，以前很多公司都是自研，但现在开源已经被玩得太多了，什么都开源，那之前的自研到底怎么办。

反正我们的判断就是，如果开源的东西已经是主流了，比如说像Spring cloud，那没必要做一个新东西再去跟它竞争，因为我们也只能靠开源去争，但如果没有革命性进步，关键也竞争不过他，所以我们后来做了Spring Cloud Alibaba，就是觉得我竞争不过你，跟你一起玩好了。策略就是这样，总体还是拥抱开源，因为你要么就自己做个开源，要么就用开源做，就这两条路。



　

水友讨论区

今天的对谈到这里就暂时结束了，重点聊毕玄当年做统一调度的经历。

虽然这些年毕玄换了不少领域，但从他对成本的关注这条线讲，之前做的所有事情又能大概串联起来，最早做的容器T4，到后来的异地多活，到今天的统一调度，后面他创业选择的方向也是做企业的云成本控制FinOps。这么看，成本可能是一个企业始终关注的话题。


Google当年分析自己的优势也提到这一点，一是排序结果的准确度比多数公司好，二做同样的效果付出的成本是其他人的1/10。分析自己所在的团队/公司，你觉得优势是什么呢？
关于统一调度的技术选型，我们也聊到了开源和自研的问题，毕玄的反思是“如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好。”你是怎么看的呢？


如果你有更感兴趣的话题，欢迎在评论区留言，如果觉得有启发也欢迎分享给身边的朋友，一起讨论。

读到这一讲，时间线已经走到了2018年，毕玄马上就要从阿里离开了，下一讲我们聊聊这个话题。下一讲见。

拓展阅读

如果你对统一调度的具体技术细节感兴趣，可以看这几篇：-
阿里云云原生写的揭开阿里巴巴复杂任务资源混合调度技术面纱-
阿里巴巴中间件写的：给 K8s 装上大数据调度引擎：伏羲架构升级 K8s 统一调度-
云技术的新变革：阿里云13年后重构全部核心调度系统