弹性调度的基本模式

方舟的弹性调度希望提供给用户的不只是一种弹性操作集群资源的能力，而是要对所有用户的成本和稳定性优化这件事负责。由于目标应用在各方面差异性很大，所涉及的配置项数以千计并且一直处于动态变化状态，全靠人工进行配置管理非常不现实。

由此，方舟弹性调度提出了一种闭环反馈式的模式（如上图所示）。弹性调度基础能力基于应用分组运行情况和不同应用分组的策略配置参数，做出扩缩容决策，并通过方舟的容器操作服务调整集群容器数量；应用分组集群受到集群容器数量变化的影响，会产生不同的表现行为（例如扩容时集群平均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分布标准差，即能得到在不同概率下应该设置的阈值）。

如上图的正态分布曲线，我们如果把阈值定为平均rt + 2个标准差，那么依照概率粗略计算，我们假设一天当中有将近33分钟服务处于rt过高状态（1440分钟 * （1 - 0.9544）/ 2），由此就得到了一个数学上合理的阈值（这部分逻辑只是服务安全策略逻辑的一小部分，具体在后文介绍该策略时具体说明）。这样一来，对于各式各样的服务，只要能获取到它的历史监控数据，就能自动、快速地得到这个数学上的阈值。

弹性调度的架构体系

方舟弹性调度的三层决策：

1.第一层是策略决策，策略决策层由多个不同的策略组成，并且支持快速扩展。策略之间逻辑完全隔离，每个策略计算完成后都会独立输出动作（扩容、缩容、不变）和数量。为了能够适应不同应用之间的异构，每个应用分组也可以根据实际情况启动或关闭不同的策略。

2.第二层是聚合决策，聚合决策收集第一层所有策略的决策结果，并依据聚合规则得到一个合并后的<动作，数量>组。这一层的规则十分简单：当同时存在扩容和缩容决策结果时，以扩容为准，忽视缩容结果；当存在多个扩容结果时，以扩容数量最多的结果作为最终结果；当存在多个缩容结果时，以缩容数量少的结果作为最终结果。

3.第三层是执行决策，这部分决策主要会考虑到一些规则，最终告诉扩缩容服务：要不要扩缩，要扩缩多少个容器，如果是缩容那么要缩容哪几个具体容器，如果是扩容那么具体的容器规格、扩容到的机房等。