Serverless 給任務調度帶來的變化及螞蟻集團落地實踐

Serverless Task 是螞蟻集團在分佈式調度和批處理中間件發展而來的解決方案。通過 ServiceMesh 的精細化引流能力,再利用研發框架的“服務分組”配置能力,將 Serverless Task 流量全部收斂在指定的“服務分組”集羣內。結合定時任務本身具備的週期、可預測等特點,根據任務執行情況彈性伸縮“服務分組”內的機器資源從而提升資源利用率。


分佈式調度在螞蟻的場景和遇到的問題

在單體架構中,爲了解決一臺機器在固定的週期間隔執行相同的任務,避免人工干預過多,有了基於 Cron 的單機調度;隨着企業級應用的發展和微服務化以及雲原生架構的逐漸演進,原先的單體架構逐漸演變爲服務化或者雲原生架構。在此背景下,既要解決原先單機要解決的定時調度問題,還需要解決任務管理、負載均衡以及高可用、容災等問題,同時兼顧用戶體驗的簡單高效,分佈式調度產品就應運而生。

在螞蟻域內,分佈式調度廣泛應用於各個 BU 的業務場景中,舉例:如在支付寶上購買基金的用戶每天需要計算基金收益,那麼就需要在分佈式調度的基礎上結合批處理的能力,充分利用應用集羣的處理能力,完成每一個用戶基金淨值的收益計算,典型處理場景如下:

爲了充分利用集羣的能力,業務會採用按照業務各個維度拆分的方式對數據進行分片,然後根據分片原則加載數據,最後儘可能的將數據分散在集羣機器上完成每一個用戶基金淨值的計算。 通過類似上述集羣執行的方式,結合分佈式調度及批處理的能力,可以完成業務的計算訴求,但是由於這部分計算邏輯被原有的應用集羣承載,隨着業務的發展和數據量的不斷增加,就會有如下的問題:
穩定性問題 :在線流量如 RPC/MSG 等與任務調度流量(簡稱異步任務流量)在 CPU/MEM/線程池 資源共享而引發的相互搶佔導致的穩定性問題。

資源利用率問題:異步任務流量最常用 Cron 表達式來描述,對於一天 24 小時只需要運行 7 個小時的任務來說,剩餘的 17 個小時的資源就是浪費掉的。

效率問題:業務同學在接入任務調度以及對批處理執行的控制,數據量統計、異常歸類和動態調整參數等複雜性導致的研發效率較低;發佈上線後,對處理速度、資源容量評估以及穩定性投入導致的運維效率較低。

Serverless Task 解決方案

爲了解決上文分佈式調度在螞蟻的多年實踐中遇到的問題,我們提供了 Serverless Task 的解決方案。

通過故障隔離的方式來提高穩定性。Serverless Task 在不影響大家研發習慣的前提下,業務同學只需要通過在 PaaS 平臺中,在同一個集羣下申請“服務分組”集羣,這些機器用於達到只承擔異步任務的流量,而屏蔽其他在線流量的訪問的目的。機器資源承載的流量做區分後,再配合 ServiceMesh 的精細化引流能力能夠將流量收斂在指定的“服務分組”內,同時結合框架的“服務分組”配置能力,能夠指定 Bean、消息、任務或者服務是否註冊或者啓動。通過上述的方式,最終能夠實現,指定的異步任務收斂在指定的“服務分組”機器資源內,以此實現在線流量和異步任務流量的故障隔離,避免相互影響,而提升系統的整體穩定性。

通過彈性伸縮的方式來提高資源利用率。 基於可控彈性伸縮 HPA 技術,通過分析任務的 Cron 表達式或者基於 CPU/Mem/線程池等各項正常或者異常指標,能夠將隔離在指定“服務分組”內運行異步任務的機器動態調整其 Pod 數量,在滿足業務處理訴求的前提下,通過彈性伸縮技術最大化的提升資源利用率。

提供更加產品化的能力。Serverless Task 支持處理器編排、支持迭代隔離、自定義參數和自定義限流等能力以提升業務的研發效率;同時,異步任務在故障隔離的基礎上,利用彈性伸縮技術動態調整業務的 Pod 資源數量,可以讓業務研發同學儘可能少的關注資源而只需關注任務的運行情況,以此極大的提升運維效率。

Serverless Task 關鍵能力介紹

  • 彈性伸縮技術

上文介紹了 Serverless Task 的解決方案思路,爲了真正實現 Serverless ,讓業務同學不關注容量只關注業務邏輯,一個很重要的技術能力就是彈性伸縮。

彈性伸縮技術,通過分析任務的 Cron 表達式或者基於 CPU/Mem 等各項指標計算出來的畫像(每個時刻期望的 Pod 副本數量),來確定每個時刻的應該 Ready 的 Pod 數量,當在流量低峯或者任務沒有在運行的時間就可以將機器縮容到相對較小的副本數。同時爲了能夠在最短的時間內恢復業務 Pod 的運行,啓動速度是一個至關重要的指標,採用基於 ServiceMesh、JVM Elastic Heap 和內存 swap 的容器保活技術實現極速啓動,來保證業務容器再恢復到期望的副本數時,有足夠快的速度。

  • 任務鏈路隔離與伸縮能力

通過上面描述的 Serverless Task 的解決方案,能夠將異步任務的流量收斂在一個業務集羣指定的“服務分組”集羣內,並能夠在彈性伸縮的基礎上充分利用機器資源。但是,這樣就會導致新的問題,當上遊系統被隔離後,其處理速度和穩定性都會一定程度的增加,但是對下游的調用量就會激增,導致下游出現熱點或者穩定性問題。基於此,我們提供了任務鏈路的解決方案,期望將 Serverless Task 觸發異步任務的門面系統以及對下游系統的調用,都能夠通過“服務分組”的方式隔離開,期望組合成一條異步任務流量作爲入口流量的任務鏈路,具體的實現方案如下所示。

每一個 Serverless Task 在週期觸發時都會自動攜帶染色標識(每一個異步任務的唯一標識),通過在任務調度平臺選擇當前異步任務要引流到的“服務分組”,就可以完成門面系統的 Serverless Task 到指定“服務分組”的引流。每一次 Serverless Task 調用門面系統均攜帶染色標識,門面系統緊接着對下游系統再發起調用,門面系統結合控制面的業務引流能力,就可以在控制面對門面系統下發引流規則,並配置流量比例,便可以將門面系統對下游系統的調用也收斂在指定的“服務分組”集羣內。以此類推,下游系統如果繼續有對後續系統的調用,也可以採用類似的方式推送引流規則來完成指定調用流量的“服務分組”集羣收斂,以此來完成一條 Serverless Task 作爲入口流量的任務鏈路的流量隔離,並具有單獨的業務語義,比如:批扣鏈路、計價鏈路。

在完成了任務鏈路的隔離之後,由於入口的流量是由異步任務驅動或者觸發的,流量是能夠通過 Cron 或者運行狀態做比較準確的預測,那麼在任務鏈路執行完畢後,就可以將整個鏈路的資源全部伸縮掉,同樣當異步任務的流量高峯到來之前時再擴容出足夠的機器資源,以此在隔離出任務鏈路的同時,還能提升整體任務鏈路的穩定性以及整個任務鏈路的資源利用率。

總結與展望

通過 ServiceMesh 的精細化引流能力,可以將 Serverless Task 流量收斂在指定的“服務分組”集羣內,再利用框架(如 SOFA Boot)的“服務分組”配置能力,控制非期望的 Bean 和服務在“服務分組”集羣內關閉,最終就能夠做到將 Serverless Task 流量完整的收斂在指定的服務器集羣內,達到流量收斂的目的後,再結合定時任務本身具備的週期、可預測等特點,就可以根據任務執行情況彈性伸縮“服務分組”內的機器資源從而提升資源利用率。

鑑於 Serverless Task 給業務帶來穩定性和資源利用率提升的業務價值,還能夠提升業務的研發效率,我們還會繼續支持更多調度以及批處理業務場景的 Serverless 化,如:金融交互文件場景、ODPS 離/在線轉換場景和 FTP 文件處理場景,歡迎大家關注。

  閱讀延展


本文分享自微信公衆號 - 金融級分佈式架構(Antfin_SOFA)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章