1.背景介绍
随着实时计算技术在之家内部的逐步推广，Flink 任务数及计算量都在持续增长，集群规模的也在逐步增大，本着降本提效的理念，我们研发了 Flink 任务伸缩容功能：
-
提供自动伸缩容功能，可自动调节 Flink 任务占用的资源，让计算资源分配趋于合理化。一方面避免用户为任务配置过多资源，造成资源浪费；另一方面，降低用户在调节资源方面的运维成本。
-
提供手动伸缩容功能，降低调节资源过程对业务的影响。伸缩容操作本质是先申请资源，待资源准备就绪后，才执行 Recover 操作，和重启任务相比，可以将业务受影响的时间从分钟级降低到秒级。
目前支持自动调节并行度以及 TaskManager 的 CPU、内存，用户可以在平台上定义个性化的自动伸缩容的策略：
2.设计思路
以伸缩容 CPU/内存为例，大致思路如下：
步骤一：向 ResourceManager 申请 Container ，并为新 Contianer 打标记
注意：新的 TaskManager Container 请求是通过 SlotPool 向 ResourceManager 请求的，这一步需要在 SlotPool 中维护新的资源配置（CPU：2核，内存：2 GB），且需要支持回滚机制（如果这次伸缩容失败资源设置回滚到 CPU：1核，内存：1 GB）
步骤二： 停掉任务，删除ExecutionGraph
步骤三： 释放掉旧TaskManager，重新构建ExecutionGraph并在标记的TaskManager上从保存点恢复
步骤四：将这次伸缩容的资源设置持久化到Zookeeper和HDFS
如果 JobManager 挂掉那么之前伸缩容的资源配置都会丢失。所以需要将伸缩容后的资源配置保存在 Zookeeper，HDFS 上 (数据存在 Flink 基于 HDFS 的 BlobServer 中，在 Zookeeper 会中保存 BlobServer 的key，节点在HA的根目录)，在 JobManager 被重新拉起时可以从最近一次伸缩容请求恢复。
3.架构设计
我们在 JobManager 中添加了一个新的组件 RescaleCoordinator ，使用HA维护其生命周期，且与 Dispatcher 之间彼此通过 RPC通信。
-
RescaleCoordinator 选上 leader 后，会定期检查是否需要伸缩容。如果需要伸缩容，则向 Dispatcher 通知 JobMaster 开始伸缩容（这里省略掉 JobManagerRunner）；
-
JobMaster 会向 ResourceManager 请求 TaskManager（这里省略掉 SlotPool 和 SlotManager）；
-
待所有请求的 TaskManager 就绪，开始将旧的 TaskManager 释放掉，然后基于新的TaskManager重新调度；
-
最终把这次结果持久化到 Zookeeper 和 HDFS，像上文提到的存到 Zookeeper 和 Flink 基于HDFS的 BlobServer，平台上的 Flink 使用 Zookeeper 和 HDFS 做 HA，所以不会引入其他组件；
因为新 Container 是提前申请好的，这样就省去了申请 Container 的时间，同时也避免了因为资源不够申请不到slot的问题。
并行度的伸缩容 与CPU/内存类似，不同点：需要在发起新调度前修改JobGraph的并行度来实现修改并行度
4.自动伸缩容策略
| 类型 | 原因 |
|---|---|
| 并行度 | 存在消费 Kafka 延迟，且 CPU 使用率较低，很可能是 IO 密集型任务，可以增加并行度扩容；存在空闲 slot，则执行缩容避免资源浪费 |
| CPU | 根据 CPU 使用率来判定需要扩容或缩容 |
| 内存 | 根据内存使用率及 GC 情况判定需要扩容或缩容 |
5. 后续规划
1.利用离线/实时错峰特点提高服务器资源利用率
由于离线任务一般跑在半夜，导致离线集群半夜比较繁忙，白天空闲，而实时任务恰好相反。我们准备支持基于时间的策略，白天在指定时间将任务资源调高，晚上再将资源还给离线任务，以提高服务器资源利用率。
2.细粒度的扩缩容
我们目前伸缩容都是调节所有 TaskManager 的 CPU/内存，后续想调研下只调节某几个 TaskManager 的可行性。