弹性调度的基本模式
如前文所言，方舟的弹性调度希望提供给用户的不只是一种弹性操作集群资源的能力，而是要对所有用户的成本和稳定性优化这件事负责。由于目标应用在各方面差异性很大，所涉及的配置项数以千计并且一直处于动态变化状态，全靠我们人工进行配置管理非常不现实。
由此，方舟弹性调度提出了一种闭环反馈式的模式（如上图所示）。弹性调度基础能力基于应用分组运行情况和不同应用分组的策略配置参数，做出扩缩容决策，并通过方舟的容器操作服务调整集群容器数量；应用分组集群受到集群容器数量变化的影响，会产生不同的表现行为（例如扩容时集群平均CPU使用率会发生变化，服务rt会在一定范围内下降等）；应用分组的表现在以实时数据提供给弹性决策的同时，也会进行历史数据的离线存储（Alimonitor/EagleEye等集团标准监控系统都提供了这样的数据服务）；自动策略配置会周期性获取这些历史数据，并依照一定的算法，对不同的应用分组进行不同的策略配置，从而再次影响到弹性调度策略的决策。
这种模式的优越性在于：
1.具备一定程度的自我进化能力。当应用分组刚刚接入弹性时，其大多数的策略参数都为默认值；而当弹性运行一段时间后，结合自动评估方式，各种参数会得到不断的修正以达到更好的弹性效果。以服务安全策略为例：服务安全策略在实时决策阶段概括起来就是对当前服务rt于服务的sla阈值进行比较，刚刚接入弹性时，服务的sla是基于服务接入弹性前的历史rt来得到的，一般来说非弹性状态下服务rt的表现，与弹性状态下服务rt的表现是有很大的区别的，可能一开始由于服务sla设置得不合理（一般来说是过小），会出现“多扩”的现象，由服务rt违反sla引起的扩容会占到整体扩容原因的大多数。这种现象会被每天定时执行的分析任务捕捉到，判断出sla设置得不合理，结合最近几天的运行状态，重新计算服务sla，由此提高阈值设置的合理性；
2.以更高的抽象层次来进行海量参数的配置，以解决普遍问题。还是以服务rt的sla阈值为例，当我们把配置视角关注到一个具体服务时，我们可能会纠结于一个服务它所对应的具体业务逻辑是什么、它涉及的调用链路是什么、上游服务对它的容忍性等等细节问题，那么这样一来，面对菜鸟不同应用提供的成千上万个服务，逐一配置根本不可能做到（注：每天都会服务会上线和下线，服务的业务逻辑也可能发生变化，配置是需要进行经常性更新的，这无疑使人工配置更加变得不现实）。而自动策略配置逻辑以更高的抽象层次来看待各项参数，对于服务rt，基于一个普遍适用的假设：“服务rt在一天当中的绝大多数时间都是处于合理状态”，并且通过概率分布计算（服务rt真正的分布情况也可以通过历史数据统计得到），可以得到一个数学意义上的sla阈值（以正态分布为例，求得一段时间内服务的平均rt和rt分布标准差，即能得到在不同概率下应该设置的阈值）。
弹性调度的架构体系为什么采用三层决策的模式？
首先介绍一下方舟弹性调度的三层决策：
1.第一层是策略决策，策略决策层由多个不同的策略组成，并且支持快速扩展。策略之间逻辑完全隔离，每个策略计算完成后都会独立输出动作（扩容、缩容、不变）和数量。为了能够适应不同应用之间的异构，每个应用分组也可以根据实际情况启动或关闭不同的策略。
2.第二层是聚合决策，聚合决策收集第一层所有策略的决策结果，并依据聚合规则得到一个合并后的<动作，数量>组。这一层的规则十分简单：当同时存在扩容和缩容决策结果时，以扩容为准，忽视缩容结果；当存在多个扩容结果时，以扩容数量最多的结果作为最终结果；当存在多个缩容结果时，以缩容数量少的结果作为最终结果。
3.第三层是执行决策，这部分决策主要会考虑到一些规则，最终告诉扩缩容服务：要不要扩缩，要扩缩多少个容器，如果是缩容那么要缩容哪几个具体容器，如果是扩容那么具体的容器规格、扩容到的机房等。执行决策进行判断时需要考虑到的规则非常复杂，这里简单罗列一些相对重要的规则：
-
机房均摊规则；
-
当前应用分组的扩缩容状态规则，例如如果本次为扩容：如果正在扩容，当本次扩容目标数量大于正在扩容的目标数量时，取差值再次发起一个扩容，由此实现并行扩容；当本次扩容目标数量小于正在扩容的目标数量时，忽略本次的扩容请求；若正在进行缩容，则立即停止缩容，并根据目标容器数和当前容器数发起扩容。
-
模式规则：弹性调度目前支持全自动扩缩模式、人工审批模式两种，如果当前分组为人工审批模式，那么本次决策会需要管理员进行审批。
-
最大值最小值保护规则：应用分组可以配置最大值最小值，执行决策会保证由弹性调度发起的扩缩任务，不会使最终容器数超过最大值或小于最小值。
此外，执行决策层对于单个分组来说是强一致的，并且第二层输出的决策结果，是集群需要达到的目标容器数量，这种设计是前两层能够做到完全无状态且幂等的重要因素。
三层决策器使每一层只需要关注自己本身的决策逻辑，分离了“变与不变”的业务逻辑，对扩缩容的最终确定进行层层验证，是实现“覆盖菜鸟大多数应用”目标的基础。
阅读原文：