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