【运维平台系列】关于弹性扩缩容操作的细节

  在IAAS层资源的自动扩缩可以有效地节省机器资源成本，比如在业务的低谷期可以将机器资源降下来，在业务高峰期可以自动扩容出来新机器。要支撑这样弹性调配需要有几个事情先要支持。

  1. 基础运维能力

 即一个应用的上线\下线可以做到全自动。以原子化服务的方式提供出来。比如输入某个应用名称+要扩容的机器数就会自动完成扩容操作。这个依赖一整个全自动运维链。从DNS、VIP、中间件、容器、软件发布等等。这块后续会单独启一个专题来探讨一下。

  2. 决策层能力

 决策层更多的是应用数据 + 规则。类似于风控系统，运行一些规则如果满足了条件就会触发扩容或缩容操作。但决策层里面要考虑的东西还是比较多的。比如可以依据定义阀值进行判断的规则；依据应用流量来预测的规则；比如下一个时段是业务的高峰，可以提前做扩容；比如下一个时段是业务低谷，可以提前对业务进行缩容。这里面会有很多的决策规则。还有一些执行策略在里面，比如前一个决策是缩容操作，后面再进来一个扩容操作，那前面这个任务还没有完成的话要不要提前结束掉？ 或者前面一个任务是缩容操作，后面再进来一个扩容操作，那前面这个缩容操作要不要终止掉。这些都是属于决策层的判断。

  3. 触发层

 触发层更多的是接入实时监控获取到准实时的监控数据，用于判断当前这个应用要不要扩容或缩容操作。对于触发层来讲重要的是：高并发采集器 + 定时调度 + 聚合 + 规则判断 + 原始数据落盘。触发层是不需要决策什么东西，只要规则生效了就会自动调用决策层发起扩容或缩容指令操作。

 触发层因为涉及到查询外部的监控数据进行聚合。这里面涉及到一些算法（数据拟合的算法）。如果是求平均的话那就是总量 / 总记录数 = 求平均数. 这中间可能会有采集丢失的可能，因为计算求平均了，所以丢了点数据其实也所谓了。这块不要想太多了。之前我的想法是一个应用下面有10台机器，采集的时候每台机器过来的时间点可能不在同一个点上，相关几个ms或1-2s。其实在求平均之后这个就不算什么了。（晚上看下：关于数据拟合算法的东西做个专题整理一下） 

这里面有些比较细节的问题：

1）决策要不要扩以及要扩多少台？

有两种策略：

a) 凭经验来判断。比如正常按一次扩10台进行扩容。

b) 按业务的上坡与下坡或者讲是按流量预测来判断。 通过准确的预测可以获得一个比较精准的扩容数量。

2）缩容是按步进执行，扩容是一次性的

在执行缩容之前务必要先进行应用的静默期等待。在这个静默期期间可能会出现新的一次决策插入

3）关于如何定义高峰与上下坡的定义

什么是流量高峰？什么是上下坡，这个定义是怎么样的？

###抛几个弹性遇到的问题####

1、如果安全阀值是由前5分钟计算出来的一个平均，那如何来解决脉冲的问题？

比如前五分钟可能RT非常高了，这个时候还不会进行扩容操作，等到5分钟之后再触发一次资源扩容。可能这个时候应用都挂了。然后五分钟之后应用的QPS会下降下来，这个时候再扩容已经没有意义了。而且会导致资源浪费。所以如何在出现这次脉冲波之前就提前把容量准备好。