阿里实时计算平台的演进和运维

本文整理自阿里云实时计算高级运维专家王华 (尚付) 在 Flink Forward Asia 2021 生产实践专场的演讲。主要内容包括：演进历史和运维挑战、集群运维 Flink Cluster、应用运维 Flink Job。点击文末「阅读原文」查看原文视频 & 演讲 PDF。演进历史和运维挑战

阿里实时计算平台经历了近 10 年的快速发展，总体可以分成三个阶段：

目前，阿里的实时计算已经拥有了几百万核算力阿里云计算，几万台物理机，几万个作业，真正形成了一个超大规模的实时计算平台。而且在业务飞速发展过程中，平台整体的架构从云下的 Hadoop Flink 正在全面往云原生 K8s 加 Flink 大规模演进中。

面对这样一个实时计算的庞然大物，运维也随着时代变迁面临了不同的挑战：

集群运维 Flink Cluster

业务重要又敏感、平台规模体量大且架构复杂，面临这样的双重挑战，如何去维护集群的稳定性是一大难题。

一开始 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、反压，然后对这些海量数据做异常分析和决策找到隐患。总的来说可以分为两大类异常：

最终在平台侧和用户侧双管齐下，形成 SLA 异常自愈的闭环，从而减少 SLA 异常次数。在异常自愈服务里，其实最复杂的是背后规则的识别和决策。经过大量的积累，我们沉淀了几十种业务侧最高频的异常规则和治理方案，来全自动化地识别和消灭之前 “看不见” 的隐患，真正做到稳定性预防。

根据 SLA 异常的公式，除了通过预防来减少 SLA 次数，另外一个手段就是缩短 SLA 发生后的异常时长。

挑战在于线上一个集群就有近万个作业，但凡是集群级的故障都表现为定位困难、恢复时间久，再加上集群数量众多、分布广，故障的概率又增大，两者叠加，一年发生几次故障几乎就成了常态，稳定性整体很被动。我们需要化被动为主动，如果能在故障场景将业务的快速切流做到集群级的容灾能力，SLA 异常恢复的时长不仅能够缩短，而且还能增加其确定性。容灾体系主要分成三部分：

Flink 作业都是长生命周期的，带着 state 中间计算结果。首先要在集群的部署架构上做到计算和存储集群在物理部署上分离。计算集群出现故障时，比如基础设施出现异常等，可以通过切流将所有 Flink 作业平迁到另外一个灾备集群，但是 state 存储还是指向老的存储集群，就可以从原来的 state 点位恢复来实现真正透明的迁移，对用户做到无感。

除了日常的稳定性以外，双 11 更是稳定性的一场大考。Flink 双 11 的专项保障可以总结为 4 大块 8 个字，分别是压测、限流、降级、热点。每一块背后我们都沉淀了一套成熟的保障体系。

上图左上角显示，集群调度层面所有机器资源水位非常平均，CPU 和内存几乎在一条线上。但实际运行在集群上的所有机器的物理水位却参差不齐，因为调度是不感知物理使用的，所以随着集群水位不断提升，比如大促零点峰值的到来，集群的热点机器就会往更高去平移，某些机器在某一维度的资源会达到性能的瓶颈比如 CPU 使用了 95% 或者更高，从而就导致了热点机器。

而在分布式系统里，所有机上的业务是有状态并且有关联的，局部的热点机器不仅会影响集群稳定性，还会成为集群性能提升的瓶颈、造成成本浪费，也就是说，热点机器会是集群稳定性和水位提升的短板。

热点机器的解决是一个很棘手的问题，一般需要经历 4 个过程：

这个过程背后涉及的东西包括对业务的理解比如优先级、资源、配置画像，对调度原理的理解比如资源的分配策略、调度的策略，以及对系统内核的深度排查分析，还有业务的经验和策略 —— 到底是限流还是降级。这样全链路的界定和分析决策是一个非常复杂的技术难题。

我们正在做的是将热点机器的完整解决方案全部沉淀下来，打造一个基于 K8s 云原生的 Flink Cluster AutoPilot 来实现热点机器的全自动化自愈。

从部署形态上来看，AutoPilot 的服务基于 K8s 进行全托管，按集群维度进行轻量化的部署，通过配置文件来方便地管理和运维。而执行阶段则是由 K8s 来保证面向终态，保证最终一致性。从 AutoPilot 的技术能力上来看，它是通过将热点机器的全面度分析流程抽象成 6 个阶段，包括热点机器的定义、感知、分析、决策、执行及全过程的可观测性，来实现整个热点机器全自动化自愈和高可观测性，提升集群的稳定性以及降低成本。

在过去的几年里，围绕着运维稳定、成本、效率三大核心价值，SRE 在 Flink Cluster 超大规模集群运维上沉淀了大量运维能力和更好的运维平台。但是随着云原生化大浪潮的到来，运维能力如何基于云原生变得更标准化，运维的交互界面、操作模式、执行模式以及运维过程的可观测性如何建立更加统一的标准，都会成为我们未来的重点发展方向。Flink Cluster AutoPilot 会成为云原生下新技术的载体，来承载运维体系的不断演进和升级。

应用运维 Flink Job

伴随着实时计算的大趋势，Flink 的用户和作业数经历了飞速增长，现在平台上的作业数已经达到了几万个。但是众所周知 Flink 作业的运维是一个非常复杂的问题，列举一些日常用户最高频的咨询，比如为什么我的作业启动慢，为什么 Failover，为什么反压，为什么延时，如何调整资源配置来减少成本？这些看似简单的问题其实都非常复杂。

Flink 的作业运维难点有两个方面：

所以我们希望将自身丰富的运维知识，包括对系统全链路的调用流程，各个组件工作原理的深入理解，也包括日常和双 11 大促中丰富的排查问题的经验，以及优秀的排查思路，全部转化为数据和规则算法，沉淀为运维产品功能。这个产品主要有两个功能：

两者配套一起来解决 Flink 作业运维的难题。

上图是 Flink Job Adviser 最终呈现给用户的效果。用户只需输入作业名或链接，@一个机器人，就会调用 Adviser 服务。

Filnk job Adviser 背后还有几十种针对复杂场景的异常诊断能力，构成了一个庞大的经验决策树。它不仅能够定位正在发生的异常，还有能力预防异常，主要由三部分组成：

在决策树的具体实现里，选择了几个典型的、有复杂度的节点来进行分享。

最早决策树的实现都是静态的规则，但随着场景的复杂化，尤其是数据的暴增以及个性化场景的出现，静态规则无法再满足我们的需求，比如每个作业的延迟都是个性化的、报错无法再通过正则匹配来维护。我们正在积极尝试引入各种 AI 来解决这些个性化的问题。

通过 Filnk job Adviser 定位异常后，就需要 Filnk job Operator 来修复异常，形成一个闭环。Operator 能力主要由 4 大部分组成：

随着实时计算的发展，运维也经历了从人肉、工具化、平台化、智能化到云原生化的演进升级，我们一直秉承的思路是将丰富的实时计算运维经验能力全部沉淀到实时计算管控产品上，来解决超大规模实时计算运维的难题。

在整个体系中，最中间是集群和应用两个运维对象，外围的运维目标和运维价值一直都是围绕着稳定、成本、效率三大目标。运维的体系、技术和产品的载体，则是实时计算管控，通过实时计算管控来服务好上层的实时计算用户和产研、SRE 还有我们自己。同时运维管控的技术内核正在全力往智能化和云原生化演进。一句话总结，以智能和云原生为技术内核，建设实时计算运维管控产品，来解决超大规模 Flink 平台运维和应用运维碰到的稳定、成本、效率三大难题。（正文完）

阿里实时计算平台的演进和运维

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!