簡介：目前，作業幫已經和阿里云有一個關于 AEP 的 tair 方案的結合，在新的一年希望我們有更大規模的落地。文章里講得比較多的是關于降本做的一些技術改進，其實在降本增效這里面還有很大一塊工作量是運營，成本運營我們也通過自動化實現了平臺化，未來我們將會進一步向 BI 化、AI 化去演進。

本文整理自作業幫基礎架構負責人董曉聰在云原生實戰峰會上的分享，講解作業幫降本增效實踐的道路上遇到的問題及經驗，主要分為三個方面。一是作業幫的業務和現狀，以及為什么要做降本增效。第二，如何和阿里云一起解決在降本過程中遇到的一系列挑戰，最后是對未來技術趨勢的展望。

背景

作者 | 董曉聰

作業幫成立于 2015 年，是一家以科技手段助力普惠教育的公司，公司主要的業務分為兩大板塊。第一，作業幫 APP 是一款典型的流量互聯網產品，二是作業幫直播課，是一款典型的產業互聯網產品，涵蓋教育主播鏈條，如教研、教學、教務、輔導等。?我是 2019 年十月份加入作業幫的，當時我看到作業幫的技術現狀歸納為兩點。一是規模化，另外是復雜化。

• 規模化：作業幫線上有數千個應用服務，這么多應用服務對應數萬個服務實例，這么多的服務實例跑在數十萬的計算核心之上；
• 復雜化：作業幫整體的技術棧是比較多元的。

其中占比最高的技術棧是 Golang 和 PHP，還有大量模塊是 C++、Python、Java 等進行編寫的，作業幫創業之初就在云上，充分享受了云計算的紅利，后來由于一系列原因創建了多元的架構，性能快速迭代也是我們一貫的追求。那為什么要進行降本增效呢？這個事之前也一直在做，只不過今天需要做得更好，其中有幾點原因：?

第一點，隨著互聯網紅利的消退，企業希望每一分錢得到最大的收益，實現成本效益最大化。第二點，雖然我們一直在強調降本增效，但肯定還是有不必要的支出存在，這些浪費是應該被節省的。第三點，作為技術人員的夢想，還是想寫出更優質、更高性能的代碼。?在降本增效的過程當中要注意一點，降本不能降質，降低成本時穩定性、效率、安全不能打折扣。我們看一下成本模型。

各種各樣的特性和功能應用在計算機上其實是一個一個的代碼模塊，這些代碼其實還是需要各種各樣的資源來運作，有計算、存儲、網絡等等，那么我們看一下這個模型里降本增效怎么來做。?

首先公司肯定希望自己的用戶越來越多，使用越來越活躍。其次，在應用側降本增效做的事情就是要提升單位算力承載量，通俗來講就是 QPS。但我們面臨的一個挑戰就是作業幫技術棧太多元了，我們如何整體提升？再看資源側，存儲、網絡這些資源要么是剛需，要么就是很難控制成本。資源側降本的重點還是計算資源，而對于計算資源我們需要提升單位成本的算力。?

我們面臨的挑戰是什么呢？就是如何選擇更優的機型以及在選擇完機型之后，如何讓業務更加快速、無感、平滑的過渡過來。在應用和計算資源的中間還有一塊巨大的提升空間，就是兩者之間的匹配和部署的問題。在部署側我們也面臨一些困難和挑戰。

第一，我們在線業務集群的負載并不高。對于高吞吐的業務一般作為核心業務，這些業務要留一定的空閑。對于低負載的業務要有碎片化和長尾化，把線上負載率拉低了。一方面是在線業務負載并不高，另外一方面是大數據離線計算要貼地進行，形成空間不均，還有時間上的不均，互聯網業務有明顯的波峰波谷。在線教育更加明顯，波峰波谷會差兩個數量級，我們一直在為波峰進行買單。

如何做到降本增效 ? ?

上面列舉了相關的問題和挑戰，作業幫是如何來做的呢？我們選擇和阿里云一起，選擇開源的力量再結合一定的自研進行相關問題的解決。在應用層面，我們提升了主流技術棧的運行性能，對于使用最多的檢索服務進行架構的重構，以此來提升性能和運維效率。

在部署側，通過 GPU 調度、ECS，在離線混部解決空間和時間的不均。在資源 K8s 技術實現應用透明無感，這樣替換機型變得更加快捷。?

下面基于應用、部署簡單來聊。

應用這一層對主流技術棧進行優化。第一，我們是重新編譯，我們以 FastCGI 運行，對非線程安全進行編譯，還有服務注冊發現，摒棄之前傳統基于名字服務，為了進一步提升性能和成功率，我們還做了 LocalDNS，使用更新的內核 4.10+，和阿里云內核團隊進行相應的調優、優化解決一系列問題，解決 IPVS 過多的性能和穩定性問題。?

最后得益于 Terway 網絡以及網絡做的持久化，可以對性能有更明顯的提升。完成之后裸框架可以有幾倍的提升，可以帶來 43% 左右的收益。檢索服務作為底層服務，對其性能要求比較高，傳統架構一般是計算存儲耦合在一起的，隨著底下文件數量越來越多，單機無法容納，要進行切片。每個切片要高可靠、高性能，由此形成二維矩陣，這種情況下存在諸多的問題，比如說像數據更新周期長、整體運維效率并不高，還有系統的瓶頸遲遲得不到解決。

要解決上述問題要做計算和存儲的分離，我們引入 Fluid 做一個關鍵的紐帶。Fluid 是一款基于 K8s 的數據編排系統，用于解決云原生過程中遇到的訪問數據過程復雜、訪問數據慢等一系列問題，JindoRuntime 用于實現緩存的加速，當我們使用 Fliud 和 JindoRuntime 完成整個檢索系統的重構之后，獲得的收益也比較明顯。?

首先，作業幫的數據更新周期從之前小時級別縮短到三分鐘以內，運維整個機器交付從之前天級別縮短到了小時級別，程序性能也得到大幅度提升，提升比例有 30%，帶來了萬核級別資源的縮減。?

我們再聊一下部署側，作業幫線上有大量 AI 推理類業務，不光是圖像識別 OCR、語音識別、合成這一塊。這些業務計算 GPU 長時間脫離整個運維體系，我們希望通過容器化改造將其納管到統一運維體系里來。我們調研業界主流的技術方案，它們或多或少都會對 GPU 性能造成一定損耗，最后我們選擇了阿里云開源方案實現了 GPU Share 的調度方案。

作業幫 GPU 服務所使用的算力和顯存相對比較固定，我們就實現了一套匹配機制。類似經典的背包問題。當完成整體一套之后，線上 GPU 資源的使用率得到了大幅度的提升。在離線混部是工程領域比較經典的問題，一方面是在線集群在波谷時有大量的空閑資源，另一方面大數據離線計算需要海量的計算資源，同時離線計算對時級要求并不高，所以兩者結合會有雙贏的結果。

但之前很大的技術瓶頸在于如果混部在一起，離線計算大量消費 CPU 和網絡資源，會使得混部的在線資源服務成功率以及時延有大幅度的下降，使用阿里云 CFS 實現 CPU 的避讓，實現空白避讓以及混部。截止到目前，有萬核級別的計算跑在在線集群上，為了進一步保證線上穩定，我們在晚高峰也做實時的調度，將離線計算份額進行縮減，完成這一套之后得到了兼顧穩定性和成本的方案。?

作業幫整體 CPU 資源有三個池子，一個是 online CPU 機器，一個是 GPU 的 CPU 機器部分應用起來，第三部分是 ECI ，通過 Pod 數目加減實現策略，包括定時 HP 策略，像一些 AI 模塊，只有在固定課程才會應用到，我們提前將課表導入，在上課之前把相關服務提起即可，我們也給線上服務增加一定 AutoHP 的策略。

未來展望

未來，作業幫會將定時業務、AI 計算遷到 ECI 之上來實現真正在線業務的削峰，并且我們將持續探索更具性價比的 IaaS 資源，這也是我們一直嘗試和探索的方向。目前，作業幫已經和阿里云有一個關于 AEP 的 tair 方案的結合，在新的一年希望我們有更大規模的落地。文章里講得比較多的是關于降本做的一些技術改進，其實在降本增效這里面還有很大一塊工作量是運營，成本運營我們也通過自動化實現了平臺化，未來我們將會進一步向 BI 化、AI 化去演進。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的作业帮云原生降本增效实践之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。