阿里超大規模 Flink 集羣運維體系介紹

摘要 ：本文整理自阿里雲實時計算高級運維專家王華 (尚付) 在 Flink Forward Asia 2021 生產實踐專場的演講。主要內容包括：

1. 演進歷史和運維挑戰

2. 集羣運維 Flink Cluster

3. 應用運維 Flink Job

一、演進歷史和運維挑戰

阿里的實時計算經歷了近 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 個過程：

1. 第一步是發現熱點機器，包括熱點機器的 CPU、內存、網絡、磁盤，難點在於熱點機器的閾值是來自 SRE 線上豐富的經驗。

2. 第二步是分析，我們做了一系列的機器診斷工具來定位熱點的進程，包括 CPU 到進程、IO 到進程，難點在於要求用戶對於 Linux 整個系統的原理有深入的理解和分析。

3. 第三步是業務的決策和策略，從熱點機器進程關聯到業務的數據做決策，不同的優先級能接受的策略是不一樣的。

4. 最後一步，纔是真正的解決熱點機器，低優先級通過降級或均衡，中高優先級則通過徑流來實現熱點機器的下降。

這個過程背後涉及的東西包括對業務的理解比如優先級、資源、配置畫像，對調度的原理的理解比如資源的分配策略、調度的策略，以及對系統內核的深度排查分析，還有業務的經驗和策略 —— 到底是限流還是降級。這樣全鏈路的界定和分析決策是一個非常複雜的技術難題。

我們正在做的是將熱點機器的完整解決方案全部沉澱下來，打造一個基於 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 平臺運維和應用運維碰到的穩定、成本、效率三大難題。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/nnmdC0pMgf8Wa6Yb47GH4Q