共计 6460 个字符，预计需要花费 17 分钟才能阅读完成。
作者: 舟柒、楼台
1. 业务背景与挑战
1.1 实时计算集群现状
对于热点机器解决始终是阿里云 Flink 集群运维的一大痛点，不论在日常还是大促都曾经是比较严重的问题，同时这也是分布式系统的老大难问题。而在往年整个阿里云老本管制的背景下，随着集群水位的逐渐抬升，热点问题愈发重大。日均有上千次的热点机器呈现，并且在早晨业务高峰期，整个热点持续时间会超过 60min，对于业务以及对于平台影响是比拟大的。
这里的影响是体现在稳固，老本，效率三方面的，首先热点会导致作业的局部节点延时，高 SLA 要求工作的性能得不到保障，相似于上面这张图。其次，受热点机器这个短板的影响，整体集群水位没有方法进一步抬升，影响老本管制。最初在咱们没有一个比拟好地机制去解决热点的状况下，是须要人肉并且十分被动地去解决热点，费时费力，影响效率。
面对全面影响运维畛域（稳固老本效率三个方面）的热点问题，咱们开发的 Flink 集群的自愈零碎，出发点就是要解决 Flink 集群的热点机器问题。
1.2 热点问题剖析
接下来具体分析为什么会产生机器热点。实际上不论说集群是 20% 还是 60% 的物理水位，整体集群的物理资源对于承载业务来说都是够用的，K8S 的调度器默认会依照作业的 request 值去尽量平铺。然而目前阿里云的 Flink 集群是容许工作进行超用的，就会呈现上面这个图的状况。
当工作配置不合理时，会导致局部的 Pod 超用，局部 Pod 不超用。使得机器之间尽管 request 差距不大，然而理论的 usage 就会偏差比拟大，毛刺的局部节点就会成为热点机器。下面这幅图咱们能够看到一台机器上 Pod 的理论耗费在业务高峰期会超过整体的申请值，这个时候就会造成热点机器。
咱们能够得出结论：热点的呈现与水位绝对值多少没有必然关系，而与作业的超用水平正相干。因而 Flink 热点的治理都是围绕着解决作业超用问题开展的。
2. 老本优化 – 热点解决
2.1 热点机器解决思路
面对热点机器问题，能够分为「大促」与「日常」两类场景。
针对大促场景，任何在大促峰值期间做的运维操作，对于业务来说都是有损的，因而要尽量避免大促期间产生热点而去执行运维操作，然而咱们通常能够通过压测去正当地预估作业在峰值的行为，通过一些提前的预测的办法在大促前躲避作业超用，从而躲避热点的呈现。因而，咱们设计了一套基于作业的画像零碎，在热点产生的事前去干涉热点的呈现。
针对日常场景，在 7*24 小时保障要求下，热点产生的频次高且类型多。叠加用户操作，平台变更等非预期行为烦扰，往往热点的呈现是绝对随机且没有方法提前预测的。咱们开发了热点的事中自愈能力，谋求热点隐患呈现后的疾速打消，当热点隐患产生后，可能在敏感工作受影响的时效内实现热点压抑。而与之相配套的预先复原与运维可观测性能力也同步建设。
整体的思路上，仍是围绕解决超用工作来做，事先画像是提前躲避超用，事中自愈则是对超用的工作进行应急解决。针对热点产生的工夫线，造成了事先画像，事中自愈，预先复原，可观测性四局部的热点机器解决方案。接下来我会具体开展介绍这四个局部的能力。
2.2 事先画像
2.2.1 业务流程
首先什么是事先画像。后面提到的，事先画像是针对大促场景下，通过对超用工作的提前躲避，来实现打消热点的计划。要提前躲避工作超用，就须要作业在大促峰值的资源配置是精准的。然而目前参加大促的工作，往往作业拓扑是非常复杂的，且作业的数量十分微小。单纯的依附数据研发同学人肉地去调优每个工作的每个节点是不事实的。因而，事先画像就是用来解决超大量简单作业资源精准配置的问题，让作业在峰值期间不超用运行。
咱们设计了一套主动迭代零碎，输出每个工作的指标 RPS，通过全链路的压测平台与 Flink 工作管控平台，让作业通过启动压测工作，灌入压测流量，生成作业画像后果，进行压测流量，进行压测工作，作业利用率及 RPS 理论值比对，更新画像后果到压测工作的模仿压测流程，自动化地执行 N 轮迭代，产出一份作业 usage 与 RPS 均合乎预期的资源配置文件。整个迭代过程不须要数据研发同学参加，全自动实现。
2.2.2 实现计划
除了自动化的迭代流程外，整个环节中最为要害的就是画像是如何产生工作资源配置的，这里的能力是依靠于阿里云作业管控平台中的 Autopilot 服务来实现的。
Autopilot 会定时采样每个 TM 所有资源应用信息（包含 cpu usage, mem usage, delay）等，统计在压测峰值窗口内 TM 应用的资源 p95 值，剔除毛刺或歪斜的 TM 带来的烦扰，并通过 TM 到 ssg 到 task 的映射关系，生成合乎大促峰值需要的配置。
2.2.3 实现成果
在往年的双 11 大促，事先画像的能力也失去了了充沛的验证。这 5 个图中轮次 1 代表画像迭代前，轮次 2 代表画像迭代后。
往年大促，实时链路团队紧贴 DT 业务方深刻单干，创新性地提出作业画像联合压测来智能化地学习、调整作业正当资源配置，不仅在稳定性上实现集群 65% 水位 0 热点，而且帮忙业务升高 17% 老本（如上图所示），更是帮忙 DT 实现上百个作业数千次自动化调优。同时还提出了集群按业务优先级错峰管理模式，通过 VVP 限流性能与作业动静布局，达成不同优先级作业在各自大促峰值期间满足提早要求，晋升了集群整体水位，二者在双 11 生产首次利用，节约了 100 台机器，在后续大促中也可继续优化利用。
2.3 事中自愈
2.3.1 技术选型
面向超用作业，如何进行事中自愈有多种计划，目前阿里云外部的其余分布式系统次要有以下四种计划：
a. 全局容许超用，也就是以前 Flink 集群应用的计划
b. 全局强限度不容许超用；
c. 通过动态的规定限度超用；
d. 动静限度超用能力。
因为实时计算的业务是有其特殊性的（比如说须要有肯定的 burst 的能力应答「回追 /FO/ 大促」的场景；低优作业往往偏向于通过就义肯定水平的性能来换取老本缩小；简单拓扑下不同算子或轻或重的歪斜问题导致资源需要不同等等这些要求）。咱们认为超用对于实时工作是一个长期会存在且正当的需要，联合日常，故障，压测，大促几种场景比拟，第四种计划，也就是通过 Inspector 来实现部分的动静限流是比拟适合的计划。在热点呈现时自动化地针对热点隐患机器上的 作业 进行限流及重调度，让热点打消。而在热点打消后，再依据理论状况从新复原作业的超用能力。
2.3.2 业务流程
整体业务流程总的来说分为三个局部，感知，决策，执行。对于事中自愈来说，通过设定阈值与机器学习的办法辨认机器异样进行感知，基于 SRE 教训积淀的决策树对作业进行决策，通过降级，限流，驱赶等作为执行办法。
2.3.3 难点与翻新
2.3.3.1. 决策树（难点）
在决策这一部分中，以 SRE 的教训，咱们总结了针对热点解决的决策树，用来判断须要抉择什么作业来进行操作。这个决策树是基于「业务影响」与「热点疾速打消」这两者的均衡来做。对于平台侧而言，必定是想要热点打消的越快越好，也就是间接剔除掉应用最高的作业好了。然而另外一方面，平台须要承接业务，须要思考业务方面受不受得了这种操作，也就意味着平台上的作业会有不同的需要，包含有的作业不承受 FO / 提早，对他们的作业操作后，咱们须要给他们有个解释等等，这对如何筛选作业减少了难度，须要依据不同的场景在这里进行不同的取舍。咱们将业务的重要水平形象为作业的优先级指标，整个决策树须要思考的因子包含作业的优先级，超用水平，规格，黑白名单，以及血缘关系等。
对于具体的决策树而言，咱们首先是思考业务，谋求尽量升高对高优先级业务的影响以及缩小对业务的影响面，因而咱们优先思考非白名单的，低优的，超用多的，应用高的作业进行操作。然而因为优先级和超用数值并不是打消热点的最优门路，如果一些优先级高的作业应用十分多导致的热点，也就意味着 Inspector 须要限度很多低优先级的工作能力把热点降下来，而这意味着，从集群层面来说，对业务的影响面反而增大，并且热点打消工夫绝对变长，为了缩小影响面以及思考到可解释性，咱们还减少了从疾速打消热点为出发点的规定，也就是如果优先级高并且超用高于阈值，咱们会优先解决这类作业。另外，对于对作业操作的数量来说，咱们会设置一个回收的限度，仅回收足够资源让机器不热为止。
2.3.3.2 执行上的翻新
上述说的是决策树方面并重业务层的思考，接下来介绍再针对作业驱赶的执行操作上的，且深刻到软件侧的技术创新点：
对于「驱赶」操作而言，个别对 Pod 进行驱赶的过程，是将驱赶申请发往 API Server，删除 Pod 后，由调度器抉择其余节点将 Pod 调度下来。之前黑盒调度指的是在调度器这一环节上，Pod 会受到调度器各种插件的影响，给每个节点进行打分，绝对 Inspector 而言，最终 Pod 具体调度到哪一个节点的不确定性比拟大，不太明确，这会妨碍 Inspector 后续决策的进一步优化。而咱们针对这一点，提出白盒调度，将调度逻辑放入 Inspector 外部，由 Inspector 依据外部算法指定 Pod 所调度到的节点。整个过程会更明确和可控。具体白盒调度实现细节就是 Inspector 会创立 K8S 的 自定义的资源 ReserveResource，在外面指定好这个资源的所属 owner 就能够了，调度器这边曾经更改好调度的逻辑，适配 Inspector，每次调度 Pod 的时候，会先看 ReserveResource 这个预留的资源的 owner 外面，是否有这个 Pod，如果有，就白盒调度到指定的 Node 下来。不走调度器自身简单的调度逻辑。
执行的操作计划，除了「驱赶」，还有「限流」，限度整个作业的资源使用量。整个流程为 Inspector 向 JM 收回一个异步的更新申请，发送完申请 Inspector 这边流程就完结，JM 接管到这个申请之后，先长久化到 TM Pod 创立模板里，保障 新创建的 TM 以及 TM FailOver 了之后，所有 TM 资源限度配置是一样的，JM 保障了增量的 TM 统一后，再去批改线上存量的 TM 配置，向 API Server 发送 patch 申请批改 TM Pod spec 里的资源配置，TM Pod 所在节点的 kubelet 就会 watch 到这个变动，从而去批改 TM Pod 的 cgroup，借用 Linux 的能力动静限度 TM 的资源应用状况，从而造成「限流」这么一个成果。Inspector 之后会异步地去查看限流是否失效，与此同时在 K8S Event 中也能够察看到这个变动。
2.3.4 成果
从执行成果这一角度来看 Inspector 整个事中自愈，热点的打消的过程，比拟 high-level 一点，能够说就是升高低优工作的应用，将资源让位给高优工作，从而升高它的提早，这么个成果。对应图中来讲，从 CPU 维度而言，就是通过限度右边这个低优工作的 CPU 应用，缓解集群热点状况，让左边的高优工作延时升高。
上图为 Inspector 整体的集群成果，流量顶峰期间，产生了 100+ 的热点，通过开启 Inspector，将热点在 3min 内齐全压抑。
从单作业角度来看，当热点机器打消后，很显著的，处于热点机器的 TM 提早就被打消了，数据就会回追回来。
2.4 预先复原
2.4.1 业务流程
讲完事中自愈，对于预先复原流程来说，刚刚事中自愈中被限流的作业，如果在闲暇机器，它有应用需要，那么就须要把限度放开来。通过这种让作业使用量的峰值错开，在高优工作应用峰值过来后，低优工作仍可能应用闲暇的机器资源，复原延时，从而达到兼顾业务稳定性以及进步集群水位的成果。
2.4.2 决策树
同样，面对如何筛选作业的问题，也会有一个制衡，整个过程就和洗手相似，如果水龙头间接放开到最大，就会水花四溅，比照这里如果间接放开作业的资源应用过猛，单台机器作业资源使用量忽然疾速减少，就会将机器迅速打到热点，从而引发 Inspector 事中自愈，又会将作业资源使用量限度回去，反反复复就会导致如图中所示的这种「震荡」的问题，影响集群和作业的稳定性。因而，咱们须要通过正当管制作业复原的频率与数量，让作业可能平缓地追数据，防止震荡。
2.5 可观测性
2.5.1 整体建设思路
作为平台的 SRE，在服务上线后，须要特地关注服务的「业务成果」与「用户影响面」，比方看 Inspector 有没有做出一些无害的操作，呈现无害的操作的时候，须要提前想好它的预案，立马进行不当的操作并且回滚回去。因而须要建设残缺的可观测性能力。总体来说，可观测性能够分为两个角度，一个是偏运维的 SRE 角度，一个是偏应用的用户角度。
对于 SRE 而言，当有热点机器的时候，咱们须要看 Inspector 有没有做出操作，以及这个操作是否正当，因为失常状况下是没有热点机器的，再看看整个决策树是否能够优化。另外当天的后果复盘时，能够看看 Inspector 的影响面如何，从优先级角度而言，能够看到高优工作受影响比例，造成一个简略的报表，这些点咱们都须要可视化，来帮忙 Inspector 的一直成长从而进步集群的平安水位。
对于用户角度而言，当他们的作业呈现「提早」或者「FO」的状况时，能够用「可视化的大盘」来查看这些状况是否是 Inspector 操作导致的影响，从而让用户本人思考优化作业，包含调整资源，作业优先级调整等等，让用户答疑自闭环，缩小工单量。
2.5.2 成果
那么具体实现效果图而言，能够在 Grafana 上配置大盘，能够看到这段时间 Inspector 操作过的作业数目，以及各个优先级作业汇总状况，以及 误操作的作业名单，Inspector 操作的详情，包含热点机器 sn，作业优先级，热点机器超用数值等等。这些都能够帮忙 Inspector 一直的优化迭代。
给用户出现的大盘外面，用户能够通过「作业名字」来进行查问，失去 Inspector 是否有操作过这个作业，以及相应的批改倡议等等。
3. 整体规划和将来方向
3.1 打算蓝图
Flink Cluster Inspector 的定位是面向于集群异样的自愈零碎，冀望通过稳固，老本，效率三大畛域的异样进行自愈，实现 Flink 集群的主动驾驶。以后的能力次要集中于老本畛域，次要是针对各类热点机器进行自愈，包含 CPU，内存，磁盘三个维度。后续会往稳定性畛域，也就是单节点的异样，零碎服务的异样以及集群所承载的业务异样进行自愈，同时会往效率畛域拓展，对于整体集群水位以及库存方面的异样通过弹性的扩缩容能力进行自愈。
目前整个零碎都是围绕云原生构建的，在 Flink 零碎云原生化的背景下，运维能力也全面云原生化，基于云原生的技术栈如 Operator，SideCar，申明式 API 等，构建了围绕 CR 开发，基于 GitOps 的 CI/CD，以及可观测高可用的运维。而承载上述业务能力的技术内核，则是紧贴于调度零碎的异样自愈框架，咱们形象了针对异样自愈的感知, 决策, 执行三个关键环节，并通过一个对立的框架整合，不便各运维同学以插件式的形式疾速实现各自的业务需要。同时也深度贴合调度层，与 K8S 的同学协同，开发面向于 Flink 场景的调度器加强能力。
3.2 顶层视角
基于以上 Inspector 的能力，咱们将 Flink 集群打造成为一个将老本稳定性效率串联起来的联动零碎，进行精细化的老本管制。咱们定义了 24h 均匀平安水位和刹时平安水位，别离用来掂量集群的老本控制能力，和集群稳定性问题临界能力。通过设置以后所能达到的平安水位，当集群水位较低的时候，可能通过隔离业务，在业务影响面最低的状况下将机器下线。而如果集群水位过高，则疾速申请估算，进行机器的扩容。通过 Inspector 中动静容量维持模块，将集群水位始终管制在平安水位左近。
在某些紧急情况下，集群的瞬时值可能会过高，触发集群整体稳定性问题。当水位曾经超过了所可能承载的平安水位下限，则须要进入应急解决流程，通过 3-5-20 报警解决，批作业限度，大促紧急预案等打消异样。当水位仍在平安水位范畴内，由自愈服务进行兜底，通过自动化的将异样的机器或者业务进行隔离或限度，将稳定性问题主动复原。容量模块一直抬升水位，锻炼自愈服务的可靠性，而自愈能力的加强，又可能反过来晋升平安水位，进而抬升集群水位，造成联动。
