作者 | 黄涛、汪萌海
起源 | 阿里巴巴云原生公众号
作为更进一步的云计算状态，云原生正在成为云时代的技术新规范，通过重塑整个软件生命周期，成为开释云价值的最短门路。
在企业外部，将云原生基础架构作为企业外部的对立架构已成为大势所趋。与此同时，也必然带来了由各种根底平台整合带来的兼容性问题，特地是规模越大、历史积淀越多的企业，这种“技术债权”体现得越显著。
本文分享的教训来自于阿里巴巴过来数年来在混合调度方面积攒的生产实践积攒，具备很强的生产实用价值。内容由浅入门，逐步深刻到调度器底细，讲述在大规模容器调度场景下，阿里巴巴针对云原生利用设计的对立基础设施 ASI（Alibaba Serverless infrastructure）调度器如何治理阿里巴巴如此简单、忙碌的资源调度工作；并尝试通过一些具体的案例让您得以充沛了解，置信会为有相似问题的读者关上设计思路，并提供落地借鉴。通过本文，置信您将系统地了解阿里巴巴简单工作场景下的资源混合调度。
调度器总览
ASI 在阿里团体外部引领着容器全面上云的施行，承当了包含阿里团体外部轻量级容器架构演进、运维体系云原生化等职责，并进一步减速促成了新兴的技术包含 Mesh、Serverless、Faas 等在阿里团体内的落地；撑持了包含淘宝、天猫、优酷、高德、饿了么、UC、考拉等简直所有经济体外部业务、阿里云云产品泛滥场景及生态。
ASI 的外围基于 Kubernetes，并提供残缺的云原生技术栈反对。现在的 ASI 也已胜利实现与阿里云容器服务 ACK（Alibaba Cloud Container Service for Kubernetes）的会师；而 ACK 既保留了云上的各种能力，也能胜利应答阿里团体简单的业务环境。
ASI 调度器是 ASI 云原生的外围组件之一。在 ASI 云原生的倒退历程中，调度器的作用至关重要。最直观的认知是：阿里巴巴规模宏大的在线电商交易容器，例如购物车、订单、淘宝详情等，每一台容器的散布，包含容器编排、单机计算资源、内存资源，均由调度器调配和调度；特地是在 双 11 零点峰值场景下，多数容器编排谬误都有可能给业务带来致命影响，调度器需负责把控峰值时每一台容器计算的品质，其重要性可想而知。
ASI 调度器起源于 2015 年在线电商交易容器调度，这一年最早的调度器仅涵盖在线交易 T4（阿里晚期基于 LXC 和 Linux Kernel 定制的容器技术）和 Alidocker 场景，出世即责任重大，并在 2015 年扛住 双 11 流量峰值中发挥作用。
ASI 调度器的演进之路也随同着云原生倒退的全过程。它经验了最晚期的在线交易容器调度器、Sigma 调度器、Cerebulum 调度器、ASI 调度器；到现在咱们正在建设的下一代调度器 Unified-Scheduler，它将进一步排汇并交融过来数年阿里巴巴 ODPS（伏羲）、Hippo 搜寻、在线调度在各个领域的先进经验。各阶段的调度解读如下图：
在 ASI 调度器的演进过程中有十分多的挑战须要解决，次要体现在：
- 调度器调度的工作品种丰盛多样，有海量的在线长生命周期容器和 POD 实例、Batch 工作、泛滥状态的 BestEffort 工作等不同 SLO 等级的工作；有计算型、存储型、网络型、异构型等泛滥不同资源类型的工作，不同工作的诉求和场景又千差万别。
- 调度之上的宿主资源各异。调度治理着阿里团体外部数量宏大的宿主资源，包含泛滥机型的存量非云物理机、云上神龙、ECS、异构机型如 GPU/FPGA 等。
- 调度器服务场景宽泛。例如：最典型的泛交易场景；最简单的中间件场景；Faas/Serverless/Mesh/Job 等泛滥新兴计算场景；饿了么、考拉、神马等新兴生态场景；公共云上随同着多租平安隔离的调度诉求；还有寰球范畴内都十分具备挑战性的 ODPS（伏羲）、Hippo、蚂蚁、ASI 对立调度场景。
- 在基础设施层的职责泛滥。调度器局部承当着基础设施机型定义、计算存储网络资源整合、收敛硬件状态、透明化基础设施等泛滥职责。
对于阿里云原生具体的倒退历程，有趣味的同学能够通过《一个扭转世界的“箱子”》这篇文章来理解。上面，咱们重点来分享 ASI 调度器是如何治理着阿里如此宏大规模、如此简单忙碌的计算资源调度工作。
调度器初探
1. 调度器是什么
调度器在 ASI 泛滥组件中的作用十分外围。调度器是云原生容器平台调度零碎内泛滥外围组件之一；调度器是资源交付的基石。调度器是 ASI 云原生的大脑。调度器的价值次要体现在：
- 能力弱小 & 场景丰盛的资源交付(计算、存储)
- 老本最优的资源交付
- 业务运行时稳固最优的资源交付
更艰深地讲，调度器要做的是：
- 一次作业调度的最优：在集群内抉择一台最合适的宿主机，并在这台宿主机上，以最佳的资源应用姿态，做到起码的互相烦扰（如 CPU 散布、IO 争抢）来运行用户提交的计算作业。
- 集群全局调度的最优：确保全局资源编排最优（如碎片等）、资源运行最稳固、全局老本最优。
在 ASI 云原生体系中，核心调度器所在的地位如下图（其中标红的框框所示）：
2. 狭义的调度器
在大部分时候，业界讲到调度器指的是“核心调度器”，例如社区的 K8s kube-scheduler。但实在的调度场景简单，每一次调度都是一个简单又灵便的综合体协同。作业提交后，它须要核心调度器、单机调度、内核调度多层次调度独特协调，并进一步在 K8s 组件 kubelet、controller 等配合下实现执行；在线调度场景，又有着批量编排调度器；而重调度下的屡次调度则确保集群总是放弃最优。
ASI 狭义的调度器了解为：核心调度器、单机调度、内核调度、重调度、规模化编排调度、多层调度 一体的综合体。
1）核心调度器
核心调度器负责计算每一个（或一批）作业的资源编排计算，它确保一次调度最优。核心调度器为这个具体的工作计算确定诸如集群、地区、执行节点（宿主机）等信息，更进一步细化节点上的 CPU 调配、存储、网络资源调配。
核心调度器在 K8s 生态组件协同下，治理着大部分工作的生命周期。
ASI 云原生的演进之路中，核心调度器即上文形容的 Sigma 调度器、Cerebulum 调度器、ASI 调度器等等。
2）单机调度
次要负责两类职责：
第一类职责：兼顾协同单机内多 POD 的最佳运行。ASI 在承受到核心调度器的节点抉择指令后，将任务调度到具体的节点上执行，单机调度即开始工作：
- 单机调度将立即、或周期性、或运维式 动静确保单机内多 POD 的工作最优，这意味着它将在单机内兼顾协同资源，例如：每一个 POD 的 CPU 核调配的最佳调整。
- 实时依据 POD 的运行指标如负载、QPS 等，针对局部运行时资源执行单机内的 VPA 扩缩容、或对低优先级的工作执行驱赶等操作。例如：动静扩大 POD 的 CPU 容量。
第二类职责：单机资源信息的采集、上报、汇聚计算，为核心调度提供决策依据。在 ASI 内，单机调度组件次要指 SLO-Agent、Kubelet 的局部加强能力；在正在建设的 Unified-Scheduler 调度内，单机调度次要指 SLO-Agent、Task-Agent、以及 Kubelet 的局部加强能力。
3）内核调度
单机调度从资源视角兼顾单机内多 POD 的最佳运行，但工作的运行态理论由内核管制。这就须要内核调度。
4）重调度
核心调度器确保了每次工作的最佳调度，即一次性调度问题；但核心调度器并不能实现集群维度的全局最优，这就须要重调度。
5）规模化编排调度
规模化编排调度是阿里巴巴大规模在线调度的特有场景，自 17 年开始建设，当初曾经十分成熟，并仍在继续加强中。
利用规模化编排能力，咱们能够一次性调度数万、数十万容器，一次性确保集群维度所有容器的全局最佳编排。它十分奇妙地补救了一次性核心调度的弊病，躲避了大规模建站场景下需重复重调度的复杂度。
对于 内核调度、重调度、规模化编排调度，咱们将在上面的章节中具体开展。
6）调度分层
另一个维度，咱们也会定义调度分层，包含 一层调度、二层调度、三层调度 … 等；Sigma 在离线混部场景甚至引入了零层调度的概念。每个调度系统对调度分层的了解和定义会不一样，并都有各自的概念。例如，在过来的 Sigma 体系内，调度分为 0 层、1 层 和 2 层调度：
- 0 层调度器负责的职责是负责全局资源视图和治理，并承接各个 1 层调度间的调度仲裁，以及具体执行；1 层调度次要是对应 Sigma 调度器、伏羲调度器 [也能够蕴含其它调度器]。
- 在 Sigma 体系中，Sigma 调度器作为 1 层调度，负责资源层的调配。
- 2 层调度交由不同的接入业务各自实现（例如电商交易、广告 Captain、数据库 AliDB 等）。2 层调度充沛贴近和了解各自业务，并站在业务全局视角做泛滥优化，建设调度能力，如业务驱赶、有状态利用故障主动运维等，做到贴心服务。
Sigma 的调度分层体系的致命弊病是，各个二层调度的技术能力和投入参差不齐；例如广告的二层调度零碎十分优良，但并不是所有的二层调度对业务贴心到极致。ASI 吸取教训，将泛滥能力下沉至 ASI 内，并进一步标准化下层 PAAS，简化下层的同时加强下层能力。
而明天正在建设的下一代调度器概念内，也分为多层，例如：计算负载层（次要指 Workload 的调度治理）、计算调度层（如 DAG 调度、MR 调度等）、业务层（同 Sigma 2 层的概念）。
3. 调度资源类型
我尝试用正在建设的 Unified-Scheduler 调度器来让大家更好地了解。在 Unified-Scheduler 调度器内，调度着 Product 资源、Batch 资源、BE 计算资源三种分等级的资源状态。
不同调度器对分等级的资源状态有不同的定义，但实质上大同小异。为了让大家更好地了解这一精华，我在后续的章节对 ASI 调度器也做了具体解说。
1）Product（在线）资源
有 Quota 估算的资源，且调度器需保障其最高级别的资源可用性。典型代表是在线电商外围交易的长生命周期 POD 实例。最经典的例子就是 双 11 外围链路上的购物车（Cart2）、订单（tradeplatform2）等交易外围的业务 POD。这些资源要求算力的严格保障、高优先级、实时性、响应低延时、不可被烦扰等等。
举例来说，在线交易的长生命周期 POD 的存在工夫很长，数天、数月、甚至数年。大部分利用研发同学申请的利用，在构建结束后须要申请数台长生命周期实例，这些都是 Product 资源。淘宝、天猫、聚划算、高德、友盟、合一、菜鸟、国际化、闲鱼 …. 等等泛滥业务研发同学申请的 POD（或容器）实例，相当大部分都是 product 资源。
Product 资源不仅仅指在线长生命周期的 POD；但凡合乎上述定义的资源申请，都是 Product 资源。但并不是所有的长生命周期 POD 都是 Product 资源。例如阿里外部“Aone 实验室”用于执行 CI 构建工作的 POD，能够长生命周期存在，但它能够被低成本驱赶抢占。
2）Batch 资源
在线业务应用的 Product 资源的 Allocate 和 Usage 之间的 Gap 在一段时间内是比较稳定的，这个 Gap 和 Prod 未调配的资源就作为 BE 资源，售卖给针对 latency 不那么敏感和然而对资源稳定性有肯定需要的业务。Batch 有 quota 估算，然而保障一段时间内（例如 10 分钟）的肯定概率（例如 90%）的资源可用性。
也就是说，Product（在线）资源申请走了账面上的资源，但实际上从负载利用率指标来看可能有泛滥算力未被应用；此时将施展调度器的差异化 SLO 分等级调度能力，将那些未跑满的局部，作为超发资源充沛应用，售卖给 Batch 资源。
3）Best Effort(BE)资源
指没有 Quota 估算，不保障资源可用性，随时能够被压抑和抢占；节点上已调配在节点的 Usage 低于一个水位的时候，调度器认为这部分 Gap 是一个“比拟不稳固 / 不记账”的资源，那么这个 Gap 就称为 BE 资源。
咱们能够这样来比如：Product、Batch 资源负责大块吃肉，BE 资源则负责生产 Product 和 Batch 不要的残渣。例如：日常开发工作中，研发须要跑很多 UT 测试工作，这类计算工作对计算资源的品质要求并不高，工夫延时的容忍度也比拟高，也不大好评估额度估算，针对这类场景去购买大量的 Product 或者 Batch 资源，将十分不划算；但如果应用最便宜的 BE 资源，收益将相当可观。此时，BE 资源就是 Product/Batch 运行中没有用到的资源。
很容易了解到，正是通过这种分等级的资源调度能力，从技术层面，Unified-Scheduler 调度器能够将一台物理节点的资源应用，施展到极致。
调度器能力总览
下图是 ASI 围绕着狭义调度需笼罩的职责，并对应不同资源等级诉求、以及服务的丰盛业务场景，构建的调度能力总览。通过这张图，大家能够了解到 ASI 调度器的技术全貌。
典型在线调度能力
1. 在线调度的业务诉求
在 ASI 云原生容器平台上，在线局部服务着交易、导购、直播、视频、本地生存、菜鸟、高德、合一、友盟、海内等数十个 BU 的各类调度场景。其中最高等级的“Product 资源”的调度占比最为宏大。
在线业务的调度与离线调度、泛滥 JOB 型调度相比拟，有着典型的差别（形容在线场景时，大家能够设想到，离线调度的世界同样精彩）。
1）生命周期
- Long Running：在线利用的容器生命周期广泛都比拟长。少则数天，大部分以月计，局部长尾利用甚至存活数年。
- 启动工夫长：利用的镜像体积大，下载镜像工夫较长，服务启动内存预热等等，这导致利用启动工夫在几秒、数十分钟都有。
长生命周期的个性，与一些典型的短生命周期任务调度（如 FaaS 函数计算），在工作特色上有着实质的不同，背地的技术挑战也截然不同。例如：绝对短生命周期的函数计算场景的挑战是：最极致的调度效率、百毫秒的执行效率、疾速的调度吞吐、POD 运行时性能等。而长生命周期 POD 带来的差异化挑战是：全局最优的调度必须依赖重调度来继续迭代优化；运行时的最佳调度必须依赖单机重调度继续优化保障。能够设想，在过来非云原生时代，泛滥业务不可迁徙，对调度而言几乎是噩梦；这意味着调度器不仅仅面对调度能力的技术问题，还需面对难度微小的存量业务治理推动；在线利用的启动工夫长，又更加剧升高了重调度的灵便度，带来更多的复杂度。
2）容器运行时
- 容器运行时须要反对业务的实时交互、疾速响应、低业务 RT 等诉求。在线容器运行时，大部分零碎需承担实时交互职责，并对提早异样敏感，稍大的提早将带来显著蹩脚的业务体感。
- 资源特色显著：如网络消耗型、IO 消耗型、计算消耗型等等。雷同特色的实例共存时，极易产生彼此间的显著资源争抢。
在线容器的运行时因为对业务和算力都十分敏感，因而对调度品质提出了十分刻薄的挑战。
3）应答阿里在线利用特有的简单业务模型
- 流量高下峰特色：在线业务的服务个别都会有比拟显著的高下峰，例如饿了么的顶峰是在中午和早晨、淘宝的顶峰也有显著的波谷和峰值。
- 突发流量：业务的复杂度，导致这些突发流量并不一定能出现肯定法则；例如直播业务可能因为某个突发的事件导致流量激增。突发流量背地的技术诉求往往是弹性，最经典的案例是 2020 年疫情期间的钉钉弹性诉求。
- 资源冗余：在线业务从出世的那一刻开始，就定义了冗余资源；这次要是出于容灾的思考。但站在阿里巴巴全局视角，相当多的长尾利用因规模小而对老本和利用率不敏感，千里之行; 始于足下，背地是微小的算力节约。
4）特有的规模化运维诉求
- 简单的部署模型：例如：须要反对利用单元化部署，多机房容灾，小流量、灰度、正式多环境部署的简单调度需要。
- 大促 & 秒杀的规模化峰值特色：阿里巴巴的各种大促贯通全年，比方大家相熟的 双 11、双 12、春节红包等等。整个链路上的利用压力、资源耗费都会随着大促峰值流量的增长成倍增加，这须要调度器弱小的规模化调度能力。
- 大促建站：大促的工夫是计划性的，为了节约云资源的洽购老本，必须尽可能升高云资源的保有工夫。调度器需最快速度实现大促前的建站，并在大促后疾速偿还资源到阿里云。这意味着极其严苛的规模化调度效率诉求，并把更多的工夫留给业务。
2. 一次调度：调度根本能力
下表详细描述了在线调度最常见的调度能力：
- 利用根本诉求对应的是：利用扩容对应的根本诉求，例如 POD 规格、OS 等。在 ASI 调度器内，它被形象为一般的 label 匹配调度。
- 容灾与打散：locality 调度，ASI 曾经通过各种伎俩获取到诸多详细信息，例如上图中的 网络外围、ASW 等。
- 高级策略：ASI 会尽可能标准化、通用化业务诉求，但依然不可避免地存在一些业务，对资源、运行时有泛滥特定要求，例如特定的基础设施环境如硬件等、容器能力的特定诉求如 HostConfig 参数、内核参数诉求等。
- 对于调度规定核心：业务对策略的特定要求，决定了调度背地还将对应一个弱小的调度策略核心，它领导着调度器应用正确的调度规定；调度规定核心的数据来自于学习，或专家运维教训。调度器驳回这些规定，并利用于每一个 POD 的扩容调配中。
3. 利用间编排策略
因集群节点数量无限，彼此潜在烦扰的泛滥利用，不得已需在同一节点并存时，这时就须要利用间编排策略，来确保每一个宿主节点和每一个 POD 运行时最优。
理论的调度生产实践中，“业务稳定性”永远是排在第一位，但资源却总是无限的；咱们很难均衡“资源老本最优”和“业务稳定性”。大部分状况下，利用间编排策略都能完满地解决这一均衡；通过定义利用之间（如 CPU 耗费密集型、网络消耗型、IO 密集型、峰值模型特色等）的并存策略，集群内充沛打散，或同一节点并存时又有充沛的策略束缚爱护，进而做到不同 POD 间的烦扰概率最小。
更进一步，调度器在运行时辅以更多技术手段优化，例如：通过网络优先级管制、CPU 精密编排管制等策略，来尽可能躲避利用间运行时的潜在影响。
利用间编排策略带来的其它挑战是：调度器在建设好本职的利用间编排能力外，还需充沛了解其上运行的每一个业务运行特色。
4. CPU 精细化编排
CPU 精密编排在“在线调度畛域”内是十分有意思的话题，它包含 CpuSet 调度、CpuShare 调度。其它场景的调度畛域，例如离线调度畛域，它并没有这么重要，甚至不可被了解；但在线交易场景下，无论是实践推断、实验室场景、还是无数次大促压测数据，都证实了精准的 CPU 调度就是这么重要。
CPU 精密编排的一句话解读是：调核，确保 CPU 核最大化、最稳固地被应用。
CPU 精密编排如此重要，以至于 ASI 在过来的数年，曾经将这一规定吃透并应用到了极致。置信您在看到下表后（仅含 CpuSet 精密编排调度），您也会感叹 ASI 甚至曾经将它玩出了花色。
科普：以一台 96 核（实际上咱们说的都是 96 个逻辑核）的 X86 架构物理机或神龙为例，它有 2 个 Socket，每个 Socket 有 48 个物理核，每个物理核下有 2 个逻辑核。【当然，ARM 的架构又与 X86 不同】。
因为 CPU 架构的 L1 L2 L3 Cache 设计，最现实的调配是：同一个物理核下的 2 个逻辑核，其中一个核 调配给最外围的在线交易利用如 Carts2（购物车业务），另一个核调配给另一个不忙碌的非核心利用；这样在日常、或 双 11 零点峰值时，Carts2 能够占尽便宜。这种用法，在理论的生产环境、压测演练环境中均屡试不爽。
如果咱们将同一个物理核上的两个逻辑核，都同时调配给 Carts2 时，因为业务峰值的雷同（尤其是同一个 POD 实例），资源的最大化应用就会大打折扣。
实践上咱们也应该尽量躲避两个同样都是交易外围的利用，例如 Carts2（购物车业务）、tradePlatform2（订单），使其不要去共用这两个逻辑核。但实际上在宏观层面，Carts2 和 tradePlatform2 的峰值会有差别，所以实际上影响还小。只管这样的 CPU 调配看起来有些“将就”；但物理资源总归是无限的，也只能放弃这份“将就”了。
而在 numa-aware 开启时，为了最大化应用 L3 Cache 来晋升计算性能，同一个 POD 的更多核，又应确保尽量躲避跨 Socket。
而当应用 CPUShare 时，Request 和 Limit 如何调配，也十分有学识；CPUSet 和 CPUShare 并存时，调度将更加简单（例如：CpuSet 容器的新扩容、或下线，潜在的诉求是整机所有 POD 的 CPU 重调度）；而在新兴的 GPU 异构调度场景下，CPU 与 GPU 的并存调配也具备肯定的技巧。
5. 规模化编排调度
规模化编排次要利用于建站、搬站或规模化迁徙场景，例如阿里巴巴频繁的大促建站、机房迁徙诉求下的超大规模搬站等。基于老本考量，咱们须要在尽可能短的工夫，以极少的人力老本疾速创立数十万级别 POD。
多个工作顺次申请的随机性和不可预见性，决定了核心调度在规模化畛域存在诸多弊病。在没有规模化编排能力之前，阿里巴巴大规模站点的建设，往往需经验简单的“业务自扩容 -> 重复重调度”的过程，这将消耗大量人力数周的精力。好在咱们有了规模化编排调度，在小时级规模化交付效率的同时，又能确保 99% 以上的资源分配率。
通用调度能力
1. 重调度
核心调度器做到了一次性最优调度；但与最终想要的集群维度全局调度最优，是两个齐全不一样的概念。重调度也包含全局核心重调度和单机重调度。
为什么肯定须要核心重调度作为一次性调度的弥补呢？咱们举几个例子：
- ASI 调度集群内存在泛滥长生命周期的 POD 实例；随着工夫的积攒，集群维度必将产生泛滥资源碎片、CPU 利用率不均等问题。
- 大核 POD 的调配须要动静的腾挪式调度能力（实时驱赶某些小核 POD 并闲暇出资源）、或基于提前布局的全局重调度，在泛滥节点上预闲暇一些大核。
- 资源供应总是缓和的。对某个 POD 做一次性调度时，可能存在肯定“将就”，这意味着某种瑕疵和不完满；但集群资源又是动态变化的，咱们能够在其后的某个时刻，对该 POD 发动动静迁徙，即重调度，这将带来业务更佳的运行时体验。
核心重调度的算法、实现上往往非常复杂。咱们须要深刻了解各类重调度场景并充沛笼罩，定义清晰的重调度 DAG 图，动静执行并确保执行的成功率。
泛滥场景也须要单机重调度。例如：CPU 精密编排的 SLO 优化、基于 OQS 数据驱动的单机重调度优化等。
须要强调的是，单机重调度的执行，必须先解决平安风控的问题，躲避不可控的爆炸半径。在单机侧风控能力有余前，咱们建议您暂不要采纳节点自治形式，而是改为严格爱护管制下的核心对立触发。实际上在 K8s 域内，会呈现十分多不可避免的节点自治场景（例如 pod yaml 变动时，Kubelet 将执行相应变更），过来 ASI 破费数年继续梳理每一个潜在的风控点，并迭代建设了分等级风控治理（核按钮、高危、中危等）的 Defender 零碎；针对潜在危险项，执行单机侧动作前，与核心的 Defender 交互，通过平安防控躲避劫难事件的产生。咱们倡议调度器必须同样做到紧密的平安进攻等级，才容许节点自治操作。
2. 内核调度
内核调度存在的背景是：一台并行运行着泛滥工作的忙碌宿主机，即便核心调度 & 单机调度，已独特确保其最佳资源分配（如 CPU 调配、IO 打散等），但理论运行时，多任务间不可避免地进行内核态的资源争抢，在大家熟知的在离线混部场景中竞争尤为强烈。这就须要核心调度、单机调度、内核调度 通过泛滥协同，例如兼顾工作的各类资源优先级，并交由内核调度管制执行。
这也对应泛滥内核隔离技术。包含 CPU：调度优先级 BVT、Noise Clean 机制等；内存：内存回收、OOM 优先级等；网络：网络金银铜优先级、IO 等等。
在明天咱们还有了平安容器。基于平安容器的 Guest Kernel 和 Host Kernel 隔离机制，咱们能够更优雅地躲避内核运行态的局部争抢问题。
3. 弹性调度、分时调度
弹性和分时的逻辑都是更好的资源复用，只是维度不一样。
ASI 调度器与阿里云基础设施层充沛协同，利用 ECS 提供的弱小弹性能力，在饿了么场景，低峰期向云偿还资源，高峰期从新申请相应资源。
咱们能够应用 ASI 大资源池（注：ASI 资源池的宿主资源均来自于阿里云云资源）的内置弹性 Buffer，也能够间接应用阿里云 IaaS 层的弹性技术。二者的均衡是一个很有争议的话题，也是一个比拟艺术的过程。
ASI 的分时调度更是将资源复用做到了极致，并带来了微小的老本优化。通过每天晚上大规模停用在线交易 POD 实例，开释的资源用于 ODPS 离线工作应用，每天早上离线工作退水并从新拉起在线利用。这个经典场景更是将在离线混部技术的价值施展到最大。
分时的精华是资源复用，以及依赖的大资源池建设治理，这是资源经营 & 调度技术 的综合。这须要调度器积攒多多益善的丰盛状态作业、以及多多益善的海量作业工作。
4. 垂直伸缩调度 /X+1/VPA/HPA
垂直伸缩调度是一种秒级交付技术，十分完满地局部解决了突发流量问题。垂直伸缩调度也是大促零点峰值压力危险的杀手锏，通过对存量 POD 的资源垂直调整、精确牢靠的 CPU 调度和洗牌算法来做到计算资源的秒级交付。垂直伸缩调度、VPA 技术一脉相承，垂直伸缩调度也是 VPA 的场景之一。
“X+1”程度扩容调度在某种意义上也能够了解为 HPA 场景之一，只不过“X+1”程度扩容调度由手动触发。“X+1”侧重于强调极致的资源交付效率，这背地是研发效率的极大晋升：在线 POD“X（若干）”分钟可启动结束提供业务服务；除利用启动外的所有其它操作，务必在“1”分钟内全副实现。
垂直伸缩调度与“X+1”程度扩容调度互为补充，独特为各类峰值保驾护航。
ASI 也正在施行更多的 VPA 和 HPA 场景。例如，咱们能够通过 VPA 技术，额定提供蚂蚁春节红包更多数量的收费算力，这将是十分大的老本节约。
VPA/HPA 等调度技术更多场景的极致施行，也是阿里巴巴将来将持续谋求欠缺的中央。
5. 分等级 [差异化 SLO] 的资源调度
差异化 SLO 调度是调度器的精华之一；这节内容与上文中的【调度资源类型】章节存在肯定的反复。鉴于差异化 SLO 的复杂度，所以无意将它放在本章的最初一节来讲述。
ASI 调度器内，也十分准确地定义了 SLO(服务质量指标)、QoS 和 Priority。
1）SLO
SLO 形容的是服务质量指标。ASI 通过不同的 QoS 和 Priority 来提供差异化 SLO，不同的 SLO 有不同的定价。用户能够依据不同的业务个性来决定 ” 认购 ” 哪类 SLO 保障的资源。如：离线的数据分析工作，则能够应用低等级的 SLO 以享受更低的价格。而对于重要业务场景则能够应用高等级的 SLO，当然价格也会更高。
2）QoS
QoS 形容了资源保障品质。K8s 社区定义的 QOS 包含 Guaranteed、Burstable、BestEffort。ASI 中定义的 QOS，与社区并没有进行齐全映射（社区齐全用 Request / Limit 来映射）。为了能将团体的场景（如 CPUShare，混部等）形容清晰，ASI 从另外一个维度定义了 QOS，它包含 LSE / LSR / LS / BE，清晰地划分出不同的资源保障，不同的业务依据本身的提早敏感度能够抉择不同的 QOS。
3）PriorityClass
PriorityClass 和 QoS 是两个维度的概念。PriorityClass 形容的则是工作的重要性。
资源分配策略和工作的重要性（即 PriorityClass 和 QoS）会有不同的组合，当然也须要存在肯定的对应关系。例如，咱们能够定义一个名为 Preemptible 的 PriorityClass，其大部分工作对应到 BestEffort 的 QoS。
各个调度系统对 PriorityClass 有不同的定义。例如：
- 在 ASI 中，ASI 的 priority 定义，目前定义了 System、Production、Preemptible、Production、Preemptible。这里不具体解读每个等级的细节。
- 搜寻 Hippo 中定义的品种和粒度更细，包含：System、ServiceHigh、ServiceMedium、ServiceLow、JobHigh、JobMedium、JobLow 等。这里不具体解读每个等级的细节。
全局最优的调度
1. 调度模拟器
调度模拟器有点相似于阿里巴巴的全链路压测系统，通过线上实在的流量回放、或模仿流量回放，在模仿环境验证调度新的能力，进而一直地锻炼各种调度算法，优化各类指标。
调度模拟器的另一个常见的用处是，是对线上疑难杂症问题做线下模仿，做到有害、高效地定位各类问题。
肯定水平上，调度模拟器是全局调度最优的根底。有了调度模拟器，咱们得以在模仿环境，重复锻炼各种算法、技术框架、技术链路，进而做到全局指标的优化，例如：全局分配率、不同场景下的调度性能、调度稳定性等等。
2. Elastic Scheduling Platform（ESP 平台）
为了做到全局最优的调度，围绕着调度器，ASI 构建了一套全新的 Elastic Scheduling Platform（ESP 平台），旨在围绕调度器，打造基于调度数据领导 & 外围调度能力 & 产品化调度经营 的一站式自闭环调度效力零碎。
在过来，咱们曾经建设了诸多相似模块，例如调度 SLO 巡检、泛滥调度工具、不同场景的二层调度平台等；而基于 ESP 平台，汇合更多的二层调度能力，带给 ASI 全局最优的调度品质，并围绕 业务稳定性、资源老本、用户效力晋升，带给客户更贴心的服务。
更多调度能力
本文尝试着系统地解说 ASI 调度器的基本概念、原理和各种场景，并率领您走进调度器漂亮精彩的世界。调度器博大精深，遗憾的是，受限于篇幅，也不得不管制篇幅，十分多的内容点到为止并未深刻开展。在调度器内，还有更多更深层次的调度底细，如异构机型调度、调度画像、公平性调度、优先级调度、腾挪调度、抢占调度、磁盘调度、Quota、CPU 归一化、GANG Scheduling、调度 Tracing、调度诊断等泛滥调度能力，本文均未予论述。受限于篇幅，本文也未讲述 ASI 弱小的调度框架结构及优化、调度性能优化等更多更深层次的技术底细。
早在 2019 年，ASI 已优化 K8s 单集群至业界当先的万级节点规模，并得益于阿里云 ACK 弱小的 K8s 运维体系，阿里团体内继续保有着数量泛滥的大规模计算集群，同时也积攒了业界当先的 K8s 多集群生产实践。正是在这些大规模 K8s 集群内，ASI 基于欠缺的容器调度技术，继续为泛滥简单的工作资源提供着计算资源算力。
在过来的数年，借助于团体全面上云的契机，阿里团体在调度畛域，已实现了从 ASI 管控到阿里云容器服务 ACK 的全面迁徙和进化。而阿里团体内简单、丰盛、规模化的业务场景，将来也将继续输入、加强并锻炼云的技术能力。