作者 | 王華

大資料運維在阿里雲實時計算叢集的落地實踐: 以數智為核心驅動的實時計算運維體系，解決穩定性、成本、效率三大運維領域需求。

一、演進歷史和運維挑戰

阿里的實時計算經歷了近 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 來解決這些個性化的問題。