鮮花與荊棘同在。云原生在外界看來，是高端大氣上檔次的時髦熱詞。彈性、可觀測、韌性、可持續等一系列優美的詞匯都會出現在它的上下文。但回歸到落地層面，卻并非一朝一夕之功。

云原生改造是事關企業長遠發展的一項重要舉措。作業幫的基礎技術架構經歷了成功的轉型，轉型過程中面臨的挑戰也是困難重重，有哪些轉型經驗值得借鑒？

我們請到了作業幫基礎架構負責人董曉聰，分享作業幫在多云之路上的思考與探索。希望本文能給即將或正在數字化轉型的開發者、管理者以幫助。

Q：是什么原因讓作業幫選擇了云原生？

A：本人在 2019 年加入作業幫，發現當時基礎技術架構的有兩個特點：

一、規模化：作業幫線上有數千個應用服務，這么多應用服務對應數萬個服務實例，這么多的服務實例跑在數十萬的計算核心之上；二、復雜化：作業幫整體的技術棧是比較多元的。其中占比最高的技術棧是 Golang 和 PHP，還有大量模塊是 C++、Python、Java 等進行編寫的。

此外，不同的業務特點和團隊特點差異很大，比如流量產品，技術棧偏向于保守，而產業互聯網的業務架構則由領域驅動，微服務架構比較徹底。

作業幫在穩定性、效率、成本等方面也面臨著諸多挑戰。

穩定性方面。之前在傳統的互聯網公司，大家很少接觸到用戶，對用戶的感知更多的是一個個 UV、PV 數字，但在線教育不一樣，我們通過直播等形式面對的是一個個學生，每一次穩定性的事故都可能會影響他們的學業，造成不可挽回的損失。所以作業幫對穩定性的要求只能更高。首先，考慮當出現單機、單機群、單云故障的時候，我們的架構能否很好的應對這些沖擊？當代碼變更導致業務中斷的時候，我們能不能快速止損？

再比如效率問題。由于線下、線上的交付物不同（如：線下是容器，線上卻是虛擬機），兩側的環境也是異構的，這就導致研發、運維、測試的周期和成本會成倍的增加。

一旦出現網絡的抖動、服務的故障，總需要各方不斷協調，等著研發等運維，運維等云廠商來恢復，給用戶造成非常不好的體驗。

另一個很大一部分也是出于 IT 支出的考慮，是結合業務考慮，與多家廠商談判得到的結果。

綜上，基于穩定性和成本、效率等問題的考慮，作業幫選擇了云原生以及多云。

改造后的整體收益，還是比較明顯的。首先是穩定性，整體機器故障的影響也從分鐘級別縮短到了秒級，交付部署的質量得到了大幅度提升。成本這塊也有明顯的收益。

Q：作業幫在云原生改造的過程中積累了不少專利，能簡要介紹下嗎？

A：近些年作業幫，在云原生方面積累了一些成果，非常樂于與業界展開分享交流。下面列舉一些。

比如在資源層，作業幫打通了各家云的網絡，在連通性、高可靠、感控能力等方面處理和制定了一套計算生命周期的平臺；在容器層面，開發了一套多云分發的平臺；在服務治理層，自研了一套分布式的日志查詢引擎方案，這套方案的成本僅為 ES 的 1/10，同時整體的查詢效率也比較高查詢 1TB 日志的話，耗時是在 5 秒以內，大幅度提高了研發的效率 ；流量管控方面，作業幫的方案已經將 P90 的損耗將至了 0.8ms，而開源方案一般在 3 ms；應用層面，作業幫也自建了可自由切換的多云體系，其中比較經典的是將外呼系統建成了一套多活的架構。

Q: 如何看待云原生的發展

A：云原生提供了以下三種關鍵能力：容器化、服務網格、多活，三種能力的最終的目的，是把之前云被禁錮的能力釋放出來。展開來講，首先，容器是一個基座的能力，只有容器實現了 100%，上層的能力才能釋放出來。

其次，服務網格。目前看，業內已經存在主流的方案 Istio，也有 BAT 自研方案，對于中長尾企業來內的接受度也不錯，但也存在部分機制、性能上的問題。Mesh 方面，目前業界沒有達成一套統一的標準。隨著容器 K8S 標準的形成，關于 Mesh 的標準也需要業內人士的碰撞、交流與探索。

個人比較看好的是，微軟之前提出的 Dapr 的 Multi-Runtime 思路。它把更多運行時卸載到 Sidecar ，本質上是將中間件和業務代碼進一步解耦。

第三，上層的多云多活，之前阿里云原生實戰峰會上公開了應用多活的白皮書?？梢钥闯觯髽I對于云原生的性能要求越來越高，云原生的規范和標準正在清晰化和明確化。

Q：能介紹下關于 GPU 容器化、多云遷移方面的情況嗎？

A：關于 GPU 調度的優化，起源于作業幫使用 AI 推理、圖像識別占用的資源比較多。GPU 是一個相對比較貴的資源，通過調研一些方案并和云廠商進行溝通，了解到目前主要推薦的方案是 GPU 容器化，但是這會至少帶來 15% 的性能損耗，這個是沒法接受的。但我們發現大多數的 GPU 服務使用的各種資源相對比較固定。于是作業幫基于算力和顯存去進行了一些策略的調度，根據這些服務與資源進行匹配的方式，也就是比較經典的背包問題，同時夜間也會進行一下預測再重新調度，如果中間出現一些故障，也會執行轉移相關的策略。GPU 服務目前已經實現 100% 容器化。

多云遷移，當時對于作業幫來說比較難。因為同時還在做容器化改造，疊加實施的難度很大。我們的做法是將服務注冊統一起來，本質上打通容器與虛擬機的鴻溝。多云之間的遷移是分步驟的，將需要遷移的業務在服務發現的過程中解耦掉，就可以分批進行了。

Q：作業幫的云原生的轉型，會對技術管理上帶來哪些變化呢？

A：比較明顯的是，會對運維的方式產生一定的影響。對于運維的崗位而言，中等規模的公司是很難接受的。人肉的工作少了，基礎架構的能力更得到重視，不再局限于一些重復的、機械式的工作。

技術的變革，就好比馬車與火車的變革。如果能及時遷移到新的技術上來，相信能夠帶來新的成長。

對于技術管理者而言，這里呼吁大家積極加入這場變革中來，這里是一片廣闊的海洋。云原生本身代表著開放，不是開源與廠商之間的爭奪。希望大家都能參與進來，一起把這個領域做的更加完善。今天大家把云原生向前推動一步，明天就能從云原生的升級中得到巨大的回饋。

同時，企業在進行云原生改造過程中，不應盲目追求主流的技術方案，一定要從實際的業務情況出發來做選擇，這樣才能獲得實用的收益。團隊管理上，應積極引導團隊在云原生改造的過程中，保持擁抱變化的積極心態。另外還會出現設施不完備等一系列客觀問題，都需要給與一定時間的寬容度。

Q：開源方面，作業幫有哪些進展？

A：作業幫在開源社區一直是有有回饋的，像之前有開源日志方面的方案，至于下一步，整體項目的開源，我們希望把項目做的完善一點，更有普適性之后再進行開源。期待開源后與業內朋友一起溝通交流。

寫在最后

容器化、服務網格、多活架構，可以說是云原生發展到目前為止最為重要的三個特點。這些特點是無數云開發者一起努力得到的結果。

正如董老師所言，云原生是一片廣闊的海洋。只有更多的開發者和企業一道參與進來，才能助力云原生結出累累碩果，改變與我們息息相關的數智化世界。

專家介紹

董曉聰，2019 年加入作業幫，作業幫基礎架構的負責人，負責架構研發、運維、DBA、安全相關的工作，阿里云 MVP、騰訊云 TVP。曾在百度、滴滴等公司負責架構和技術管理工作，擅長業務中臺、技術中臺、研發中臺的搭建和迭代。

作業幫成立于 2015 年，是一家以科技手段助力普惠教育的公司，公司主要的業務分為兩大板塊。第一，作業幫 App 是一款典型的流量互聯網產品，二是作業幫直播課，是一款典型的產業互聯網產品，涵蓋教育主播鏈條，如教研、教學、教務、輔導等。