(網(wǎng)經(jīng)社訊)本文整理自作業(yè)幫基礎架構負責人董曉聰在云原生實戰(zhàn)峰會上的分享，講解作業(yè)幫降本增效實踐的道路上遇到的問題及經(jīng)驗，主要分為三個方面。一是作業(yè)幫的業(yè)務和現(xiàn)狀，以及為什么要做降本增效。第二，如何和阿里云一起解決在降本過程中遇到的一系列挑戰(zhàn)，最后是對未來技術趨勢的展望。
01
背景
作業(yè)幫成立于 2015 年，是一家以科技手段助力普惠教育的公司，公司主要的業(yè)務分為兩大板塊。第一，作業(yè)幫 APP 是一款典型的流量互聯(lián)網(wǎng)產(chǎn)品，二是作業(yè)幫直播課，是一款典型的產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品，涵蓋教育主播鏈條，如教研、教學、教務、輔導等。
我是 2019 年十月份加入作業(yè)幫的，當時我看到作業(yè)幫的技術現(xiàn)狀歸納為兩點。一是規(guī)?；?，另外是復雜化。
規(guī)?；鹤鳂I(yè)幫線上有數(shù)千個應用服務，這么多應用服務對應數(shù)萬個服務實例，這么多的服務實例跑在數(shù)十萬的計算核心之上；
復雜化：作業(yè)幫整體的技術棧是比較多元的。
其中占比最高的技術棧是 Golang 和 PHP，還有大量模塊是 C++、Python、Java 等進行編寫的，作業(yè)幫創(chuàng)業(yè)之初就在云上，充分享受了云計算的紅利，后來由于一系列原因創(chuàng)建了多元的架構，性能快速迭代也是我們一貫的追求。那為什么要進行降本增效呢？這個事之前也一直在做，只不過今天需要做得更好，其中有幾點原因：
第一點，隨著互聯(lián)網(wǎng)紅利的消退，企業(yè)希望每一分錢得到最大的收益，實現(xiàn)成本效益最大化。第二點，雖然我們一直在強調(diào)降本增效，但肯定還是有不必要的支出存在，這些浪費是應該被節(jié)省的。第三點，作為技術人員的夢想，還是想寫出更優(yōu)質(zhì)、更高性能的代碼。
在降本增效的過程當中要注意一點，降本不能降質(zhì)，降低成本時穩(wěn)定性、效率、安全不能打折扣。我們看一下成本模型。
各種各樣的特性和功能應用在計算機上其實是一個一個的代碼模塊，這些代碼其實還是需要各種各樣的資源來運作，有計算、存儲、網(wǎng)絡等等，那么我們看一下這個模型里降本增效怎么來做。
首先公司肯定希望自己的用戶越來越多，使用越來越活躍。其次，在應用側(cè)降本增效做的事情就是要提升單位算力承載量，通俗來講就是 QPS。但我們面臨的一個挑戰(zhàn)就是作業(yè)幫技術棧太多元了，我們?nèi)绾握w提升？再看資源側(cè)，存儲、網(wǎng)絡這些資源要么是剛需，要么就是很難控制成本。資源側(cè)降本的重點還是計算資源，而對于計算資源我們需要提升單位成本的算力。
我們面臨的挑戰(zhàn)是什么呢？就是如何選擇更優(yōu)的機型以及在選擇完機型之后，如何讓業(yè)務更加快速、無感、平滑
第一，我們在線業(yè)務集群的負載并不高。對于高吞吐的業(yè)務一般作為核心業(yè)務，這些業(yè)務要留一定的空閑。對于低負載的業(yè)務要有碎片化和長尾化，把線上負載率拉低了。一方面是在線業(yè)務負載并不高，另外一方面是大數(shù)據(jù)離線計算要貼地進行，形成空間不均，還有時間上的不均，互聯(lián)網(wǎng)業(yè)務有明顯的波峰波谷。在線教育更加明顯，波峰波谷會差兩個數(shù)量級，我們一直在為波峰進行買單。
02
如何做到降本增效
上面列舉了相關的問題和挑戰(zhàn)，作業(yè)幫是如何來做的呢？我們選擇和阿里云一起，選擇開源的力量再結合一定的
在部署側(cè)，通過 GPU 調(diào)度、ECS，在離線混部解決空間和時間的不均。在資源 K8s 技術實現(xiàn)應用透明無感，這樣替換機型變得更加快捷。
下面基于應用、部署簡單來聊。
應用這一層對主流技術棧進行優(yōu)化。第一，我們是重新編譯，我們以 FastCGI 運行，對非線程安全進行編譯，還有服務注冊發(fā)現(xiàn)，摒棄之前傳統(tǒng)基于名字服務，為了進一步提升性能和成功率，我們還做了 LocalDNS，使用更新的內(nèi)核 4.10+，和阿里云內(nèi)核團隊進行相應的調(diào)優(yōu)、優(yōu)化解決一系列問題，解決 IPVS 過多的性能和穩(wěn)定性問題。
最后得益于 Terway 網(wǎng)絡以及網(wǎng)絡做
要解決上述問題要做計算和存儲的分離，我們引入 Fluid 做一個關鍵的紐帶。Fluid 是一款基于 K8s 的數(shù)據(jù)編排系統(tǒng)，用于解決云原生過程中遇到的訪問數(shù)據(jù)過程復雜、訪問數(shù)據(jù)慢等一系列問題，JindoRuntime 用于實現(xiàn)緩存的加速，當我們使用 Fliud 和 JindoRuntime 完成整個檢索系統(tǒng)的重構之后，獲得的收益也比較明顯。
首先，作業(yè)幫的數(shù)據(jù)更新周期從之前小時級別縮短到三分鐘以內(nèi)，運維整個機器交付從之前天級別縮短到了小時級別，程序性能也得到大幅度提升，提升比例有 30%，帶來了萬核級別資源的縮減。
我們再聊一下部署
作業(yè)幫 GPU 服務所使用的算力和顯存相對比較固定，我們就實現(xiàn)了一套匹配機制。類似經(jīng)典的背包問題。當完成整體一套之后，線上 GPU 資源的使用率得到了大幅度的提升。在離線混部是工程領域比較經(jīng)典的問題，一方面是在線集群在波谷時有大量的空閑資源，另一方面大數(shù)據(jù)離線計算需要海量的計算資源，同時離線計算對時級要求并不高，所以兩者結合會有雙贏的結果。
但之前很大的技術瓶頸在于如果混
作業(yè)幫整體 CPU 資源有三個池子，一個是 online CPU 機器，一個是 GPU 的 CPU 機器部分應用起來，第三部分是 ECI ，通過 Pod 數(shù)目加減實現(xiàn)策略，包括定時 HP 策略，像一些 AI 模塊，只有在固定課程才會應用到，我們提前將課表導入，在上課之前把相關服務提起即可，我們也給線上服務增加一定 AutoHP 的策略。
03
未來展望
未來，作業(yè)幫會將定時業(yè)務、AI 計算遷到 ECI 之上來實現(xiàn)真正在線業(yè)務的削峰，并且我們將持續(xù)探索更具性價比的 IaaS 資源，這也是我們一直嘗試和探索的方向。目前，作業(yè)幫已經(jīng)和阿里云有一個關于 AEP 的 tair 方案的結合，在新的一年希望我們有更大規(guī)模的落地。文章里講得比較多的是關于降本做的一些技術改進，其實在降本增效這里面還有很大一塊工作量是運營，成本運營我們也通過自動化實現(xiàn)了平臺化，未來我們將會進一步向 BI 化、AI 化去演進。
