嘉賓 | 董曉聰

出品 | CSDN雲原生

2022年9月1日，在中國信通院、騰訊雲、FinOps産業标準工作組聯合發起的《原動力x雲原生正發聲 降本增效大講堂》系列直播活動第7講上，作業幫基礎架構負責人董曉聰分享了作業幫的雲原生降本增效實踐。本文整理自董曉聰的分享。

為什麼要進行降本增效

作業幫的技術現狀可以歸納為兩點，分别是規模化和複雜化。

• 規模化：數千個應用服務，對應數萬個服務實例，運行在數十萬計算核心之上；

• 複雜化：技術棧極為豐富，涵蓋多種主流語言。

作業幫于2020年初開始走一條雲原生的道路，來解決發展過程中所遇到的穩定性、成本、效率及安全方面的問題。通過雲原生的改造，用基礎設施接管業務當中大量的非功能邏輯，以此實現彈性、可觀測性、韌性、自動化及可持續性。

為什麼要進行降本增效？

• 随着互聯網紅利的消退，企業希望能夠實現成本效益最大化；

• 資源浪費現象普遍存在，節省不必要的浪費；

• 從技術人員的角度來看，期望寫出更優質、更高性能的代碼。

在降本增效的過程中，我們需要明确一點：降本但不能降質，在降低成本的同時，穩定性、效率、安全等均不能為此打折扣。

在多種限制條件存在的情況下，該如何開展降本增效的工作呢？

應用層首先要做的是提升性能，即提升單位資源能夠支撐的業務并發量。對于作業幫來說，多元的技術棧給應用層的效能提升帶來了挑戰。

資源層降本增效的重點在于計算層面的優化，存在兩大挑戰：

• 尋找更優機型，提升單位成本的算力；

• 擁有合适的機型後，實現業務平滑無感地切換。

資源調度層有着巨大的優化空間，同樣也面臨諸多挑戰：

• 在線資源負載不高，對于高并發業務，為了應對頻繁的流量突增，需保證一定的Buffer，同時低流量業務通常長尾，進一步拉低了在線資源的利用率；

• 資源空間不足，在線資源利用率一般在30%，而大數據通常100%負載；

• 資源時間不均，互聯網業務資源的使用存在明顯的波峰、波谷。

應用層降本增效

應用技術棧改造

起初，作業幫采用PHP為服務端的主要開發語言，并使用ODP框架，能夠有效地支撐新業務的快速構建及發展叠代。但随着業務的發展，以ODP為代表的PHP服務端技術棧遇到了諸多問題：

• 性能瓶頸，PHP缺乏線程與協程的支持，在單位的并發下，資源使用率、業務成本高；

• 欠缺微服務支撐，ODP框架下，服務之間可以使用RPC進行調用，也支持混部後進行本地調用，服務之間邊界模糊、權責不清等問題開始顯現；

• 雲原生适配不足，雲原生帶來諸多技術紅利，如容器化、服務治理、DevOps等，但PHP适配性較低，無法與其結合。

于是我們選擇使用Go語言代替PHP作為服務端的主要開發語言。Go語言框架ZGIN基于GIN衍生而來，是面向Web服務的開發框架，提供了開箱即用的常見組件和功能，側重通用性和穩定性，兼顧性能和時延。

應用技術棧——整體設計

GIN是一個通用性應用框架，我們在GIN的基礎上做了性能優化，用來适配底層基礎架構技術方案，同時帶來業務場景下的性能提升。

與GIN相比，HttpServer中一直以性能著稱的fasthttp具有一個顯著的優勢：複用連接池。但我們并未在GIN的二次開發中實現連接池，而是将能力下移，借助底層架構的能力使多語言棧保持同等能力。大多數服務模塊目前已經接入Service Mesh，上遊請求與Mesh-Proxy建立連接，Mesh-Proxy和服務模塊之間通過UDS通信且保持長鍊接，同時優化UDS的零拷貝問題。

效率工具方面，提供簡單易用的代碼生成工具，根據腳手架快速地生成服務代碼。通過代碼生成工具，規範業務對框架的使用，減少業務後期追查及維護問題的成本。

測試環境互通工具方面，提供簡單的命令工具，将遠端測試環境的流量代理到本地端口，也可以将本地模塊的出流量轉發到測試環境之上。

應用技術棧——成果

經過兩年的發展，Go語言已演變成為作業幫使用最多的服務端語言，當前基于Go語言構建的模塊總計已達600 ，性能提升十分明顯。如上圖所示，使用Go語言重構應用模塊後能夠帶來五倍以上的性能提升。

核心系統雲原生改造

檢索系統作為公司最底層的核心系統之一，是C語言棧下的倒排索引和綜合策略索引，為智能推薦、資料智能分析以及搜索等提供底層支持。機器規模千台級别，計算核心達千萬核以上，時效數據達百TB，數據日增量為TB級别。

檢索系統——架構

檢索系統底層設施主要包括兩部分：數據産出服務與數據存儲服務。

由于檢索系統對低時延、高穩定性以及高吞吐性能的要求，早期選擇使用本地存儲，帶來了計算與存儲的耦合問題。随着數據量的增大，單機無法承載所有數據量，需要對數據進行切片，每個節點存儲部分數據。出于高并發、高可用的要求，每個切片還需有多個副本。

當數據需要更新時，由于數據量龐大，數據産出服務無法一次将全量的數據存至線上的節點中，隻能選擇部分數據進行同步，随後以該部分節點為基準進行二次、三次分發。這就導緻數據更新時間長、運維成本高、占用資源多等問題。

通過對檢索系統架構的分析，可以看出，當前的關鍵問題都是由于計算存儲耦合所導緻。隻有引入計算存儲分離的架構，才能從根本上解決複雜度的問題。而新的解決方案應該具備以下能力：

• 存儲讀取的穩定性應和本地持平；

• 存儲讀取的性能；

• 存儲讀取的易用性，最好支持POSIX接口；

• 數據叠代流程的可控性；

• 數據集合的可伸縮性。

基于上述要求，在技術選型方面，我們選擇了Fluid與JindoRuntime的組合。Fluid是開源的Kubernetes原生的分布式數據集編排和加速引擎，它通過數據的編排、應用數據的調度，解決雲原生過程中所遇到的一些列數據問題，如訪問數據的時延過高、多數據聯合查詢困難等。JindoRuntime是Fluid的一種分布式緩存Runtime實現，實現了HDFS、S3協議的訪問與緩存加速。

檢索系統——雲原生架構

通過雲原生改造，檢索系統變成了一個标準的無狀态容器應用，數據應用的過程得到簡化。

數據産出服務将數據傳到對象存儲中，Fluid驅動JindoRuntime完成對數據的加載。檢索的進程通過Fluid挂載的PVC訪問fuse，fuse将POSIX協議轉化為對遠端JindoRuntime的RPC訪問。

完成架構改造後，對檢索系統的瓶頸進行分析，發現導緻性能無法提升的原因在于跨NUMA的内存訪問帶寬存在上限。

通過添加調度器，使進程綁定NUMA，保證CPU和内存的訪問不跨NUMA，能夠使該問題得到妥善解決。

資源調度層降本增效的核心在于解決上文所提到的在線集群負載不高、資源空間及時間分布不均等一系列問題。

自定義調度器

容器化改造使得機器的平均負載得到顯著提升，但不同的機器之間差異較大，部分機器在業務高峰階段還需進行額外的運維工作，如人工封鎖高負載機器、人工驅逐不均衡Pod等。為什麼會出現這樣的問題呢？

主要原因在于Kubernetes原生調度器的調度依據以request為主，隻考慮簡單的指标，沒有考慮未來的變化。于是我們通過自定義調度器來解決此問題：

• 底層數據依賴Prometheus采集資源的真實使用情況；

• 結合曆史信息進行預測；

• 除了将CPU和内存作為指标考慮外，添加更多因子多維考慮。

在離線混部

互聯網業務都有明顯的波峰、波谷，波谷時段有大量的剩餘資源處在空閑狀态，考慮到大數據離線計算需要大量計算資源并對實時性的要求較弱，我們可以在在線集群的波谷時期運行大數據離線任務，達到節省計算資源的目的，實現雙赢。但在實際實施中，存在資源隔離無法避免幹擾、隔離效果差等問題。

對此，我們使用騰訊TLinux的新特性，在内核的CFS之間，添加一個新的調度器Offline，實現CPU避讓，并對空閑資源做預測調度。

Serveless廣泛使用

Serverless一直是作業幫技術架構探索的核心方向之一，用于解決資源分布時間不均的問題。Serverless的主要運行方案有兩種，一種是函數計算，另一種是K8s虛拟節點。K8s虛拟節點具有對現有服務無使用差異、用戶體驗較好、業務服務無感知的特點，可以基于現有基礎架構進行遷移。

Serverless技術挑戰——調度

Serverless具有較強的成本優勢，将在線服務高峰期彈性調度到Serverless上，可以大量節省資源成本。在推進Serveless的過程中存在諸多挑戰，在調度層需要解決兩個主要問題：

• 擴容時創建的Pod基于何種策略調度到虛拟節點；

• 縮容時應如何實現優先縮虛拟節點上的Pod。

有三種方案可以解決上述兩個問題。

• 方案一：原生标簽能力。通過Node Selector、節點親和等利用虛拟節點資源，但這種方式是割裂的，同一個服務無法運行在兩種類型的節點上。

• 方案二：雲廠商調度擴展。用戶無需指定Selector，當固定節點的資源不足時再調度到虛拟節點之上。但在集群資源已滿的情況下，才進行虛拟節點調度會導緻Pod部署過于密集，節點負載過高，影響業務穩定性。

• 方案三：自研調度器。将超過阈值的Pod調度到虛拟節點之上，其中阈值基于預測推薦 人工調整而定。這種方式可以有效兼顧穩定性和成本。

Serverless技術挑戰——觀測

日志采集方面，采用CRD配置日志采集，将日志發送到統一的Kafka，通過資源的日志消費服務，消費雲廠商的自有節點日志，實現虛拟節點和正常節點上的日志統一。

監控方面，雲廠商虛拟節點實現的Metrics接口和Kubelet完全兼容，可以無縫接入 Prometheus，完成對Pod實時CPU、内存、磁盤及網絡流量等的監控。

在分布式追蹤方面，由于無法部署Daemonset形式的jeager-agent，我們在jeager-client端做了改造，通過環境變量識别Pod的運行環境，如果是在虛拟節點上運行，則跳過jeager-agent，直接将分布式追蹤的數據推送到jeager-collector。

作業幫基于雲原生進行了一系列改造，最終實現了降本增效，整體的降本服務度已達到40%，未來會繼續探索更具性價比的降本增效方式。此外，作業幫運營工作當前已實現從靠人到靠平台的過渡，将進一步向BI化、AI化演進。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!