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

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

  1. 基础运维能力

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

  2. 决策层能力

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

  3. 触发层

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

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