在阿里云十三年的发展历史上，重新设计调度系统算得上是一个重要的技术抉择。
云计算是一个庞大的技术工程。2009年，阿里云从0到1自建国产云计算系统“飞天”，为了确保对每一行代码都有控制力，阿里云选择了一条艰难的道路：自主研发。伏羲调度系统是“飞天”三大服务之一。调度系统作为云计算的核心技术，无论是对亚马逊、谷歌还是其他云计算企业来说，都是他们最保守的秘密，而伏羲凭借自研与优异的性能，与YARN、Mesos等技术一起成为了调度系统的典型代表之一。
这么多年发展下来，很多人认为阿里云战略上最与众不同之处，就是坚持自研核心技术。作为全球集群规模最大的云计算平台之一，阿里云在技术已然成熟、稳定运行着数量庞大的业务情况下，选择了用云原生的标准重新设计和构建云计算的调度系统，并在2021年“双十一”大促之前将全球几十个数据中心、数百万容器、数千万核的资源统统搬到了新的调度系统之上。
阿里云为什么在十三年之后重构调度系统？在不影响业务运行的情况下，阿里云是如何更换“引擎”的？这种技术思路给我们带来什么启示？新调度系统有开源计划吗？InfoQ采访了几位调度系统负责人，为大家一一解惑。
发展十三年，成绩斐然的老调度系统
资源调度系统可谓是云计算的大脑，负责在众多集群内的机器里，选择一台最合适的，以最佳的资源使用姿势，做到最少的相互干扰来运行用户提交的计算作业。云计算最终目的之一是降低IT成本，最大限度地利用单台PC的CPU处理能力，而调度系统恰恰就决定着基础设施的利用率和整体运作成本。
艰难起步，从0到1自研伏羲调度系统
2008年，阿里巴巴确定了“云计算”战略，决定自主研发大规模分布式计算操作系统“飞天”，目标是将几千台乃至上万台普通PC服务器连接到一起，使其像一台多功能的超级计算机，实现超强计算性能。
2009年2月，飞天团队在北京写下了第一行代码，“飞天”系统也从此成为阿里云的奠基技术平台。伏羲调度系统是十年前飞天成立时创建的三大服务之一，另两个是飞天分布式存储盘古和分布式计算MaxCompute。
2011年7月，阿里云作为中国第一个公有云正式对外开放。这之后的十多年里，伏羲能调度的单集群规模，也从最初的几百台物理机，发展到了10万台机器。我们知道，规模每放大十倍，就意味着很多架构设计点都需要重新调整，当横向扩展遭遇不可逾越的瓶颈，就代表着系统重构的开始，伏羲就因此经历了两次重构。
2013年，伏羲在飞天“5K”项目中对系统架构进行了第一次大重构。“5K”顾名思义，就是能让调度系统支持单集群5000节点，并解决大规模单集群下的性能、利用率、容错等问题。
不断扩大单集群的规模，到现在依然是业界不同调度系统在做的事情。
如果依靠早期的Hadoop开源调度器技术，以当时的实践经验来看，并不是容易的事情，因此伏羲团队选择了架构和代码都是自己构建的自研方式。这个项目，在阿里云历史上也是一次非常有里程碑意义的“攻坚战”。
随着阿里云的业务需求变化，伏羲的内涵也在不断扩大。最开始是作为一款对标开源YARN的单一资源调度器，而后扩展成了覆盖数据调度、资源调度、计算调度、单机调度等的核心调度系统，伏羲也于2019年经历了第二次重构，并将单集群规模扩展到了十万台。
双调度系统混部实践
伏羲是负责阿里离线业务的调度系统，而于2015年正式立项的ASI调度器则支撑着阿里搜索、电商等庞大的在线业务。
在线调度历史也比较悠久，最早起源于2011年上线的T4系统，即阿里早期基于LXC和LinuxKernel定制的容器调度器。T4的技术理念与如今云原生领域的核心技术——容器，如出一辙。在线调度最开始是一个简单的资源分配系统，而后逐渐演进为Sigma调度器、ASI调度器，在发展过程中又进一步吸收并融合了伏羲离线调度系统、搜索团队基于YARN的Hippo系统的先进经验。
据称全球服务器平均利用率不到20%，因此提升服务器的资源利用率是很多大厂不断追逐的目标。
2014年左右，阿里巴巴开始大力探索混部技术，通过将在线业务和离线大数据计算的负载混部运行在共享的集群中，以期可以显著提高数据中心资源利用率。与离线调度不一样的是，类似双十一活动中的零点峰值场景，它对在线调度CPU的集群化编排要求非常高，对延迟和抖动敏感；离线业务正好相反，平时资源使用压力较高，业务资源使用较为固定，对时延不敏感。所以，只要两类负载能跑在共享的集群中使用“分时复用”的策略，就可以达到提升利用率的目的。
作为自研的调度系统，伏羲和Sigma运行在一起，这种混部系统形式曾存在很多干扰和影响，一方面是两个系统之间节点状态不一致造成的干扰，另一方面是两个系统所分配的容器互相之间的干扰。然而“混部”带来的收益又不可忽视，因此阿里于2016年开始重点研发了Sigma1.0，基于DockerSwarm通道创建容器，并将演进中的各种语言技术栈统一为Golang，同时在实践层面做了很多隔离、协同的优化工作，也将不同等级的任务调度做得更精细化。
大船难调头，阿里的调度系统发展了十多年，成果斐然，性能优异，运行的业务规模也是数千万级别了，但2021年，阿里云还是决定将伏羲、Sigma双调度协同系统重构为基于ACK的“统一调度系统”。
基于阿里云容器服务ACK的调度系统
我们在技术上到达了一个新的临界点。
2020年6月，阿里云集结了100多位调度团队核心技术人员，开始了重构的进程。
经过一年多的研发，赶在双十一之前，将数千万量级的业务切换到了新一代的“统一调度系统”上。新框架基于阿里云容器服务Kubernetes版（简称容器服务ACK），通过一套调度协议、一套系统架构，统一管理底层的计算、存储、网络资源。ACK本身提供了一个全托管的Kubernetes集群的调度能力，对于IaaS层不同类型的计算、存储、网络等能力都可以统一调度，是统一调度大资源池化生产运行的基座。
2021年双十一，新系统打通并统一了阿里巴巴电商、搜推广、MaxCompute大数据和蚂蚁业务，全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
为什么要重建？
Kubernetes项目始于2014年，源自谷歌内部的Borg，吸收了Borg项目多年的实践经验，它超前引入了Pod概念将容器分组，大量使用了Sidecar设计模式，为容器化应用提供了自动化的资源调度，并具备动态扩容、滚动升级、负载均衡、服务发现等功能，受到大厂的大力推崇。
在接下来的两年里，与其对应的Mesos、DockerSwarm等相比，Kubernetes作为容器编排引擎的采用缓慢却很稳定，领先的科技巨头如亚马逊、阿里巴巴、微软Azure、红帽都开始启动了基于Kubernetes的新解决方案。
2019年，Sigma全面迁移到了基于ACK的调度系统。同时，在这几年里，阿里的技术体系也逐渐全面切向云原生技术，去年9月，阿里云容器服务全面升级为ACKAnywhere。
据在线调度系统负责人智清回忆，在线调度系统最初是完全自研的，云原生兴起之后，在线调度团队于2017年决定将这套技术框架迁移到Kubernetes，消除两者之间的差异并跑在阿里云容器服务ACK上。“刚开始是比较艰难的，尝试过好多版本，包括SigmaonKubernetes、KubernetesonSigma等方式，最后还是决定用最标准、最原生的、完全基于Kubernetes的方式。”后面启动的ASI项目，它做的事情就是将整个调度框架以非常原生的标准方式搬到Kubernetes上，在Kubernetes基础上做到在线、离线调度的真正融合。而且在业务侧，阿里也专门组织了一支云原生团队来推进容器化，最终形成一个整体的云原生资源池。
云原生统一调度架构师懿川将这些年调度系统的发展过程总结为三个阶段：
第一个阶段是非容器阶段，仅有调度的需求，并且基础设施还没有完善，属于调度的最初期阶段。在这个阶段，无论是伏羲还是T4，基本都是借助一些比较简单的隔离概念，以及一些内核的能力，靠自身的演进来实现对调度的最朴素的需求。
第二个阶段是开始进入容器阶段。容器技术使用场景变多，规模变大，Sigma以容器为主进行了改造。在这个阶段，需要调度系统既能承接业务的需求，又能同时深耕容器技术。
第三个阶段是云原生化，调度系统完全基于新一代的容器技术，包含阿里自己的安全容器、RunC以及其他的虚拟化技术，同时调度器的实现框架上也需适应整个Kubernetes生态。也就是将电商、搜索和大促这种创造洪峰型的业务，以及十多年调度系统技术积累，再结合Kubernetes开源架构的优势，整合到一起进行大规模应用。
总而言之，阿里重建调度系统的决策，是基于业务演进的需要，也是希望能有一个全局资源池，统一支撑所有业务形态。
云计算的本质，是将小的计算碎片变成更大的资源池，充分削峰填谷，提供极致的能效比。混部技术打破了多资源池的割裂，不同计算领域的多调度大脑协同共用资源，让业务间峰谷互补的优势发挥到最大，但两个调度器，由于彼此间无法高效地交互细粒度信息，阻碍了混部效果的进一步提升。
另外调度成本、资源的调度效率和业务独占资源池有很大的关系。从过去的调度系统演进经验来推断，建设统一资源池是最好的提升效率的方法：业务上有很多共同性的调度需求是可以互相配合和优化借鉴的，各自演进并不利于发展。无论是搜索还是电商，在线还是离线，如果作业类型越来越相近的话，就可以通过合作和共建，作为同一种调度类型去建设和演进，集中力量将云原生终态方案一起做到极致，并希望最后能做到自研、商用、开源三位一体。
“反倒是做成一个统一的调度系统是比较难的，做成多种调度系统相对来讲更容易。而且类似谷歌的Borg或微软的Apollo系统一开始也不是所有的调度策略、逻辑以及场景都能支持，也有一个在演进过程中逐步增加功能的过程。”
新调度系统对Kubernetes的改进和增强
新调度系统需要支持在线离线、低频高频各种调度类型和众多业务种类，且要完全兼容Kubernetes生态，还需要是模块化、组件化，形成一个可插拔式的机制。
统一调度团队针对Kubernetes社区版在Pod和资源安全上做了很多优化，围绕APIServer、ETCD、Kubelet做了不少功能优化和代码修改。统一调度在Pod和接口调用上也做了很多安全防御方面的事情，例如ETCD错配或出现其它问题时如何进行防护，从而保证底座平台的安全。但最重要的两方面改造在单集群规模、调度频次性能上。
Kubernetes早期版本仅支持几百节点的单集群规模，与Mesos支持的节点数量相去甚远，各大厂集合力量一起大幅提升了Kubernetes的集群管理规模，到1.9版本就已可以稳定支持5000个节点，但远达不到阿里原来调度系统单集群上万节点的性能要求。并且Kubernetes以APIServer为中心的消息同步机制，更适用于调度频度较低的在线服务场景，对于阿里系统中的大数据计算场景，可达每秒10万次的调度频度。所以“尽管Kubernetes已经演进很久了，但是在我们的调度器上仍然需要投入大量的工作来改造，才能够满足我们的要求。”
如果要问哪些历史经验有助于新系统重构的话，集群管理规模的突破必定是其中之一。
2013年的飞天5K项目，已经早早突破了单集群5000节点的规模。在后面的演进中，伏羲再次经历了第二次重构，据伏羲分布式调度负责人李超回忆说，当时主要考虑到“现在集群的规模可能动不动就过万台，不光是物理节点在增加，CPU的处理能力也在不断增强。5年前一台物理机上一般二三十个CPUcore，现在一台物理机节点里已经变成了一百多个CPUcore了。相当于即便物理机节点不增加，可调度的总资源扩大了五六倍，甚至扩大了一个数量级，这对调度的挑战是很大的。”
“如果规模无限扩展下去，在架构和设计上也要有一个应对的方案。随着规模继续变大，我们也要Hold得住。”
在伏羲2.0资源调度的重构里，伏羲团队提出了一些比较新颖的观点，在混部中引入去中心化的多调度器架构，基于悲观锁这种Partition策略，解决调度之间的冲突，保证调度latency性能达到与小规模下的系统相同的水平。
但Kubernetes单集群规模有限，远不能满足今天的诉求。统一调度团队通过对APIServer和ETCD的算法优化、在服务端进行数据压缩以及链路治理的方式，将集群规模从8千台（2020年）扩展到1.2万台（2021年）节点，而业界一般达到8千台就已经是超大规模。
统一调度团队参考了Kubernetes社区schedulerframework插件化和多调度机制，通过灵活的调度框架让不同的调度团队可以定制各自的调度需求，从而让Kubernetes能够很好的去支持一些场景下的大规模高并发的调度需求。比如在阿里大数据场景下，对调度系统的要求是每秒钟能发生十万次调度。
飞行中更换引擎
2021年双十一之前，伏羲和ASI调度系统中的机器和计算资源已迁移到了统一调度系统，仅伏羲就包含几万台机器、数百万核计算资源，迁移过程需全程对业务和用户透明无感。
同时这个系统本身是一个涉及非常多人的协同项目，中间涉及到一次完整的系统重新设计和实现，还要将原有积累的伏羲、Sigma、ASI以及Hippo的设计经验融合进来，且保持对业务的兼容性和对开源框架的兼容性。
可以说，整体设计非常复杂，代码开发涉及的耦合也很高，各个系统之间还存在各种对接。
以伏羲为例，在阿里MaxCompute技术体系中，伏羲一方面是分布式系统的资源管理和调度组件，需要与上层作业执行引擎进行资源交互，另一方面也是各种运维管控的数据源，复杂的模块依赖决定了系统升级是一件非常艰巨的事情。如果将MaxCompute比作一架高速飞行的飞机，统一调度升级就是要给这架飞行中的飞机更换引擎，难度可想而知。
在这种情况下，要让新系统在“双十一”大促中表现得更有保障，李超表示主要有两大技术举措：
第一是灰度上线之前，有专门的风洞测试机制，它能把历史上真实生产的一些需求、请求在测试环境去做回放（Replay），从而验证经过新一轮的修改或者新的功能后系统是否能稳定上线。
第二是在稳定性上，在状态的可恢复上，传统的方式是基于KubernetesETCD的持久化机制，但是因为大数据的调度频率达到每秒十万次的调度，这种状态要做持久化保障是比较困难的。新系统引入了软硬状态failover机制，简单来说是基于这个状态的重新收集，而不是完全依赖于状态的持久化。在不同的角色上去收集状态，重建调度器当时的状态。
另外在工程上也需要一套很严格的实施和上线机制：
未来规划
每个技术都有自己的生命周期，十多年前大家很难想到Kubernetes会成为当今技术界的扛把子，而技术演进过程中，开发者的使命就是用最合适的技术来构建我们的系统。使用新技术不代表过去的经验和成果不再有价值，统一调度系统也是吸取了伏羲和Sigma系统构建中的精华。
开源技术影响着调度系统的演进，而部署在大型企业生产环境中的系统，无论是谷歌的Borg、微软的Apollo还是脸书的Twine，反过来也在影响开源项目的系统演进。统一调度团队表示，未来会进一步提升和完善整个调度器的功能和能力，继续往2.0推进；另一方面，要完成自研、商用、开源三位一体的目标，作为战略计划推进项目的开源，包括开源核心代码和关键能力。建设这样一个超级系统，投入和挑战都非常大，而开源能够将更多的人聚集起来，一起把这套系统做得更好。
延伸阅读：
采访嘉宾简介：
懿川，阿里巴巴研究员，云原生统一调度架构师。全面负责统一调度项目，在分布式领域和资源管理领域有多年的经验积累。
李超，阿里云智能计算平台事业部资深技术专家，飞天平台伏羲分布式调度负责人，拥有十多年分布式系统与大数据研发经验。
智清，阿里云智能容器服务资深技术专家，ASI调度系统负责人，负责了阿里巴巴在线调度从Sigma、ASI、到全面统一调度的迭代演进。