技术抉择（阿里云13年后重构全部核心调度系统）云计算

简介：在阿里云十三年的发展历史上，重新设计调度系统算得上是一个重要的技术抉择。
在阿里云十三年的发展历史上，重新设计调度系统算得上是一个重要的技术抉择。
云计算是一个庞大的技术工程。2009 年，阿里云从 0 到 1 自建国产云计算系统“飞天”，为了确保对每一行代码都有控制力，阿里云选择了一条艰难的道路：自主研发。伏羲调度系统是“飞天”三大服务之一。调度系统作为云计算的核心技术，无论是对亚马逊、谷歌还是其他云计算企业来说，都是他们最保守的秘密，而伏羲凭借自研与优异的性能，与 YARN、Mesos 等技术一起成为了调度系统的典型代表之一。
这么多年发展下来，很多人认为阿里云战略上最与众不同之处，就是坚持自研核心技术。作为全球集群规模最大的云计算平台之一，阿里云在技术已然成熟、稳定运行着数量庞大的业务情况下，选择了用云原生的标准重新设计和构建云计算的调度系统，并在 2021 年“双十一”大促之前将全球几十个数据中心、数百万容器、数千万核的资源统统搬到了新的调度系统之上。
阿里云为什么在十三年之后重构调度系统？在不影响业务运行的情况下，阿里云是如何更换“引擎”的？这种技术思路给我们带来什么启示？新调度系统有开源计划吗？InfoQ 采访了几位调度系统负责人，为大家一一解惑。
发展十三年，成绩斐然的老调度系统
资源调度系统可谓是云计算的大脑，负责在众多集群内的机器里，选择一台最合适的，以最佳的资源使用姿势，做到最少的相互干扰来运行用户提交的计算作业。云计算最终目的之一是降低 IT 成本，最大限度地利用单台 PC 的 CPU 处理能力，而调度系统恰恰就决定着基础设施的利用率和整体运作成本。
无论是亚马逊、谷歌、微软还是阿里，某种程度上，“大脑”代表的是企业技术竞争力。核心技术的重要性不言而喻，像谷歌的调度系统 Borg，在很长一段时间内，一直是谷歌最保守的秘密之一。
艰难起步，从 0 到 1 自研伏羲调度系统
2008 年，阿里巴巴确定了“云计算”战略，决定自主研发大规模分布式计算操作系统“飞天”，目标是将几千台乃至上万台普通 PC 服务器连接到一起，使其像一台多功能的超级计算机，实现超强计算性能。
2009 年 2 月，飞天团队在北京写下了第一行代码，“飞天”系统也从此成为阿里云的奠基技术平台。伏羲调度系统是十年前飞天成立时创建的三大服务之一，另两个是飞天分布式存储盘古和分布式计算 MaxCompute。
2011 年 7 月，阿里云作为中国第一个公有云正式对外开放。这之后的十多年里，伏羲能调度的单集群规模，也从最初的几百台物理机，发展到了 10 万台机器。我们知道，规模每放大十倍，就意味着很多架构设计点都需要重新调整，当横向扩展遭遇不可逾越的瓶颈，就代表着系统重构的开始，伏羲就因此经历了两次重构。
2013 年，伏羲在飞天“5K”项目中对系统架构进行了第一次大重构。“5K”顾名思义，就是能让调度系统支持单集群 5000 节点，并解决大规模单集群下的性能、利用率、容错等问题。
不断扩大单集群的规模，到现在依然是业界不同调度系统在做的事情。
如果依靠早期的 Hadoop 开源调度器技术，以当时的实践经验来看，并不是容易的事情，因此伏羲团队选择了架构和代码都是自己构建的自研方式。这个项目，在阿里云历史上也是一次非常有里程碑意义的“攻坚战”。

文章图片

（阿里飞天 5K 项目纪念碑）
随后历经一年半时间，阿里巴巴和蚂蚁金服完成“登月计划”，将所有数据存储、计算任务全部迁移至飞天平台。在 2015 年 Sort Benchmark 排序竞赛中，飞天用 377 秒完成 100TB 的数据排序，打破四项世界纪录。随着阿里云的业务需求变化，伏羲的内涵也在不断扩大。最开始是作为一款对标开源 YARN 的单一资源调度器，而后扩展成了覆盖数据调度、资源调度、计算调度、单机调度等的核心调度系统，伏羲也于 2019 年经历了第二次重构，并将单集群规模扩展到了十万台。
双调度系统混部实践
伏羲是负责阿里离线业务的调度系统，而于 2015 年正式立项的 ASI 调度器则支撑着阿里搜索、电商等庞大的在线业务。在线调度历史也比较悠久，最早起源于 2011 年上线的 T4 系统，即阿里早期基于 LXC 和 Linux Kernel 定制的容器调度器。T4 的技术理念与如今云原生领域的核心技术——容器，如出一辙。
在线调度最开始是一个简单的资源分配系统，而后逐渐演进为 Sigma 调度器、ASI 调度器，在发展过程中又进一步吸收并融合了伏羲离线调度系统、搜索团队基于 YARN 的 Hippo 系统的先进经验。

文章图片

（0 层调度器负责全局资源视图和管理，并对 1 层调度器 Sigma、伏羲进行仲裁）
据称全球服务器平均利用率不到 20%，因此提升服务器的资源利用率是很多大厂不断追逐的目标。
2014 年左右，阿里巴巴开始大力探索混部技术，通过将在线业务和离线大数据计算的负载混部运行在共享的集群中，以期可以显著提高数据中心资源利用率。与离线调度不一样的是，类似双十一活动中的零点峰值场景，它对在线调度 CPU 的集群化编排要求非常高，对延迟和抖动敏感；离线业务正好相反，平时资源使用压力较高，业务资源使用较为固定，对时延不敏感。所以，只要两类负载能跑在共享的集群中使用“分时复用”的策略，就可以达到提升利用率的目的。
正是因为在线离线混部对于提高集群利用率非常有意义，所以无论是在学术界，还是在各大厂商实际落地中，都对混部做了深入的研究，各大企业中最早做混部实践的是谷歌 Borg。虽然有 Borg、Omega 先例存在，但谷歌很少对外分享自己的混部实践，仅在 2015 年、2019 年对外发布过两篇论文。这也意味着，如果想做好“混部”调度，企业都得靠自己去摸索。阿里的混部实践也于 2015 年正式立项，并于当年的双十一经历了一次资源调度能力的“考验”。据公开资料显示，混部能将阿里云的 CPU 资源利用率从 10% 提升到 40%。
作为自研的调度系统，伏羲和 Sigma 运行在一起，这种混部系统形式曾存在很多干扰和影响，一方面是两个系统之间节点状态不一致造成的干扰，另一方面是两个系统所分配的容器互相之间的干扰。然而“混部”带来的收益又不可忽视，因此阿里于 2016 年开始重点研发了 Sigma 1.0，基于 Docker Swarm 通道创建容器，并将演进中的各种语言技术栈统一为 Golang，同时在实践层面做了很多隔离、协同的优化工作，也将不同等级的任务调度做得更精细化。
整个演进过程中，调度团队也曾将实践成果分享为数篇顶会论文，得到了学术界和工业界的认可。有意思的是，谷歌曾在 2019 年 11 月分享了 Borg 集群运行数据，在对应的论文中谷歌特地指出其系统很少在集群中使用超过 50% 的内存，但据报道竞争对手阿里巴巴达到了 80% 的利用率。
大船难调头，阿里的调度系统发展了十多年，成果斐然，性能优异，运行的业务规模也是数千万级别了，但 2021 年，阿里云还是决定将伏羲、Sigma 双调度协同系统重构为基于 ACK 的“统一调度系统”。
基于阿里云容器服务 ACK 的调度系统
我们在技术上到达了一个新的临界点。
2020 年 6 月，阿里云集结了 100 多位调度团队核心技术人员，开始了重构的进程。
经过一年多的研发，赶在双十一之前，将数千万量级的业务切换到了新一代的“统一调度系统”上。新框架基于阿里云容器服务 Kubernetes 版（简称容器服务 ACK），通过一套调度协议、一套系统架构，统一管理底层的计算、存储、网络资源。ACK 本身提供了一个全托管的 Kubernetes 集群的调度能力，对于 IaaS 层不同类型的计算、存储、网络等能力都可以统一调度，是统一调度大资源池化生产运行的基座。
2021 年双十一，新系统打通并统一了阿里巴巴电商、搜推广、MaxCompute 大数据和蚂蚁业务，全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
为什么要重建？
Kubernetes 项目始于 2014 年，源自谷歌内部的 Borg，吸收了 Borg 项目多年的实践经验，它超前引入了 Pod 概念将容器分组，大量使用了 Sidecar 设计模式，为容器化应用提供了自动化的资源调度，并具备动态扩容、滚动升级、负载均衡、服务发现等功能，受到大厂的大力推崇。
在接下来的两年里，与其对应的 Mesos、Docker Swarm 等相比，Kubernetes 作为容器编排引擎的采用缓慢却很稳定，领先的科技巨头如亚马逊、阿里巴巴、微软 Azure、红帽都开始启动了基于 Kubernetes 的新解决方案。
2019 年，Sigma 全面迁移到了基于 ACK 的调度系统。同时，在这几年里，阿里的技术体系也逐渐全面切向云原生技术，去年 9 月，阿里云容器服务全面升级为 ACK Anywhere。

文章图片

据在线调度系统负责人智清回忆，在线调度系统最初是完全自研的，云原生兴起之后，在线调度团队于 2017 年决定将这套技术框架迁移到 Kubernetes，消除两者之间的差异并跑在阿里云容器服务 ACK 上。“刚开始是比较艰难的，尝试过好多版本，包括 Sigma on Kubernetes、Kubernetes on Sigma 等方式，最后还是决定用最标准、最原生的、完全基于 Kubernetes 的方式。”后面启动的 ASI 项目，它做的事情就是将整个调度框架以非常原生的标准方式搬到 Kubernetes 上，在 Kubernetes 基础上做到在线、离线调度的真正融合。而且在业务侧，阿里也专门组织了一支云原生团队来推进容器化，最终形成一个整体的云原生资源池。
云原生统一调度架构师懿川将这些年调度系统的发展过程总结为三个阶段：
第一个阶段是非容器阶段，仅有调度的需求，并且基础设施还没有完善，属于调度的最初期阶段。在这个阶段，无论是伏羲还是 T4，基本都是借助一些比较简单的隔离概念，以及一些内核的能力，靠自身的演进来实现对调度的最朴素的需求。
第二个阶段是开始进入容器阶段。容器技术使用场景变多，规模变大，Sigma 以容器为主进行了改造。在这个阶段，需要调度系统既能承接业务的需求，又能同时深耕容器技术。
第三个阶段是云原生化，调度系统完全基于新一代的容器技术，包含阿里自己的安全容器、RunC 以及其他的虚拟化技术，同时调度器的实现框架上也需适应整个 Kubernetes 生态。也就是将电商、搜索和大促这种创造洪峰型的业务，以及十多年调度系统技术积累，再结合 Kubernetes 开源架构的优势，整合到一起进行大规模应用。
总而言之，阿里重建调度系统的决策，是基于业务演进的需要，也是希望能有一个全局资源池，统一支撑所有业务形态。
云计算的本质，是将小的计算碎片变成更大的资源池，充分削峰填谷，提供极致的能效比。混部技术打破了多资源池的割裂，不同计算领域的多调度大脑协同共用资源，让业务间峰谷互补的优势发挥到最大，但两个调度器，由于彼此间无法高效地交互细粒度信息，阻碍了混部效果的进一步提升。
另外调度成本、资源的调度效率和业务独占资源池有很大的关系。从过去的调度系统演进经验来推断，建设统一资源池是最好的提升效率的方法：业务上有很多共同性的调度需求是可以互相配合和优化借鉴的，各自演进并不利于发展。无论是搜索还是电商，在线还是离线，如果作业类型越来越相近的话，就可以通过合作和共建，作为同一种调度类型去建设和演进，集中力量将云原生终态方案一起做到极致，并希望最后能做到自研、商用、开源三位一体。
双调度系统协同的方式跟谷歌的 Borg 或微软的系统相比，在集群管理模式上有一定的区别，那是否是因为双调度系统协同模式存在缺陷才会导致重构？回复 InfoQ 的采访时，懿川认为调度系统的发展和业务形态密切相关。国内很多企业确实会存在拥有多种调度系统的情况，原因是在线业务和离线业务特点有很大的不同，性能、吞吐量、任务长短类型等，以及对调度业务的需求决定了调度器的架构设计。
“反倒是做成一个统一的调度系统是比较难的，做成多种调度系统相对来讲更容易。而且类似谷歌的Borg或微软的Apollo系统一开始也不是所有的调度策略、逻辑以及场景都能支持，也有一个在演进过程中逐步增加功能的过程。”
新调度系统对 Kubernetes 的改进和增强
新调度系统需要支持在线离线、低频高频各种调度类型和众多业务种类，且要完全兼容 Kubernetes 生态，还需要是模块化、组件化，形成一个可插拔式的机制。

文章图片

统一调度团队针对 Kubernetes 社区版在 Pod 和资源安全上做了很多优化，围绕 API Server、ETCD、Kubelet 做了不少功能优化和代码修改。统一调度在 Pod 和接口调用上也做了很多安全防御方面的事情，例如 ETCD 错配或出现其它问题时如何进行防护，从而保证底座平台的安全。但最重要的两方面改造在单集群规模、调度频次性能上。
Kubernetes 早期版本仅支持几百节点的单集群规模，与 Mesos 支持的节点数量相去甚远，各大厂集合力量一起大幅提升了 Kubernetes 的集群管理规模，到 1.9 版本就已可以稳定支持 5000 个节点，但远达不到阿里原来调度系统单集群上万节点的性能要求。并且 Kubernetes 以 API Server 为中心的消息同步机制，更适用于调度频度较低的在线服务场景，对于阿里系统中的大数据计算场景，可达每秒 10 万次的调度频度。所以“尽管 Kubernetes 已经演进很久了，但是在我们的调度器上仍然需要投入大量的工作来改造，才能够满足我们的要求。”
如果要问哪些历史经验有助于新系统重构的话，集群管理规模的突破必定是其中之一。
2013 年的飞天 5K 项目，已经早早突破了单集群 5000 节点的规模。在后面的演进中，伏羲再次经历了第二次重构，据伏羲分布式调度负责人李超回忆说，当时主要考虑到“现在集群的规模可能动不动就过万台，不光是物理节点在增加，CPU 的处理能力也在不断增强。5 年前一台物理机上一般二三十个 CPU core，现在一台物理机节点里已经变成了一百多个 CPU core 了。相当于即便物理机节点不增加，可调度的总资源扩大了五六倍，甚至扩大了一个数量级，这对调度的挑战是很大的。”
“如果规模无限扩展下去，在架构和设计上也要有一个应对的方案。随着规模继续变大，我们也要 Hold 得住。”
在伏羲 2.0 资源调度的重构里，伏羲团队提出了一些比较新颖的观点，在混部中引入去中心化的多调度器架构，基于悲观锁这种 Partition 策略，解决调度之间的冲突，保证调度 latency 性能达到与小规模下的系统相同的水平。
但 Kubernetes 单集群规模有限，远不能满足今天的诉求。统一调度团队通过对 API Server 和 ETCD 的算法优化、在服务端进行数据压缩以及链路治理的方式，将集群规模从8千台（2020年）扩展到1.2 万台（2021年）节点，而业界一般达到8千台就已经是超大规模。
此外，由于 Kubernetes 容器拉起的时间在几秒甚至几十秒，如果需要做到一秒钟有十万次的调度，也必须对其进行大量改造。
统一调度团队参考了 Kubernetes 社区 scheduler framework 插件化和多调度机制，通过灵活的调度框架让不同的调度团队可以定制各自的调度需求，从而让 Kubernetes 能够很好的去支持一些场景下的大规模高并发的调度需求。比如在阿里大数据场景下，对调度系统的要求是每秒钟能发生十万次调度。
飞行中更换引擎
2021 年双十一之前，伏羲和 ASI 调度系统中的机器和计算资源已迁移到了统一调度系统，仅伏羲就包含几万台机器、数百万核计算资源，迁移过程需全程对业务和用户透明无感。
同时这个系统本身是一个涉及非常多人的协同项目，中间涉及到一次完整的系统重新设计和实现，还要将原有积累的伏羲、Sigma、ASI 以及 Hippo 的设计经验融合进来，且保持对业务的兼容性和对开源框架的兼容性。
可以说，整体设计非常复杂，代码开发涉及的耦合也很高，各个系统之间还存在各种对接。
以伏羲为例，在阿里 MaxCompute 技术体系中，伏羲一方面是分布式系统的资源管理和调度组件，需要与上层作业执行引擎进行资源交互，另一方面也是各种运维管控的数据源，复杂的模块依赖决定了系统升级是一件非常艰巨的事情。如果将 MaxCompute 比作一架高速飞行的飞机，统一调度升级就是要给这架飞行中的飞机更换引擎，难度可想而知。
“留给我们上线的时间窗口很小，但整体的业务要求却很高。双十一的时间点是摆在那里的一个硬性指标，我们不可能错过。”懿川介绍项目背景时讲到。
在这种情况下，要让新系统在“双十一”大促中表现得更有保障，李超表示主要有两大技术举措：
第一是灰度上线之前，有专门的风洞测试机制，它能把历史上真实生产的一些需求、请求在测试环境去做回放（Replay），从而验证经过新一轮的修改或者新的功能后系统是否能稳定上线。
第二是在稳定性上，在状态的可恢复上，传统的方式是基于 Kubernetes ETCD 的持久化机制，但是因为大数据的调度频率达到每秒十万次的调度，这种状态要做持久化保障是比较困难的。新系统引入了软硬状态 fail over 机制，简单来说是基于这个状态的重新收集，而不是完全依赖于状态的持久化。在不同的角色上去收集状态，重建调度器当时的状态。
另外在工程上也需要一套很严格的实施和上线机制：

保证代码高质量和低缺陷率，并做好全面的单元测试，平时基本功扎实才能保证最终的工程质量。
上线之前，用接近真实生产的环境进行测试和验证，确保能够跑通，如果出现问题及时解决和处理，符合整体的上线进度。“我们最后上伏羲集群的过程中，出现的问题都是日清日结，让问题快速收敛，保证整个集群的交付可以符合要求。”
分阶段灰度测试。第一阶段用小规模的迁移，“当时只是用几十台节点机器统一调度跑起来，再到后面就逐渐放大规模”，而且还需要先从重要程度相对低的业务开始切换，并保证足够长的灰度时间，最后才在线全面铺开，没问题后再将更复杂的离线调度引入混部运行。
保证每天有一定的切换量，最终将系统按时切完。“当然这也有一定运气成分在：我们没有出现特别严重的问题，这也非常考验整个项目成员的设计和实现的功底。当然也需要我们有整体的机制和流程的保障。”
系统需要一个完善的监控机制。“上线一个系统之前，我们先得想好怎么去监测它。观测方方面面的上百个维度的元数据是不是正常，通过完善的监测，系统一旦出现问题，我们能第一时间发现，做一些回滚动作，或者提前准备好一些处理机制，来保证用户受到影响之前系统能够恢复到一个正常的状态。”

未来规划
每个技术都有自己的生命周期，十多年前大家很难想到 Kubernetes 会成为当今技术界的扛把子，而技术演进过程中，开发者的使命就是用最合适的技术来构建我们的系统。使用新技术不代表过去的经验和成果不再有价值，统一调度系统也是吸取了伏羲和 Sigma 系统构建中的精华。
【技术抉择（阿里云13年后重构全部核心调度系统）】开源技术影响着调度系统的演进，而部署在大型企业生产环境中的系统，无论是谷歌的Borg、微软的Apollo 还是脸书的 Twine，反过来也在影响开源项目的系统演进。统一调度团队表示，未来会进一步提升和完善整个调度器的功能和能力，继续往2.0推进；另一方面，要完成自研、商用、开源三位一体的目标，作为战略计划推进项目的开源，包括开源关键能力和标准、框架。建设这样一个超级系统，投入和挑战都非常大，而开源能够将更多的人聚集起来，一起把这套系统做得更好。
采访嘉宾简介：
懿川，阿里巴巴研究员，云原生统一调度架构师。全面负责统一调度项目，在分布式领域和资源管理领域有多年的经验积累。
李超，阿里云智能计算平台事业部资深技术专家，飞天平台伏羲分布式调度负责人，拥有十多年分布式系统与大数据研发经验。
智清，阿里云智能容器服务资深技术专家，ASI 调度系统负责人，负责了阿里巴巴在线调度从 Sigma、ASI、到全面统一调度的迭代演进。
原文链接
本文为阿里云原创内容，未经允许不得转载。