ReaderMX.
阿里巴巴中间件

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

阿Tina约 16 分钟
编辑 | Tina
在阿里云十三年的发展历史上，重新设计调度系统算得上是一个重要的技术抉择。
云计算是一个庞大的技术工程。2009 年，阿里云从 0 到 1 自建国产云计算系统“飞天”，为了确保对每一行代码都有控制力，阿里云选择了一条艰难的道路：自主研发。伏羲调度系统是“飞天”三大服务之一。调度系统作为云计算的核心技术，无论是对亚马逊、谷歌还是其他云计算企业来说，都是他们最保守的秘密，而伏羲凭借自研与优异的性能，与 YARN、Mesos 等技术一起成为了调度系统的典型代表之一。
这么多年发展下来，很多人认为阿里云战略上最与众不同之处，就是坚持自研核心技术。作为全球集群规模最大的云计算平台之一，阿里云在技术已然成熟、稳定运行着数量庞大的业务情况下，选择了用云原生的标准重新设计和构建云计算的调度系统，并在 2021 年“双十一”大促之前将全球几十个数据中心、数百万容器、数千万核的资源统统搬到了新的调度系统之上。
阿里云为什么在十三年之后重构调度系统？在不影响业务运行的情况下，阿里云是如何更换“引擎”的？这种技术思路给我们带来什么启示？新调度系统有开源计划吗？InfoQ 采访了几位调度系统负责人，为大家一一解惑。
01

发展十三年，成绩斐然的老调度系统

Aliware

资源调度系统可谓是云计算的大脑，负责在众多集群内的机器里，选择一台最合适的，以最佳的资源使用姿势，做到最少的相互干扰来运行用户提交的计算作业。云计算最终目的之一是降低 IT 成本，最大限度地利用单台 PC 的 CPU 处理能力，而调度系统恰恰就决定着基础设施的利用率和整体运作成本。
无论是亚马逊、谷歌、微软还是阿里，某种程度上，“大脑”代表的是企业技术竞争力。核心技术的重要性不言而喻，像谷歌的调度系统 Borg，在很长一段时间内，一直是谷歌最保守的秘密之一。
02

艰难起步，从 0 到 1 自研伏羲调度系统

Aliware

2008 年，阿里巴巴确定了“云计算”战略，决定自主研发大规模分布式计算操作系统“飞天”，目标是将几千台乃至上万台普通 PC 服务器连接到一起，使其像一台多功能的超级计算机，实现超强计算性能。
2009 年 2 月，飞天团队在北京写下了第一行代码，“飞天”系统也从此成为阿里云的奠基技术平台。伏羲调度系统是十年前飞天成立时创建的三大服务之一，另两个是飞天分布式存储盘古和分布式计算 MaxCompute。
2011 年 7 月，阿里云作为中国第一个公有云正式对外开放。这之后的十多年里，伏羲能调度的单集群规模，也从最初的几百台物理机，发展到了 10 万台机器。我们知道，规模每放大十倍，就意味着很多架构设计点都需要重新调整，当横向扩展遭遇不可逾越的瓶颈，就代表着系统重构的开始，伏羲就因此经历了两次重构。
2013 年，伏羲在飞天“5K”项目中对系统架构进行了第一次大重构。“5K”顾名思义，就是能让调度系统支持单集群 5000 节点，并解决大规模单集群下的性能、利用率、容错等问题。
不断扩大单集群的规模，到现在依然是业界不同调度系统在做的事情。
如果依靠早期的 Hadoop 开源调度器技术，以当时的实践经验来看，并不是容易的事情，因此伏羲团队选择了架构和代码都是自己构建的自研方式。这个项目，在阿里云历史上也是一次非常有里程碑意义的“攻坚战”。
（阿里飞天 5K 项目纪念碑）
随后历经一年半时间，阿里巴巴和蚂蚁金服完成“登月计划”，将所有数据存储、计算任务全部迁移至飞天平台。在 2015 年 Sort Benchmark 排序竞赛中，飞天用 377 秒完成 100TB 的数据排序，打破四项世界纪录。
随着阿里云的业务需求变化，伏羲的内涵也在不断扩大。最开始是作为一款对标开源 YARN 的单一资源调度器，而后扩展成了覆盖数据调度、资源调度、计算调度、单机调度等的核心调度系统，伏羲也于 2019 年经历了第二次重构，并将单集群规模扩展到了十万台。
03

双调度系统混部实践

Aliware

伏羲是负责阿里离线业务的调度系统，而于 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 的“统一调度系统”。
04

基于阿里云容器服务 ACK 的调度系统

Aliware

我们在技术上到达了一个新的临界点。
2020 年 6 月，阿里云集结了 100 多位调度团队核心技术人员，开始了重构的进程。
经过一年多的研发，赶在双十一之前，将数千万量级的业务切换到了新一代的“统一调度系统”上。新框架基于阿里云容器服务 Kubernetes 版（简称容器服务 ACK），通过一套调度协议、一套系统架构，统一管理底层的计算、存储、网络资源。ACK 本身提供了一个全托管的 Kubernetes 集群的调度能力，对于 IaaS 层不同类型的计算、存储、网络等能力都可以统一调度，是统一调度大资源池化生产运行的基座。
2021 年双十一，新系统打通并统一了阿里巴巴电商、搜推广、MaxCompute 大数据和蚂蚁业务，全面支撑了全球数十个数据中心、数百万容器、数千万核的大规模资源调度。
05

为什么要重建？

Aliware

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系统一开始也不是所有的调度策略、逻辑以及场景都能支持，也有一个在演进过程中逐步增加功能的过程。”
06

新调度系统对 Kubernetes 的改进和增强

Aliware

新调度系统需要支持在线离线、低频高频各种调度类型和众多业务种类，且要完全兼容 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 能够很好的去支持一些场景下的 大规模高并发的调度需求 。比如在阿里大数据场景下，对调度系统的要求是每秒钟能发生十万次调度。
07

飞行中更换引擎

Aliware

2021 年双十一之前，伏羲和 ASI 调度系统中的机器和计算资源已迁移到了统一调度系统，仅伏羲就包含几万台机器、数百万核计算资源，迁移过程需全程对业务和用户透明无感。
同时这个系统本身是一个涉及非常多人的协同项目，中间涉及到一次完整的系统重新设计和实现，还要将原有积累的伏羲、Sigma、ASI 以及 Hippo 的设计经验融合进来，且保持对业务的兼容性和对开源框架的兼容性。
可以说，整体设计非常复杂，代码开发涉及的耦合也很高，各个系统之间还存在各种对接。
以伏羲为例，在阿里 MaxCompute 技术体系中，伏羲一方面是分布式系统的资源管理和调度组件，需要与上层作业执行引擎进行资源交互，另一方面也是各种运维管控的数据源，复杂的模块依赖决定了系统升级是一件非常艰巨的事情。如果将 MaxCompute 比作一架高速飞行的飞机，统一调度升级就是要给这架飞行中的飞机更换引擎，难度可想而知。
“留给我们上线的时间窗口很小，但整体的业务要求却很高。双十一的时间点是摆在那里的一个硬性指标，我们不可能错过。”懿川介绍项目背景时讲到。
在这种情况下，要让新系统在“双十一”大促中表现得更有保障，李超表示主要有两大技术举措：
第一是灰度上线之前，有专门的 风洞测试机制 ，它能把历史上真实生产的一些需求、请求在测试环境去做回放（Replay），从而验证经过新一轮的修改或者新的功能后系统是否能稳定上线。
第二是在稳定性上，在 状态的可恢复 上，传统的方式是基于 Kubernetes ETCD 的持久化机制，但是因为大数据的调度频率达到每秒十万次的调度，这种状态要做持久化保障是比较困难的。新系统引入了软硬状态 fail over 机制，简单来说是基于这个状态的重新收集，而不是完全依赖于状态的持久化。在不同的角色上去收集状态，重建调度器当时的状态。
另外在工程上也需要一套很严格的实施和上线机制：
  • 保证代码高质量和低缺陷率，并做好全面的单元测试，平时基本功扎实才能保证最终的工程质量。
  • 上线之前，用接近真实生产的环境进行测试和验证，确保能够跑通，如果出现问题及时解决和处理，符合整体的上线进度。“我们最后上伏羲集群的过程中，出现的问题都是日清日结，让问题快速收敛，保证整个集群的交付可以符合要求。”
  • 分阶段灰度测试。第一阶段用小规模的迁移，“当时只是用几十台节点机器统一调度跑起来，再到后面就逐渐放大规模”，而且还需要先从重要程度相对低的业务开始切换，并保证足够长的灰度时间，最后才在线全面铺开，没问题后再将更复杂的离线调度引入混部运行。
  • 保证每天有一定的切换量，最终将系统按时切完。“当然这也有一定运气成分在：我们没有出现特别严重的问题，这也非常考验整个项目成员的设计和实现的功底。当然也需要我们有整体的机制和流程的保障。”
  • 系统需要一个完善的监控机制。“上线一个系统之前，我们先得想好怎么去监测它。观测方方面面的上百个维度的元数据是不是正常，通过完善的监测，系统一旦出现问题，我们能第一时间发现，做一些回滚动作，或者提前准备好一些处理机制，来保证用户受到影响之前系统能够恢复到一个正常的状态。”
    08

    未来规划

    Aliware

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

KEEP THE THREAD GOING

更多来源文章