乾貨 | 起底eBay Flink的上雲之路

供稿 | Rheos Team 徐朝暉

編輯 | 顧欣怡

本文2238字，預計閱讀時間7分鐘

更多幹貨請關注“eBay技術薈”公衆號

導讀

Apache Flink作爲低延遲、高吞吐的大數據計算引擎，在實時數據處理領域有着優越的地位。本文將從 集羣生命週期管理、Job生命週期管理、Job快照管理 三個方面介紹eBay Rheos Team如何將Flink算力服務化、便捷化。希望能給同業人員相應的借鑑與啓發。

實時數據處理是當前數據生態的熱門關注環節，是業務創新的重要前提。 Flink 從誕生之初就定位於實時計算的框架和引擎，演化至今，已經發展成爲實時數據處理領域的佼佼者。然而，Flink的使用門檻比較高，加上集羣本身的維護和job狀態管理並不容易，業務開發者們往往就會望而卻步。事實上，我們仍有多種途徑可以使Flink更加服務化、便捷化。

本文將分享我們在eBay內部如何提供 Flink服務的端到端管理 ，以解決業務開發者的後顧之憂，讓他們專注於業務領域的創新，而無需煩心平臺層面的維護。

從平臺提供者角度，爲了讓Flink服務更觸手可及並穩定可靠地運行，我們需要完整的組件來支撐。而云基礎設施高度動態的運行時特徵，也決定了平臺需要具備更加彈性的機制來保證Flink集羣的 容錯性和雲原生特性 。

一、集羣生命週期管理

Flink集羣構建於 Tess 之上，Tess是eBay對Kubernettes的定製和增強，是eBay內部使用的下一代雲平臺。我們採用 Tess Deployment 來構建Flink cluster的TaskManager(TM)和JobManager(JM)。Deployment的特性使得單個Pod即便因爲各種原因被異常銷燬或退出，也能被Controler自動帶起，實現一定程度上的高可用和容錯機制。 JM 的持續健康對集羣至關重要，因爲JM掌控着job的狀態管理，以及統籌job的checkpoint機制。

爲此，我們支持JM的Active-Standby架構，通過Zookeeper來實現主備之間的快速切換。

跟Tess交互，實現集羣從構建、配置更改、伸縮擴展到銷燬刪除，這些過程涉及到複雜的元數據管理和事件處理。 NAP Service(MilkyWay) 是eBay內部廣泛使用的Tess應用管理平臺，通過定義 CRD(Custom Resource Definition) 來管理應用的狀態和組件之間的依賴，並提供接口以操作相應組件，此處可類比成k8s的Operator。

Flink集羣的構建和維護正是依賴於 Milkyway 的這種能力，通過集成Milkyway接口，實現集羣層面的生命週期管理，詳見圖1。在這一過程中，我們設計實現了豐富的運維工作流，以支持不同業務場景下集羣的演化和伸縮，這些工作流運行於eBay自研的工作流引擎NAP Workflow之上。

在Flink服務化的過程中，我們也構建了 精細的權限管理和Quota管理 ，以實現不同租戶（一個租戶通常對應一個業務小組）之間資源的隔離性，同時避免資源競爭。此外，爲保證服務的穩健性，我們也內建了 自動重試機制和熔斷機制。

圖1（點擊可查看大圖）

二、Job生命週期管理

平臺構建的Flink集羣運行於 會話模式（Session Mode） ，意味着集羣的生命週期與job的生命週期是互相獨立的。這帶來的好處是，允許job多次啓停調試而無需重建集羣，節省了集羣頻繁重建的耗時。同時，多個job能共用一個集羣，也在一些場合下提升了資源利用率。

我們集成了Flink的restful接口來實現job的生命週期管理。通常情況下，在提交job之前，用戶需要上傳job jar包到Flink集羣裏，而後基於此jar包來提交job執行。另一方面，具備複雜業務邏輯且包含了依賴的jar包，通常都比較大。當增長到幾百兆的大小時，本地上傳jar包的體驗就非常差，因爲本地到線上集羣的網絡傳輸效率普遍較低，而本地到生產環境的集羣甚至是隔離的。

爲此，我們在Flink內部增強了 jar包管理模塊 ，使得集羣能從就近的存儲系統主動下拉jar包到本地，而後基於此jar包提交任務。同時，我們還開發了一個 maven插件 ，當用戶在項目中引用插件後，就能一鍵實現打包和上傳jar包到存儲系統。爲了讓提交到集羣后的job和平臺中維護的job元數據狀態同步，我們在Flink端增強了一個 回調機制 ，每次當job狀態切換時，就會生成一個事件，而後這個事件會推送到平臺端以更新元數據狀態。

通過這些，用戶就能在平臺上一站式管理job的生命週期，詳見圖2。

圖2 （點擊可查看大圖）

Flink任務通常是一個長期無間斷運行的流數據處理邏輯，但用戶有時也會有臨時中斷job做參數調製或debug的需求。用戶發起的job管理命令，經平臺驗證合法後，就會進一步下發到集羣執行， job狀態遷移詳見圖3。

圖3 （點擊可查看大圖）

三、Job快照管理

Flink原生支持job的checkpoint機制，通過定期給任務內部的狀態數據打快照而實現job的容錯能力。爲實現高可用，這些快照數據都需要落盤存儲到指定的集羣內共享目錄。然而，在雲環境下，用戶很難知道哪些目錄可用。爲此，我們設計實現了一系列的定製和增強，使得用戶透明無感地享受到job的容錯能力。

首先，我們爲集羣內的每個Pod以local-volume的形式掛載Cephfs到指定路徑。

而後，我們定製了Flink job狀態數據的管理機制，使得觸發出來的checkpoint數據都能落到指定目錄。

此外，我們還設計了合理的Cephfs目錄結構，使得多租戶環境下，同一租戶建的集羣之間能互通數據，而不同租戶之間集羣的數據互相隔離。

Job的checkpoint是由Flink運行時自動觸發和管理的。而savepoint則由用戶按需觸發的狀態數據保存方式，以便job下次啓動時能達到斷點續傳的效果。我們在平臺端實現了給job定期觸發savepoint的功能，以便在碰到錯誤或需要replay數據的場景下，讓job能穿梭到過去的任何時間點繼續運行，詳見圖4。爲了避免savepoint數據膨脹，我們也引入了retention機制，以清理過期數據。

圖4 （點擊可查看大圖）

四、監控和智能運維

在雲環境裏，機器的維護和硬件故障是常態。因此，實時監控集羣的健康狀況，並配置異常告警系統就很有必要。

我們爲Flink集羣的各節點都內置了 監控模塊 ，以蒐集節點本地的運行時特徵。同時藉助 Prometheus 收集各節點數據，匯聚成集羣層面的健康指標，當探測到潛在風險時，及時通過AlertManager發出告警通知。節點和job的監控數據也同時發往eBay內部的統一監控平臺，以便用戶端查看指標報表和訂閱異常告警。

人爲處理異常告警是一項非常繁瑣的運維工作，所以我們還搭建了一套智能運維繫統以優化操作。當運維繫統收到告警後，經過初檢判斷是否爲假告警，而後根據先前積累的經驗，採取一系列補救措施來把集羣帶回到健康狀態。只有當運維繫統無法處理或補救措施效果不明顯時，系統纔會將告警轉發至管理員，由人工介入。