摘要：本文整理自阿裡雲實時計算進階運維專家王華 (尚付) 在 Flink Forward Asia 2021 生産實踐專場的演講。主要内容包括：
- 演進曆史和運維挑戰
- 叢集運維 Flink Cluster
- 應用運維 Flink Job
::: hljs-center
點選檢視直播回放 & 演講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 叢集運維和應用運維碰到的穩定、成本、效率三大難題。
::: hljs-center
點選檢視直播回放 & 演講PDF