2.1　业务背景

在实际生产环境中，从服务的端到端交付来看，集群资源调度只是生产环节的一个服务模块。例如，站在微服务［10］的应用视角，应用生命周期过程包括：应用实例扩缩容、发布、停止、重启、下线。在云原生计算［11］、Serverless场景中，在这一未来新架构模式下，业务方可能只需要定义集群容量、发布规则，实例扩缩容由弹性服务模块自动管理。正如前言所述，本书的切入点是IaaS（Infrastructure as a Service）的资源调度，实例资源的扩缩容依然是核心服务主线，一般资源调度对使用资源的应用的服务架构是微服务还是云原生，并不感知。不过，由于发布模式与业务场景、业务实例架构紧密相关，对于原地发布和非原地发布[1]，资源调度承载的技术点是不完全一样的。因此，我们可以理解为：集群资源调度核心指标对外的SLA表现，着重在于实例资源的扩缩容、发布的成功率和效率。当然，同时也要面对不可回避的挑战——硬件故障是常态，特别是大规模物理集群，集群资源调度系统必须能够应对常态化的软硬件故障。

集群资源调度核心指标对内的SLA表现，体现在资源利用率和稳定性上。通过调度支持各种Workload特征，实现充分的资源分配、运行时资源的分时共享，并依据SLA进行运行时资源的调配，实现运行时的稳定性。下面分别从对外SLA、对内SLA的表现，进一步进行场景分析和实践分享。

2.1.1　缩容

我们先从缩容的重要性说起。能缩容，才能说资源生命周期是完整的[2]。透明缩容，需要屏蔽“故障机”[3]、资源具体位置[4]等；否则，意味着资源“静止”了。静止的资源最大的风险是：资源利用率的提升有限，以及故障发生时，业务快速恢复的能力有限，最终导致成本的大幅度提高。考虑到规模化平台，有上万个应用，每个应用“静止”一个实例，就是上万个容器或者虚拟机。这些“长尾”的“静止”资源，分散在每个业务下几乎是可以忽略的，但是从全局来看数据是吓人的。

此外，应用缩容，可能关联上下游依赖系统联动变化。与之相对，资源调度系统通常是透明的，不会主动感知业务的依赖性，而是交给业务自身控制。这个场景存在糟糕的实践，因此需要避免。在给出建议之前，我们需要理解本质诉求。

1.缩容糟糕实践

心理因素：担心缩容后扩不出来，于是就会预留Buffer以避免未来资源交付的不确定性。还有，在预算前提下“任性”保留资源。在公有云或者私有云上，都会面临资源交付的确定性问题。

2.缩容本质诉求

在精细化成本运营场景下，可预知、可控的资源获取，直接影响了成本和业务规划。规模化平台承载了大量的用户需求：资源等级、资源规模诉求是多样的，资源调度系统针对应用实例的缩容在被动场景下触发。解决心理因素导致的资源占坑问题，需要联合资源运营管控，例如额度、预算、资源供应链等，在不同发展阶段采取相应的资源池逻辑划分、运作、管控约束，进行资源的滚动、分时共享交付，做到可预知、可控的资源获取。

缩容技术建议

在规模化场景下，应用缩容（非指定容器实例缩容），加入调度算法的筛选因子：宿主机健康度、潜在软硬件升级诉求、负载均衡、功耗均衡及其他资源搬迁运维计划等，从而充分利用缩容时机，叠加其他运维需求，透明化已知的基础软硬件升级给业务带来的影响和感知。

2.1.2　扩容

对于一个应用来说，扩容最核心的输入就是容量评估，也就是需要扩容多少个服务节点。还有效率问题，就是如何自动扩容。实现自动扩容，还需要调度支持。在规模化扩容时，有哪些建议？下面进行具体描述。

1.容量评估

将缩容和扩容看作正反两面，按“取反”原理，依据缩容的诉求和建议来评估扩容的诉求和建议，就更简单了。不过，扩容多少、评估依据是什么、扩容之后什么时候下调，扩容是否触发联动上下游容量的依赖变化，等等，这些需要分层实现。预算、性能、业务表现会共同影响容量的变更，同时资源池的供应能力，有时也会对扩容交付产生影响。

2.自动扩容

自动扩容是资源弹性能力的关键体现，在平衡成本和服务效率发挥重要作用时，可实现资源利用率的提升、稳定性的优化改进，使业务能快速应对高低峰请求的处理压力。

3.调度支持

大规模资源调度始终有一个原则：在调度算法层面实现最基础的资源共享，而不是独占[5]。在资源运营层面，约定一些临时性的、全局考虑的“申请流程”规范。例如专有云，因为同属一个公司内部组织，应用属性以及对资源的消耗特征，通过数据共享给调度系统，帮助编排加以优化——有针对性地实现单机实例数控制、可控超卖、紧凑分配等，以及大规格、高优先级实例优先申请等；公有云，采用黑盒调度，需要额度申请、资源报备并交纳一定比例的预约金。

扩容技术建议

在可预知的场景下扩容，一般都有缓冲的时间来应对资源需求。最具挑战性的是突发场景下的大规模资源扩容。从用户的角度，一般采取专有云与公有云结合的模式来实现容量诉求，专有云应对如数据库、全局缓存这样的容量诉求，公有云应对前端Web这样的容量诉求；从调度系统的角度，要在扩容阶段就开始考量后期的腾挪、迁移，以及潜在的硬件故障。

例如阿里巴巴每年的“双11”促销活动，这是一个典型的、规模化的突发资源诉求和资源调度场景，要在有限的资源、有限的时间内，应对大促资源的诉求——规模资源的提供、规模资源的编排、规模资源的稳定性。在资源供给充分的前提下，挑战有：

● 像“双11”大促这样的电商促销活动，会有很多应用联合起来提供服务。也就是说，大促活动依赖很多应用，而每个应用又都依赖一些具体资源，从业务开始规划到具备峰值处理能力，这个准备过程比较长，过程中业务规则的变化、容量的变化时刻发生，越到资源准备的后期，资源越稀缺，要考虑这个时候大规模扩容、临时新增资源诉求该如何满足。

● 参与大促的应用，容量评估很难一步到位。

常用的应对办法推荐如下：

● 调度系统保持“中立”，平衡各个业务诉求，最大化资源效能，最小化二次分配的扰动。平衡是说存在多个应用同时提出资源需求，需求量各异，业务的重要性、资源保障优先级也不同。二次分配的扰动是说应用的资源交付是逐步收敛的、需要确定性稳定性的过程[6]，已有的编排部署关系应该是收敛的，也就是改变最小。

● 资源运维管理的配合：通过流程化预算追加、额度转借等实现预期外容量资源的调度分配。

● 混合云资源申请：假定云的资源是海量的，可在云端按需申请资源。

很多企业对混合云可能还比较陌生，这里进行如下分析，便于读者更好地理解宏观上混合云的资源支持特点。

假设在公有云场景下，同时面对N个未知用户的突发资源诉求。例如A、B、C同时需要1000个实例，3000个实例由云端提供。

为了应对这样的突发容量需求，势必要求云端Buffer池足够大，以应对规模化的突发资源供应。面对这么大的Buffer池，问题来了：云端资源利用率高不到哪里，又如何能够实现盈利？或者说，这么大的Buffer成本，或多或少会转嫁给用户，用户采用混合云相比自建机房的服务器成本优势会不会受到影响？公有云的盈利维度有很多，在资源侧有一种解释（所有数字均为假设）：用户自己采购3000台服务器，全年硬件成本为30000元，租用云服务器3个月的云上硬件成本为8500元（）。该成本由两部分构成，其中一部分是等价自建的成本；另一部分是公共摊销成本。相对用户自建全年的投入来说，租用云服务器成本是可控的、有优势的。公共摊销构成的收益就是云盈利的一个来源，规模越大，每个用户的公共摊销成本越低，从而用户越多、使用越多的平台优势越大。对于混合云，用户和云供应商是双赢的。

2.1.3　故障处理

在集群调度管理过程中，常见的问题就是软硬件故障。故障是一种小概率的必然事件，那么故障处理能力必不可少，具有该能力可以很好地检验调度管理系统的闭环能力和自动化能力。这部分主要关注故障率、故障影响和故障处理。

1.故障率

在大规模集群中，硬件故障率为0.03%。每天因为宕机或者夯机（服务夯住的状态，没有完全中断）投入的答疑人力，与链路关联的模块数量、模块关联的组织团队数量紧密相关。模块多、组织结构分散，再加上问题场景复杂多样，答疑沟通成本已远超发生故障的硬件本身的成本开销。所以，硬件故障处理周期是一个有效的指标。

2.故障影响

硬件故障率看起来极低，并且故障呈现随机性，但是这些小概率突发事件发生在一个应用如分布式缓存系统或者消息中间件节点上时，业务的故障影响就会被放大。这些业务场景对故障敏感性很高，对故障的感知、迁移能力要求极高。

3.故障处理

故障是常态，故障处理系统自然是必备系统。故障事件采集、故障事件通知、故障事件处理三者整体协同工作。故障处理水平间接体现了一个集群资源调度管理的水平，同时也保障了扩缩容的效率和自动化能力。基于面向失败的设计，在集群资源调度管理中，硬件故障就是一个典型的失败场景。

故障处理技术建议

故障处理和业务扩缩容等同对待，有利于实现故障处理的流程化和自动化。故障处理往往是“背后”的工作，不同于扩缩容链路那么“靠近”用户，因而不容易被用户直接感知，被“显示”关注到，往往被忽视。故障处理推荐：按完整的资源生命周期来处理，避免中间节点介入临时处理。故障处理流程是在故障确认[7]后，进行节点上残留实例信息清理[8]、节点硬件维修、节点基础软件重新构建（基于模板或者基于镜像）、节点重新上线（加入线上资源池，成为可调度的资源）。故障处理过程，就是事件驱动的自动化处理过程。

2.1.4　负载均衡

在一个大型的混合机型的物理资源池中，物理机负载是否均衡直接反映了资源利用率水平。资源调度和管理的终极目标就是节约成本[9]，实现资源利用率的提升。

做好负载均衡，首先需要理解负载不均衡的原因。物理资源利用率不均衡，有很多因素。一般默认应用负载在流量均衡的前提下是均衡的。但“长尾”总是客观存在的，也就是说，总是会存在局部不均衡。此外，随着业务的发展，以及实例自身资源消耗特征的变化，之前的编排部署已经不匹配最新的Workload特征。

负载均衡技术建议

物理集群级别、规模性的不均衡一般需要重调度、二次部署来大范围处理。一般局部实例的不均衡，采取定点迁移微调即可。例如，在电商交易促销场景下，负载均衡处理过程是：先进行全链路压测，然后通过全链路压测结果分析，识别峰值时刻TopN高、TopN低负载物理机，最后结合业务属性，进行定点迁移——将高负载物理机上的实例节点迁移到低负载物理机上。日常负载均衡处理的思路是：进行长周期任务（比如在线的面向用户服务的Web Service）和短周期任务（比如离线的面向数据处理的Data Analysis）的混部，抹平物理节点的负载不均衡。集群部署规划前置也会影响利用率，例如用于安全、法律或者其他诉求的专有集群，利用率相对其他集群会存在不均衡甚至持续低下的情况。在这种强场景性的制约下，资源调度系统很难跨越业务的约束实现资源共享。

2.1.5　宏观评价

1.资源的用户评价

对集群资源调度和管理进行评价时，一般要考查SLA保障能力，例如在业务层面，腾挪最少、故障率最低、单机性能最大化、峰值时刻CPU利用率情况等。

2.资源的管理者评价

考查物理机碎片率、物理机CPU Max利用率、物理机集群CPU均值、物理机集群综合利用率等。

3.技术能力评价

考查并发分配性能、调度规则的灵活性、调度响应时间、初次分配成功率[10]、二次迁移量等。

4.高可用视角评价

考查发布迭代周期、版本一致性比例、运行时节点故障率、单机多节点间干扰率、集群预警告警比例、故障快速响应和止血时间等。我们可以定义适当的运维等级，按等级对应的指标要求进行跟进和优化。

以上概述了集群资源调度对外SLA、对内SLA以及评价的解释，下面从量化指标的角度进行一一说明。

2.1.6　具体指标

上面内容以“概念或者能力”阐述为主，这一节以具体的量化指标来反映资源领域的业务情况，分别从用户视角和系统视角来定义。

1.服务指标（用户视角）

如表2-1所示，服务指标主要从资源的用户视角来定义，偏白盒化、透明化。用户关心结果，而不关心细节。

2.系统指标（系统视角）

如表2-2所示，系统指标主要从系统视角，由提供服务者来定义，偏具体化、过程化。系统指标是用户指标在系统内的分解体现。

接下来，重点阐述资源调度性能、资源调度成功率、资源分配率、资源实际利用率指标。