3.2.4 调度技术
调度系统在整个弹性计算中发挥着资源决策的作用, 当用户创建一台虚拟机或者使用一台已有的虚拟机进行迁移时，需要调度系统能够精确选择一个可用的物理机。典型的迁移场景有以下几个。
停机迁移： 物理机停机的时候。
升降配迁移：虚拟机需要进行CPU 和内存扩容，或者升级到其他规格产品系列的时候。
主动迁移：物理机硬件隐患、资源竞争导致性能下降时，可以通过热迁移或者用户重启的方式触发主动迁移。
调度系统不光在云平台，也在日常生活的很多场景中会遇到，比如高铁、电梯等。
回归本质，调度系统就是资源分配的决策过程，即在合适的时间给合适的对象分配合适的资源。因资源不同，所以出现了各式各样的调度系统。如果资源是 CPU 的68
时间片，那么它可能是操作系统内部的进程调度；如果资源是用于创建虚拟机的一台台物理机，那么它是云上的虚拟机调度系统，如阿里云的后羿调度系统。
当用户通过控制台或者 Open API 创建一台虚拟机时，调度系统会在数以万计的物理机中，寻找一台较符合用户需求的机器承载用户的虚拟机实例。对照上面的描述，在这个场景下，合适的时间即用户创建虚拟机的时候，合适的对象指用户设定的虚拟机的属性，比如规格、售卖类型、网络类型等，而合适的资源其实就是云平台的物理机集群了。
调度系统在不同平台的实现存在一些差异，业界也有很多文章对其进行分析总结，比如 Google 发布的关于 Omega 调度系统的论文，把调度的架构分成了集中式调度、双层调度及共享状态调度。目前主流的一些分布式调度系统，包括 Yarn、Mesos、Spark 等都可以归到这几大类。它们在扩展性、并发度、容错性等方面各有优缺点， 此处不再赘述。
阿里云的后羿调度系统历经了十多年的发展。 2010 年，ECS 的第一个集群上线， 那时候的后羿调度系统是基于集群的调度，做的事情就是在集群内部进行静态的资源分配。但是伴随着集群规模的扩大，后羿调度系统也开始逐步演化，除了管理粒度细化到了区域，在调度流程中也引入了过滤—权重模型，同时考虑的权重策略变得逐渐丰富起来，从最初的装箱策略到后来的用户粒度分散、资源负载等。
过滤—权重模型
过滤— 权重模型是目前调度系统中使用的主流模型之一， 在 OpenStack、Kubernetes 中都能看到相关实现，当接受调度请求时，会依次流转到过滤器（ Filter）、 权重器（ Weigher） 及选择器（ Selector） 这三个核心组件，如图 3-10 所示。
过滤器权重器选择器调度请求
图3-10 过滤—权重模型
我们以用户发起创建多个 ecs.c5.large 规格的虚拟机为例，介绍这三个组件的作用。
（1）过滤器
顾名思义，过滤器的作用是过滤候选物理机。对于创建 ecs.c5.large 规格（即 CPU 是两核，内存是 4GB）的虚拟机，过滤器最典型的一个用途就是剔除当前资源不足两核 4GB 内存的物理机。实际上，在过滤器中有一个过滤器链，上文提到的剩第3 章 计算产品和技术
余资源过滤只是链路中的一环，其他比较常见的有售卖集群过滤、售卖类型过滤、网络架构过滤等。
（2）权重器
所谓“吹尽狂沙始到金”，经过前置的过滤器后，到达权重器的物理机列表都是符合创建条件的，那为什么需要权重器这个组件呢？回到前面创建虚拟机的场景中， 最主要的一个考虑就是装箱策略，ecs.c5.large 的内存和 CPU 的比例是 2 ∶ 1，从资源使用率的角度，我们当然期望最大化使用物理机上的所有资源，如果候选的物理机有两台，剩余的资源分别是两核 4GB 和两核 8GB，那么从配比的角度看，使用剩余资源是两核4GB 的物理机比较合算，刚好能最大化使用资源，否则会造成 4GB 资源的浪费。与过滤器中的过滤条件描述类似，权重器中考虑的权重也不止一个，除了刚才举例的资源配比，还有用户分散度、大规格资源预留等，这里部分权重甚至还会有冲突，如何去做权衡是一个大学问。
（3）选择器
这是整个调度链路的最后一环，从前置的权重器获取一个有序的物理机列表后， 它要做的事情就是从列表里面选择一台最终承载用户创建的虚拟机。当然，最简单的策略就是选择第一台，因为它在此时此刻是最符合用户需求的。而实际情况是，在分布式环境里，用户创建的是多台 ecs.c5.large 规格的实例，言外之意就是并发创建。每创建一次虚拟机，都需要对物理机执行资源分配、虚拟机创建等操作，为了保持在分布式环境中的资源一致性，往往需要对当前操作的物理机执行加锁操作。为了提高效率，在选择器中比较典型的做法是对在一定范围内符合条件的物理机，执行随机选择策略，降低对同一台物理机争抢加锁的概率。当然这时候选择的物理机未必就是最佳的了，这本身也存在与效率之间的平衡问题。
核心业务组件
阿里云的 ECS 后羿调度系统有哪些独特之处呢？除了过滤—权重模型，还有哪些调度相关的核心业务组件呢？接下来逐步为大家揭晓。
1） 调度的大脑——过滤器—权重器—选择器工作流
虽然说这个工作流结构相对比较通用，但是在不同平台中需要考虑的方面存在不少差异，尤其是在不同规格及业务场景的冲击下，设计上的差异更是突出，如图3-11 所示。70
图3-11 过滤器—权重器—选择器工作流
强/ 弱过滤器的引入。过滤器依据了一些规则对候选物理机列表做筛选，但是在调度的策略中常常会出现如期望这些虚拟机尽量迁移到符合某些特定条件的机器上去等需求。针对这类需求，除了在权重中引入对应的因子，还可以使用弱过滤器，即当调度系统使用过滤器过滤后的候选列表低于设定阈值时， 就会忽略掉这个过滤规则。
多重的调度权重因子。在当前的调度权重计算中，会考虑用户维度的打散、物理机健康度、调度虚拟机与目的机器上 CPU/ 内存的配比、机型的最佳匹配等。正是因为有诸多的考虑因素，最终才能在众多物理机中选择出“最”符合条件的物理机。
高度可配置化。在实际情况中，集群中资源的分布时刻都在变化，通过外部分析实时调整相关调度策略及因子，最大的挑战是一个可用区的物理机数量达到数万乃至数十万级别，如果每个物理机都走一遍过滤器—权重器—选择器的过程流，则性能开销非常巨大，无法实现高性能交付。常规的解决思路是进行物理机分组，比如1000 台服务器一组，调度系统先选择分组，然后在组内实施过滤器—权重器—选择器流程。
2）调度的基石——标签系统
随着业务的变化及技术的发展，云上机器的异构性也越来越明显，下面介绍一些典型的例子。
（1）在物理机层面，Intel CPU 不断更新换代，如 Haswell、Broadwell、Skylake、Caslake 等，同样地，与之对应的机型也有诸多差异，如不同的内存容量、磁盘容第3 章 计算产品和技术71
量等。
（2）在物理网络和虚拟网络层面，物理网络从早期的千兆网络、万兆网络演变到目前主流的 25G bit/s 网络。同样，虚拟网络也在逐步发展：从经典网络到 VPC 网络， 以及是否支持 DPDK 高速转发等。
（3）存储系统的差异，包括高效云盘、SSD 云盘、ESSD 云盘及本地实例存储的区别。
（4）虚拟化技术，除了大家熟知的 Xen 和 KVM ，还有阿里云特有的神龙架构等。
调度流程中的过滤—权重工作流程，需要区分这些差异，或者说需要把这些差异用程序表达出来。在阿里云的后羿调度系统中，这是由标签系统来实现的。
在系统实现层面，标签系统其实就是为每台物理机维护了很多的 Key-Value 的配对值，如图3-12 所示，涵盖了从物理机自身的硬件配置、上面运行的软件状态、机器的实际物理位置到售卖相关的业务特性等方方面面的信息。其实，在设计之初，标签系统就并不只是供调度系统使用，我们期望它在物理机的管理控制等方面都能提供系统支撑。
有了标签系统后，无论是调度系统还是管控系统，都能通过程序化的方式感知和比较下层物理机的差异，甚至进一步，通过引入标签组等方式，更快地筛选机器，降低过滤器—权重器—选择器工作流中过滤器的压力。
3）调度的情报处——数据中台
俗话说得好，“知己知彼，百战不殆”。调度系统想做出一个好的决策，必须对所有物理机知根知底。如果要准确、高效地给如标签系统等输入信息，就离不开数据中台。
数据中台是弹性计算业务架构中用于数据收集、处理及分发的业务平台，调度系统借助数据中台的力量，实现了调度信息的收集和处理，比如以下典型的场景。
（1）物理机依赖实时上报和数据回流来构建整体的机器画像。在实时上报层面， 通过运行在物理机上的Agent 实时上报，系统获取当前 CPU 的 Model/Flags、网络组件 AVS 的大小版本及支持的特性、本地盘机型的磁盘状态等；在数据回流层面，通过离线对数据做分析处理，把物理机前一段时间的健康状态回流到调度系统中，例如当前物理机上虚拟机的争抢情况、功耗和超电情况等。72
图3-12 标签系统
（2）ECS 的后羿资源调度本质是一个黑盒调度，换言之，调度系统没有办法知道当前虚拟机的用途，但是我们可以通过检测物理机上的负载情况、用户创建和释放的周期等去建立画像信息，做到料敌于先机。
4）后羿调度的训练师——调度模拟器
上面提到后羿调度系统考虑了多重的调度权重因子及高度可配置化，这就引入了另外一个问题：不同区域存在差异性，这么多因子的权重如何配置？初期可以依赖线上数据定性分析，但是随着业务的更加复杂和更多因子的引入，显然需要一个比人脑更高效的“训练师”来做决策，这个训练师就是调度模拟器。
图3-13 描述了调度模拟器的工作流程。我们通过设定调度目标，并使用线上实际的创建记录数据，在模拟器平台上结合机器学习模块反复播放，按照用户购买习惯，找到当前区域产品最佳权重分配策略，通过配置化接口设置到调度系统，并以此形成一个自闭环的反馈机制，逐步优化线上资源分配。
在介绍调度系统之后，不得不提到库存供给系统。如果说调度系统是厨师，负责把各种不同的物理机食材做资源分配，并通过管控系统创建出符合用户需求的虚拟机，那么库存供给系统就是准备食材的人。显而易见，调度系统想要烧出一道好菜， 如果食材不好或者不符合预期，是万万不能的。
比如阿里云售卖的同一款产品，在不用的区域，购买用户不同，应用场景也不同，诸如创建的虚拟机平均 CPU 值、内存和 CPU 的配比、单位时间的并发创建量等也不同。在资源调度时需要适配这些“不同”，最典型的就是针对下层物理机构成的第3 章 计算产品和技术73
不同，在虚拟机内存和 CPU 配比较小的区域，尽量补充数量合适的物理机，以更好地分配虚拟机资源，甚至在差异性较大时，还可能需要适当调整装箱的策略权重参数等。
图3-13 调度模拟器的工作流程