共计 6823 个字符，预计需要花费 18 分钟才能阅读完成。
摘要：本文整顿自阿里云实时计算高级运维专家王华 (尚付) 在 Flink Forward Asia 2021 生产实践专场的演讲。次要内容包含：
- 演进历史和运维挑战
- 集群运维 Flink Cluster
- 利用运维 Flink Job
点击查看直播回放 & 演讲 PDF
一、演进历史和运维挑战
阿里的实时计算经验了近 10 年的疾速倒退，总体来说能够分成三大时代：
- 1.0 时代：2013 年到 2017 年，三大实时计算引擎并存。大家相熟的 Jstorm 和 Blink 过后都还叫做流式计算。
- 2.0 时代：2017 年团体合并了三大实时计算引擎，Blink 凭借着杰出的性能、高效的吞吐成为惟一的实时计算引擎，实现了大一统。在接下来的 4 年里，团体所有实时计算业务全副迁徙到 Blink，阿里的实时计算业务经验了最飞速的增长，平台规模体量也从千级别增长到万级别，实时计算 all on Blink。
- 3.0 时代：随着前两年阿里收买了德国 Flink 母公司，阿里中国和德国团队联手打造了基于云原生新底座、搭载 Flink 开源新引擎的 VVP 新平台。在 2021 年双 11，VVP 新平台以大幅度的性能晋升安稳撑持了双 11，宣告着阿里实时计算进入了全新的 3.0 时代。
目前，阿里的实时计算曾经领有了几百万核算力，几万台物理机，几万个作业，真正造成了一个超大规模的实时计算平台。而且在业务飞速发展过程中，平台整体的架构从云下的 Hadoop Flink 正在全面往云原生 K8s 加 Flink 大规模演进中。
面对这样一个实时计算的硕大无朋，运维也随着时代变迁面临了不同的挑战：
- 第一阶段是平台运维，外围是帮忙 SRE 解决超大规模体量的平台运维，也就是 Flink Cluster 集群运维的难题；
- 第二阶段是利用运维，外围是帮忙集群上大量的实时计算用户解决利用侧 Flink 作业运维简单的难题；
- 第三阶段是随着 3.0 时代的到来，集群底座全面云原生化，全域数据也随着云原生而标准化，运维能力如何向云原生和智能化疾速演进和晋升，成为咱们新的挑战。
二、集群运维 Flink Cluster
- 一方面，Flink 平台上运行着一个十分典型的业务，就是双 11 大促当天 GMV 媒体成交翻牌器，也就是妇孺皆知的成交额大屏，这个业务对于稳定性要求十分高。除了 GMV 翻牌器，Flink 还承载了阿里外部全副重要的实时计算业务，包含阿里妈妈、广告计量计费、搜寻举荐、机器学习平台等外围电商业务的实时场景。这些实时场景既重要又实时敏感，稳定性是第一大挑战。
- 另一方面，因为平台规模体量微小，波及到几万台独享机器，多地区的部署，平台体量增长带来的平台简单部署度的减少，所以部分异样又会成为常态，这是对稳定性的第二大挑战。
业务重要又敏感、平台规模体量大且架构简单，面临这样的双重挑战，如何去保护集群的稳定性是一大难题。
一开始 Flink 集群是用故障数来度量稳定性的，但实际上粒度很低，因为有很多未达到故障时长规范的稳定性异样是没有方法在最终的故障数中体现的，导致稳定性存在着盲区。前面咱们就打造了几套基于分钟级可用率的 SLA 可用率来度量整个集群的稳定性。
SLI 是用来计算 SLA 的黄金指标，它代表着 Flink Cluster 的可用性，因为集群是一个虚构的逻辑概念，所以咱们定义了 Flink 作业状态来代表 SLI。Flink 作业状态自身非常复杂，然而咱们能够简略形象出三种状态：调度中、运行失常、运行异样，每个作业都能计算出这三种状态，而后汇聚到集群层面造成作业的比例，一旦异样的比例超过某个阈值，就代表集群不可用，从而度量出 SLI 再算出全年的不可用时长。
最终 SLA 的可用率度量能够示意成一个简略的数学公式，SLA 可用率 = SLA 异样数 * SLA 均匀每次异样时长，来实现分钟级可用率精密度量衡集群稳定性。
有了精密的量化，接下来就是晋升的门路，也能够从上述公式动手去优化两个因子：别离是既做好稳定性的预防，来缩小 SLA 次数；同时也做好了 SLA 的疾速复原，缩短 SLA 时长，最终晋升整体的可用率。
首先是 SLA 异样预防局部，要害的思路是做好集群的巡检，被动发现异常隐患，及时毁灭隐患，从而缩小 SLA 异样的次数。
导致 SLA 异样隐患有哪些？比方一堆超大作业忽然启动，导致集群几百台机器 load 打高或者磁盘打满，引发大量作业心跳超时；再比如说某一个 Flink 版本存在重大的稳定性问题或缺点，影响了线上近千个作业。这些看上去很冷门的故障场景，实际上在一个超大规模的集群里和丰盛的业务场景状态下简直每天都在产生，这是平台倒退到肯定规模必然会呈现的挑战。而且集群规模越大，越容易呈现蝴蝶效应，影响面往往更大。此外，每次集群异样定位的复杂度和耗时都十分久，如何去毁灭这些 SLA 异样？
咱们的思路是打造一个 Flink Cluster 的异样自愈服务，通过定期扫描线上全量作业的行为数据比方作业的延时、Failover、反压，而后对这些海量数据做异样剖析和决策找到隐患。总的来说能够分为两大类异样：
- 一类是因为用户侧本身作业行为导致的，告诉用户去更改相应的作业，比方资源配置不合理导致 OOM、作业反压导致提早等；
- 另一类异样是因为平台侧问题版本导致的，平台侧会进行大规模的被动降级来毁灭这些问题版本。
最终在平台侧和用户侧并行不悖，造成 SLA 异样自愈的闭环，从而缩小 SLA 异样次数。
在异样自愈服务里，其实最简单的是背地规定的辨认和决策。通过大量的积攒，咱们积淀了几十种业务侧最高频的异样规定和治理计划，来全自动化地辨认和毁灭之前“看不见”的隐患，真正做到稳定性预防。
依据 SLA 异样的公式，除了预防来缩小 SLA 次数，另外一个伎俩就是缩短 SLA 产生后的异样时长。
挑战在于线上一个集群就有近万个作业，但但凡集群级的故障都体现为定位艰难、复原工夫久，再加上集群数量泛滥、散布广，故障的概率又增大，两者叠加，一年产生几次故障简直就成了常态，稳定性整体很被动。咱们须要转被动为被动，如果能在故障场景将业务的疾速切流做到集群级的容灾能力，SLA 异样复原不仅可能缩短，而且还能减少其确定性。
容灾体系次要分成三局部：
- 第一，是往哪里切，实时计算对于网络的要求都是毫秒级，跨城有几十个毫秒必定无奈满足实时的要求。所以在平台侧部署架构上做了计算同城双机房部署，两两容灾，互为主备切流布局，解决了故障场景有中央可切。
- 第二，资源容量是无限的，平台这么大的体量不可能有容灾资源做估算，所以就须要做取舍。取高优先级的业务舍低优先级的业务，如何辨别优先级？平台依据业务的场景建设了一套 Flink 作业的优先级规范，并配套着从申请到治理到整改，降级推出全过程的自动化管理体系，在业务侧精细化地区分优先级，确保真正高优业务的质和量。在资源无限的条件下，重保高优业务，以实现资源换资源。
- 最初一步是最简单的，如何通明切走作业。外围的思路是复用存储，保障计算通明切换来确保业务的无感。
Flink 作业都是长生命周期的，带着 state 两头计算结果。首先要在集群的部署架构上做到计算和存储集群在物理部署上拆散。计算集群呈现故障时，比方基础设施出现异常等，能够通过切流将所有 Flink 作业平迁到另外一个灾备集群，然而 state 存储还是指向老的存储集群，就能够从原来的 state 点位复原来实现真正通明的迁徙，对用户做到无感。
除了日常的稳定性以外，双 11 更是稳定性的一场大考。Flink 双 11 的专项保障能够总结为 4 大块 8 个字，别离是压测、限流、降级、热点。每一块背地咱们都积淀了一套成熟的保障体系。
- 第一块压测指的是压测平台，首先提供给用户将生产到影子作业一键克隆的能力，其次还会提供大量大规模精准的造压、控压、稳压能力，并提供作业自动化性能的调优，以及最初一步生产一键上线全自动化的一站式压测解决方案。
- 第二块降级指的是降级平台，因为在大促 0 点峰值，须要将低优先级的业务疾速降级来实现水位的正当管制。
- 第三块限流，还有一部分中优或高优业务，在大促状态不容许降级，然而能承受短时间的提早，所以平台还基于 Linux 内核的 Cgroup 实现了作业 Pod 资源的隔离和限度，从而达到作业粒度计算精准限流的成果。
- 第四块是热点机器，也是大促最简单的点。从集群层面看，集群卖出的资源和用户应用的资源是存在差别的，比方 1 个 Flink 作业申请了 10 个 CPU，而理论应用了 5 个 CPU，还有波峰波谷会导致集群层面水位不平衡。
上图第一个图显示，集群调度层面所有机器资源水位十分均匀，CPU 和内存简直在一条线上。但理论运行在集群上的所有机器的物理水位却参差不齐，因为调度是不感知物理应用的，所以随着集群水位一直晋升，比方大促零点峰值的到来，集群的热点机器就会往更高去平移，某些机器在某一维度的资源会达到性能的瓶颈比方 CPU 应用了 95% 或者更高，从而就导致了热点机器。
而在分布式系统里，所有机上的业务是有状态并且有关联的，部分的热点机器不仅会影响集群稳定性，还会成为集群性能晋升的瓶颈、造成老本节约，也就是说，热点机器会是集群稳定性和水位晋升的短板。
热点机器的解决是一个很辣手的问题，个别须要经验 4 个过程：
- 第一步是发现热点机器，包含热点机器的 CPU、内存、网络、磁盘，难点在于热点机器的阈值是来自 SRE 线上丰盛的教训。
- 第二步是剖析，咱们做了一系列的机器诊断工具来定位热点的过程，包含 CPU 到过程、IO 到过程，难点在于要求用户对于 Linux 整个零碎的原理有深刻的了解和剖析。
- 第三步是业务的决策和策略，从热点机器过程关联到业务的数据做决策，不同的优先级能承受的策略是不一样的。
- 最初一步，才是真正的解决热点机器，低优先级通过降级或平衡，中高优先级则通过径流来实现热点机器的降落。
这个过程背地波及的货色包含对业务的了解比方优先级、资源、配置画像，对调度的原理的了解比方资源的调配策略、调度的策略，以及对系统内核的深度排查剖析，还有业务的教训和策略 —— 到底是限流还是降级。这样全链路的界定和剖析决策是一个非常复杂的技术难题。
咱们正在做的是将热点机器的残缺解决方案全副积淀下来，打造一个基于 K8s 云原生的 Flink Cluster AutoPilot 来实现热点机器的全自动化自愈。
从部署状态上来看，AutoPilot 的服务是基于 K8s 进行全托管，按集群维度进行轻量化的部署，通过配置文件来不便地治理和运维。而执行阶段则是由 K8s 来保障面向终态，保障最终一致性。从 AutoPilot 的技术能力上来看，它是通过将热点机器的全面度剖析流程形象成 6 个阶段，包含热点机器的定义、感知、剖析、决策、执行及全过程的可观测性，来实现整个热点机器全自动化自愈和高可观测性，晋升集群的稳定性以及降低成本。
在过来的几年里，围绕着运维稳固、老本、效率三大外围价值，SRE 在 Flink Cluster 超大规模集群运维上积淀了大量运维能力和更好的运维平台。然而随着云原生化大浪潮的到来，运维能力如何基于云原生变得更标准化，运维的交互界面、操作模式、执行模式以及运维过程的可观测性如何建设更加对立的规范，都会成为咱们将来的重点倒退方向。Flink Cluster AutoPilot 会成为云原生下新技术的载体，来承载运维体系的一直演进和降级。
三、利用运维 Flink Job
随同着实时计算的大趋势，Flink 的用户和作业数经验了飞速增长，当初平台上的作业数曾经达到了几万个。然而家喻户晓 Flink 作业的运维是一个非常复杂的问题，列举一些日常用户最高频的征询，比方为什么我的作业启动慢，为什么 Failover，为什么反压，为什么延时，如何调整资源配置来缩小老本？这些看似简略的问题其实都非常复杂。
Flink 的作业运维难点有两个方面：一方面是分布式系统全链路组件很多，依赖很简单。另一方面是 Flink 本身尤其是波及到 RunTime 层面时，原理很简单。所以咱们心愿将咱们本身丰盛的运维常识，包含对系统全链路的调用流程，各个组件工作原理的深刻了解，也包含日常和双 11 大促中丰盛的排查问题的教训，以及优良的排查思路，全副转化为数据和规定算法，积淀为运维产品性能。
这个产品次要有两个性能，一个是 Flink Job Adviser，用来发现和诊断作业的异样；另一个是 Flink Job Operator，用来修复作业的异样。两者配套一起来解决 Flink 作业运维的难题。
上图是 Flink Job Adviser 最终出现给用户的成果。用户只需输出作业名或链接，@一个机器人，就会调用 Adviser 服务。
比方 Case1，作业因为资源有余无奈启动，adviser 会给出诊断后果，是因为某个作业资源有余，并附上改良倡议，让用户去控制台扩容对应的资源数量。
比方 Case2，用户的某一个作业 failover 了，他想晓得为什么。通过全域数据的关联，Adviser 给出的后果是因为平台侧机器下线或硬件故障自愈导致的，倡议用户无需做任何操作，期待自动化的复原即可。
再比方 Case3，因为用户作业内存配置不合理，频繁呈现 OOM 导致 failover。Adviser 就会倡议用户去调整对应计算节点的内存配置，防止新的 failover。
Filnk job Adviser 背地还有几十种针对简单场景的异样诊断能力，形成了一个宏大的教训决策树。它不仅可能定位正在产生的异样，还有能力预防异样，次要由三局部组成：
- 事先局部，通过作业的运行指标和零碎的全域事件来做预测，提前发现危险隐患，达到预防的成果，比方有作业发现的 failover 或者版本有问题等，这些异样还没有真正影响作业，通过体检可能发现这些问题。
- 事中局部，针对作业运行的全生命周期做诊断，包含启停类的问题，比方启动报错、启动慢、进行报错等，还包含运行起来性能有余、延时以及运行过程报错、数据一致性、准确性等问题。
- 预先局部，反对用户对于历史作业做全量的回溯。比如说想看昨天中午 failover 的起因。
在决策树的具体实现里，抉择了几个典型的、有复杂度的节点来进行分享。
- 第一个是作业全生命周期状态查看，一个作业从控制台提交到资源分配，再到运行环境、依赖下载，再到 Top 的创立，到上下游的加载，最初数据处理，整个链路是一个非常复杂的流程，Adviser 就是把要害节点的耗时和全量的事件对立收集起来进行剖析，最终可能做到在作业任何状态做异样诊断和定位。
- 第二个是作业运行态性能类的问题，次要针对各类实时监控指标做异样检测，或通过经验值、域值的判断来发现和剖析异样。比方作业延时了，那就通过节点找到反压所在的节点，再找到 TM 所在的节点，而后剖析机器异样，最初发现可能是某台机器 load 高。以此造成整个链路证据链的推导，做到关联下钻剖析，定位到实在的根因。
- 第三个就是最高频的问题，作业在运行过程中有报错。外围的思路是收集各个组件的日志，比方提交的日志、调度的日志、failover 和有 JM 和 TM 的日志，将这些海量的异样日志通过日志聚类的算法，包含自然语言解决和理论提取，来将一些非结构化的日志变成结构化的数据，再合并同类项进行压缩，最初由 SRE 和研发来进行起因标注和倡议，造成一套欠缺的专家教训。
最早决策树的实现都是动态的规定，但随着场景的复杂化，尤其是数据的暴增以及个性化场景的呈现，动态规定无奈再满足咱们的需要，比方每个作业的提早都是个性化的、报错无奈再通过正则匹配来保护。咱们正在踊跃尝试引入各种 AI 来解决这些个性化的问题。
通过 Filnk job Adviser 定位异样后，就须要 Filnk job Operator 来修复异样，造成一个闭环。
Operator 能力次要由 4 大部分组成：
- 第一种能力是降级，对作业问题版本进行通明降级以及配置的热更新，来解决作业在代码和配置等稳定性方面的隐患和异样。
- 第二种能力是优化，基于阿里外部的 Autopilot 来对作业进行性能的配置调优，从而帮忙用户作业解决性能和老本的问题。
- 第三种能力是迁徙，作业通过跨集群通明迁徙，次要帮忙用户在大规模作业场景下达到作业的高效治理。
- 最初一种是自愈修复，依据 Adviser 诊断出的各种危险和规定，配套有一键修复的自愈能力。
随着实时计算的倒退，运维也经验了从人肉、工具化、平台化、智能化到云原生化的演进降级，咱们始终秉承的思路是将丰盛的实时计算运维教训能力全副积淀到实时计算管控产品上，来解决超大规模实时计算运维的难题。
在整个体系中，最两头是集群和利用两个运维对象，外围的运维的指标和运维的价值始终都是围绕着稳固、老本、效率三大指标。运维的体系、技术和产品的载体，则是实时计算管控，通过实时计算管控来服务好下层的实时计算用户和产研、SRE 还有咱们本人。同时运维管控的技术内核正在全力往智能化和云原生化演进。
一句话总结，以智能和云原生为技术内核，建设实时计算运维管控产品，来解决超大规模 Flink 集群运维和利用运维碰到的稳固、老本、效率三大难题。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
