擁抱雲原生，作業幫多雲架構實踐之路

作為一家深耕教育一線多年的科技公司，作業幫具有規模化和複雜化業務特點。為了支撐數千個應用服務，應對不同語言棧、同一語言棧不同業務需求的複雜性，作業幫早就開始探索多雲架構。至於，雲架構如何來做?IaaS、服務治理、PaaS、SaaS每層要如何設計?如何從單雲架構遷移到多雲?本文結合作業幫實際業務發展，具體介紹了多雲架構的實踐經驗。

本期分享嘉賓：

董曉聰 作業幫基礎架構負責人

簡介：

董曉聰，之前主要曾在百度、曠視等公司負責架構和技術管理工作，擅長業務中臺、技術中臺、研發中臺的搭建和迭代。19年底加入作業幫擔任基礎架構負責人，負責作業幫架構研發、運維、DBA、安全等工作。20年初主導了作業幫雲原生建設，開始進行底層技術的重塑，當前已完成96%以上業務的容器化改造，建成了一套完備的微服務治理、DevSecOps、多雲多活架構體系，帶來了一系列穩定性、成本、效率、安全上的收益。成為阿里云云原生方向的MVP，騰訊云云原生方向的TVP。作業幫在FinOps領域也取得一定成績，成為中國產業網際網路發展聯盟主辦的FinOps產品標準工作組中副組長單位。

作業幫教育科技(北京)有限公司成立於2015年，一直致力於用科技手段助力教育普惠，運用人工智慧、大資料等前沿技術，為學生、老師、家長提供更高效的學習、教育解決方案，智慧硬體產品等。

技術現狀

作業幫的技術現狀可以歸納為兩點，即規模化和複雜化。“規模化”。是指作業幫有數千個應用服務，然後對應數萬個服務例項，這麼多的業務例項跑在數十萬的計算核心之上; “複雜化”，是指作業幫的技術棧比較多元，基本上主流的技術棧都有，其中佔比最高的像PHP、Golang能佔到公司的60%;除此之外還有大量模組是用Node.js、 Java、Python、C++等進行編寫的。

大體來看，作業幫主要的技術棧是PHP。PHP主要的技術體系是基於odp，更準確地說是odp2.0，是百度2010年內部自研的一款以框架為核心的虛機架構的整體的解決方案，它能夠快速實現新業務孵化。即便大家都同樣使用odp這樣的框架，也會因為不同業務特點、團隊能力等因素出現技術棧上的差異。比如：工具側的產品更側重於客戶端，所以在服務端上的一些技術其實是偏向於保守;但像產業網際網路這類業務，其實是領域驅動，會大量使用微服務架構，當時由於沒有統一標準，各自團隊也在自研一些服務治理體系的基礎設施。

混合部署其實也是odp的一大特色，將不同的模組部署在同一組機器、同一組服務單元上，這對成本是有幫助的，它能夠有效提升資源的一個利用率。但是，也帶來一系列的穩定性和效率的問題。究其本質，其實還是程式碼、模組、應用服務、機器之間其實沒有一個明確的一個對應關係導致。

單雲架構瓶頸

作業幫從創立之初，基礎業務就是語音服務，充分享受到雲端計算帶來的紅利。但在傳統單雲架構下，作業幫遇到了一些問題和挑戰：

首先，故障恢復。在單雲架構出現故障的時候，尤其是大規模故障，涉及到了一些整體的網路故障，業務團隊什麼也做不了，就只能等著運維團隊進行業務恢復。同時，運維團隊也做不了什麼，只能去等著雲廠商恢復。至於，具體什麼時間恢復，很難得到一個明確答覆，有一種束手無策的感覺。其實，雲廠商也沒有我們想象的那麼穩定。就公開資料來看，國內外的公有云廠商均出現過故障或者當機的問題。而線上教育其實對穩定性要求很高，如果不能提供一體化的教育平臺，很難保證服務體驗。

其次，雲成本最佳化。隨著網際網路紅利的消退，降本增效成為各個公司的時代主題。雲服務成本是公司除了營銷之外最靠前的幾項之一，是重點要解決的問題。因為選擇的是單雲，基本被雲廠商繫結。很多公司的雲成本最佳化已經不是CTO在處理，而是CFO掛帥。

其三，服務質量。早期，業務剛上雲的時候沒問題，但隨著時間推移，服務的質量是否還能夠一如既往，各種需求是否能夠及時響應，很多時候要打一個問號。這也能夠理解，畢竟人力資源有限，根源還是單一供應商服務的問題。

單雲架構解決路徑

那麼，從行業角度看，關於單雲架構會有哪些解決路徑呢?

針對單一供應商不可控的問題，其實有兩條比較明顯的一個思路：

一個思路是：下雲，迴歸IDC。時至今日，擁抱雲已經是一個不可爭議的主旋律，當然IDC也依然會存在。但像一些大體量公司，比如計算資產有幾百萬核的企業，選擇IDC會更划算，有些公司還會提供公有云的一些服務，但是對於一些相對一般體量的公司，他們選擇IDC可能會有幾點考慮。

可能公司在雲廠商獲得的折扣一般，或者是中間有一些捆綁的一些商業因素等等。再或者，有些公司還會出於對自身的一些資料、模型有保護需求，所以去選擇了IDC。對很多公司而言，基礎設施的掌控能力確實提升了，但是要操心的事情也會更多，機房的風、火、水、電，再比如製冷、消防、防潮、備用電力等所有的問題都需要進行關心。

另外一個思路，是多雲架構。也是本文關注的重點，即採用多個供應商解決不可控的問題。 多雲的定義是，一個公司使用了兩個及以上的雲IaaS的供應商。泛化來講啊，廣義的來看，混合雲其實也屬於多雲架構。

那麼，多雲會有一些什麼優勢呢?

1.災難恢復，當出現單雲故障的時候，資料儲存不至於不可挽回，可以從其他地方進行恢復。

2.故障轉移，指的是當雲出現故障的時候，透過故障轉移，可以使用另外一家雲來承接這個服務，從而做到業務不中斷。

3.成本最佳化，不管是什麼採購，只要有兩家及以上供應商，採購方就會有一個充分選擇和議價能力，也就避免被供應商鎖定。

4.資料主權，是指國家或者相關機構對數對服務產生的資料有一定的產權需求，導致企業雲基礎設施也會受到影響。

5.特定服務訪問，是指不同雲都會有自己的特色服務，一般會出現在PaaS層。比如：各家都有各種各樣的資料庫、大資料實施方案，但都在某些領域裡極具優勢，使用多雲後就可以集各家之長。

架構模式分析

那麼，多雲到底是有哪些架構模式呢?是不是就只有一種固定不變的架構模式?答案是否定的，多雲有多種架構模式!

1.主備多雲。企業的應用服務在一家雲上，使用者透過DNS資料沿著閘道器應用、資料儲存這條鏈路進行流轉。忽然有一天，企業出於對資料災備的一個考慮，將資料儲存同步到另外一邊雲，或者說企業有一些海量的物件資料歸檔的一些需求，會進行資料備份，選擇另外一家在雲端儲存價格上有一定優勢的企業。同時，企業還有可能會在這個備份的雲上開一些衍生的離線計算，用來進行一些加工處理，比如支援對圖片、檔案、影片等轉碼之類的服務。

基於多雲架構上述的六個優點，我們看下主備多雲有哪些優勢。首先看災難恢復，因為把資料備份到另外一個雲上了，所以災難恢復在資料層面肯定是滿分，任何故障都不會對資料造成一個毀滅性影響。但是，對於故障轉移卻無能為力，因為只把資料存過去了，應用服務其實沒有什麼變化，所以這塊肯定是零分。

2.彈性多雲。基於上述考慮，企業開始考慮一些特色服務。比如：深度歸檔，或者基於深度歸檔衍生的一些基於物件儲存的一些更豐富的圖片處理能力，或者更多彈性計算的能力。這樣，企業在原來備份雲上的使用會更多，不再僅僅滿足備份需求，開始把一些重要服務部署過去，應對流量突增的一些彈性需求。在這種架構下，為了保證需要臨時去擴的時候，服務完備，是需要長期做多活。所以在日常的時候，就會有一部分的流量，是在這邊這個雲進行流轉。中間也是透過DNS去進行一個流量的分發。當出現真的一些突增的一些流量、一些非預期的一些流量的時候，彈性的雲我就可以做一個計算資源的一個快速的擴容。然後透過DNS或者是閘道器，將主雲無法承載的流量轉移到彈性雲上。

我們看下在彈性多雲這種架構下，各方面表現如何?

基於主備多雲，資料完成了多雲端儲存，災難恢復肯定是滿分。因為，企業已經把一些核心的服務部署在了第二家雲上，故障轉移能力更強了。但因為只把一些新服務部署過來，應對一些彈性流量，一旦主雲掛掉，這個彈性雲能不能工作，沒有準確答案。因為在彈性雲上，還是有些服務會依賴主雲，這會導致企業邁向下一步。

3.業務切分多雲。其實這個也很好理解，並且現在應該是各家多雲裡面相對比較主流的一種方式。很多公司都有多個部門，或者因為是個集團型公司，有多個子公司。各部門都有自己相對比較中立的一個雲廠商，就形成了一個局面，就是我的一部分業務在一家雲上，另一部分業務在其他的雲上，使用者訪問不同的業務，需要透過不同的域名、DNS，兩家雲結合起來才能支撐公司業務。這種情況下，和之前相反，災難恢復、故障轉移，基本是零分，因為資料、服務其實沒有一個備份，沒有冗餘。如果真的出現問題，就會出現嚴重的遷移成本。

4. 資料主權多雲。不同使用者群體透過DNS、路由到不同的雲上，其實已經不一樣了，每個雲上都是一個完整的應用，但是這些資料只是各自這些使用者的資料，它其實也是組合起來之後才能是完整的資料。主要使用場景有幾種，比如業務出海，不同國家限定了資料，不允許出境，主權只能在這個國家內，基於這個原因會去簽訂一些相關的雲廠商，進而導致出現這麼一個資料主權多雲。另外，某些像國內的一些私有化交付專案，僱主其實對資料部署在在公有云，或者哪個私有云，是有一定要求的。對於服務的企業而言，其實是想用一份程式碼去服務多家企業，所以也有可能會出現這樣一個資料多雲的一個場景。

5.多活多雲。企業將服務等量部署在兩家雲上，同一份使用者它是透過DNS進行分流，分流到不同的雲上，完成一個完整的鏈路，資料儲存這裡列的是相對比較經典的一個儲存模式。當然，隨著分散式資料庫的完善，也有一些分散式的選型，我們這裡先簡單講講主從模式。在這種架構下，其實因為我的所有應用、所有的資料儲存在每一家雲上都是有對等的一份兒，所以我的災難恢復、故障轉移特別容易。當出現機房故障的時候，我只去進行一個DNS切換，就又可以正常提供服務了。不同雲上都是有完整的服務，只是大家各自的一個佔比的流量不同，並且成本比較低，也不太可能會被繫結。

看上去，多活多雲是一個特別理想的模式，但在多數應用服務場景下很難實現，而且代價巨大，會引發新的問題。如果我們做不到業務在各自雲之間是完整的一個閉環，彼此之間如果還會存在一些跨雲、千絲萬縷的一些呼叫依賴的話，故障率很有可能沒有減少，而是被增加了。如果兩邊雲的穩定性做得不好，對於業務而言肯定要做冗餘最差情況下，在兩邊各部署能夠承擔百分之百容量的一個服務。這樣，成本肯定會增加，因為兩邊加起來是百分之二百，比之前百分之一百多很多，是巨大的一個浪費，跟最初目標相悖。最重要的是，運維效率大幅降低，會反作用於穩定性。

所以，在不完備的、多活的方案下，對多雲沒有等量地做部署，所以不得不需要一次又一次地去演練，透過人肉的方式去保證多雲架構的有效性。中間一旦鬆懈，很有可能就導致耗費巨大精力做的這套架構，在單元故障之前完全沒有任何的作用。

作業幫多雲建設

作業幫堅定地選擇多雲多活策略，只有這樣，才能達到理想的穩定性、成本收益等。我們生活在雲原生時代，K8S相當於把雲廠商的北向介面統一了，極大地抹平了多種技術之間的差異，讓多雲交付相對統一。而云內部是一個完整的閉環，常態的應用呼叫發生在雲內，雲間只需要做資料的同步，或者主叢集的寫流量。當然，會有一些跨雲的需求，比如新擴建服務的時候不能一下把所有服務切過去，各業務沒有辦法做到完整的一致，一定會有先部署的模組，在多雲側也要有一定的叢集間發現的能力，儘量把問題域從叢集服務降低到叢集這個單一的維度，再就是南北向的排程優先使用DNS來進行。

此種背景下，作業幫是如何基於多雲架構進行資源調配、服務治理的呢?

從大的架構來看，分為兩層：一個是資源層，包含計算、儲存、網路等諸多IaaS資源。計算包含CPU、異構計算，儲存會有塊儲存、檔案儲存、物件儲存等等。另一個是應用層，會有各種各樣的PaaS應用元件，包括資料儲存、安全、訊息佇列、大資料等等。再往上是各種業務中臺、業務線，以Docker+K8S為代表的容器技術，透過容器映象、作業編排、資源排程、資源管理實現了資源對上層業務的透明。上層業務想要跑得更快，需要一套服務治理體系，以服務發現為基礎，包含觀察、通訊協議、流量管控等方面，這是架構全貌。

具體而言，底層架構，首要能力是網路。這是一切上層互通的一個基礎，在基本的一個連通性上，需要各家雲廠商之間可以進行互通。我們的工區，不管是北京，還是外地，可以去訪問雲上的一個內網。服務連通性，其實是最基礎的一個要求，更高層面的要求是需要網路更加高可用。另外，在所有的網路邊界上，會有更強的感知能力和管控能力。至於高可用，其實也並不只針對是雲上，也針對工區，作為幫對工區的一個穩定性要求會比較高。

在傳統網際網路公司，其實工區如果網路出故障，會影響研發，晚提交一會程式碼，不會對下游業務造成影響，其實這些還是一個相對比較間接的影響。但是作業幫，有幾萬輔導老師，在學校上課的時候，需要同步做著一些輔導、答疑的一些事情，內網的不穩定會直接影響學習質量，應用的穩定性一定要重點保障。

作業幫整體的網路發展歷程梳理如下：

1、以工區為中心的雙雲互通

2019年，公司還沒有一個正式的網路運維人員，主要方案就是滿足連通性，工區需要上雲，會從工區直接去連到那個雲的IDC，然後工區之間再聯通起來，多雲也就自然也聯通起來了。解決完北京工區和雲的互通問題後，對於外地工區，是透過打一個VPN通道，走公網，然後連到了北京的工區，自然也就可以上雲了，這套方案讓聯通性基本得到了滿足。

但是，這套方案問題也比較多。首先，在高階別的可靠性、感知能力上有一些問題。兩家雲之間是透過工區來進行橋接的。我雲上本來是一個IDC級別的可靠性要求，一下子降低到一個樓宇物業的級別，中間但凡臨時停個電，服務就可能會出現故障。同時，外地工區上雲本質上走的還是一個公網的鏈路，只不過在上面加上了一個VPN的安全防護，而且防護質量其實並不高。

2、IDC級別的雙雲互通

如何提升網路的穩定性級別?經過綜合對比，包括重點考察了裸纖組網服務，實現端到端鋪設組網線路。涉及到傳輸層面，除了最後一公里去接線之外，其實大量的還是去用專線廠商已有的一個都會網路。最後，以接觸點的方式幫企業組成了一張內網。當時，其實只有兩家的雲廠商，所以最終選擇的是裸纖的一個方案。我們分析了一下兩家雲廠商的一個pop點的一個分佈，他們其實在亦莊、順義都有相關的一個pop點，並且離得還比較近，所以我們選擇用裸纖的方案將這家雲的順義pop點跟另外一家雲的順義的pop點連起來。在亦莊這邊也是同樣的，這樣就實現了一個IDC級別的一個互通。除此之外，我們也對外地工區上雲做了一定的最佳化。

最理想的方案，還是想像北京這邊一樣，去找一箇中立的第三方，然後複用它的一個全國的骨幹網路來進行上雲。但對於專線廠商而言呢，他們全國骨幹網的覆蓋更多是去覆蓋一個比較大的城市，比如華北、華中、華南以及華東的某些點，因為他們畢竟還是做IDC級別的一個互通，沒法覆蓋到我們的一個外地工區，真正能做到這麼密集去覆蓋的其實就只有雲廠商。因為雲廠商本身的業務主體是一個比較大的網際網路業務，所以說他們也有這樣一個需求，需要更好的一個覆蓋，能覆蓋到全國主要的一些省會城市。最後，我們選擇的方案是，藉助雲廠商的一個骨幹網路，進行一個外地工區上雲的聯通，訪問我們的內網服務。同時，就原有的那個Ipsec-VPN通道，還是進行了一個保留，作為一個備用的一個鏈路。

3、多雲組網

之後，我們新的問題就隨之而來，原來之前是兩雲，就現在我們需要去接入新的第三家雲，就是因為各種合作的一些原因，我們的網路需要進行怎樣的調整呢?另外，在之前方案下，感知和管控能力其實並沒有提升，相反還是有一些降低了。在最早的那版方案裡，雖然走的是工區的網路，但是工區畢竟有可控的交換機，可以做管控、感知，但是現在完全採用裸纖的方案，是兩家雲廠商直接點到點的一個連線，我們的感知管控能力其實是喪失了，因為中間並沒有我們的一個裝置。

基於上述這些問題，作業幫對網路進行了第三代演化，實現多雲之間的最佳化。新加一個雲廠商，作業幫原有的網路拓撲其實並不適用了。之前講到專項供應商，提供了三種方案。作業幫分析了一下多雲組網的方案，其實更適合這種需要接入兩家以上的一個點。在新的方案下面，也是有各種各樣的高可靠要求，比如從供應商的一個連線上，供應商自身的一些都會網路會有一些冗餘，有故障的抗干擾，以及一些彈效能力。除此外，也做了一些雙聯路，不僅使用了兩家不同的供應商，每家供應商去接入的地域其實也不一樣，還是一邊是從亦莊，一邊是在順義方向進行接入，整個鏈路之間實現了鏈路的負載均衡，當單條鏈路出現故障的時候，從協議層面可以實現一個秒級的自動切換，並不需要人工的一個干預。在這樣的網路架構下，供應商跟雲廠商的網路裝置是缺乏管控狀態，作業幫在專業供應商這邊去租了相關裝置實現了感知跟管控能力，在後面像雲的一些故障演練、跨雲的流量分析上，起了一些相對比較重要的一些作用。

其次，是計算。計算是橫在多雲架構上 “一塊難啃的骨頭”。在單雲的時候，其實如果我們沒有統一個機型規劃的話，看到雲上有什麼樣的機器，我就開什麼樣的機器。雲上的機型特別多，2c、4c、8c、16c、32c、48c、96c都有。然後，那個記憶體比有1:2、1:4、1:6、1:8，兩項一組合，就會形成一個大的機型列表，可能會有幾十甚至上百種。這個時候，一旦去做多雲，再乘上多雲的一個數量，就是對運維而言絕對是一個巨大的災難。這麼多的機型如何我去做一一的適配以及更好的維護?

面對這個問題，最終解法是要去定義一個機型的一個規範，從這些發展的機型裡面去進行梳理，定義各家雲主流的一些規格。首先，讓所有的業務儘量往一個規格上靠攏，各業務大規格上雲把裸金屬作為一個主力的機型，比如像在容器裡面，讓容器的宿主都使用這種大規格的裸金屬。一方面既可以減少叢集中管理的節點數量，另一方面也是縮減機型的一個訴求。

早期的資料儲存，會優先讓其使用這種裸金屬，然後在其上進行一個混部，像MySQL跟Redis也都是這麼做的。除此之外，有些真是主力機型滿足不了，比如像各種各樣對網路吞吐要求比較高的就是流媒體的機型，某些特定的採買的一些服務的機器，這種做不了。

除了這些特定的服務以及我們收斂的主機機型之外，虛機肯定還是會存在，但是不能像之前一樣任其發散。作業幫選擇兩款作為選擇，選項就是8核16G、32核64G，規格相對適中，跨度也並不是特別大，能涵蓋百分之九十五以上的虛機需求。如果再有一些其他需求的話，我們其實建議其遷到容器。

再到下一個階段，隨著部分服務的一些資源使用量越來越多，比如超過了10000核，就是像資料庫或者Redis結合降本增效的一個背景，其實最終發現，要努力的方向要麼是軟體，要麼是硬體。在硬體上其實更多的就是在機型上去下功夫。比如像DB的機器，其實使用不了那麼多的一個CPU，我需要更多的記憶體、更多的磁碟，我們就去使用各種大量的一些專用的大磁碟的一些機器。而在Redis場景，選用了傲騰來實現降本。

計算生命週期管理

接下來的問題是，計算生命週期管理如何來做?如何透過自動化、平臺化去提升多雲效率?

首先，有了機型之後，也不是直接去購買機器，中間還缺少一環網路。因為，所有的資源其實都被劃分到一個個網路的安全域裡面，比如有測試域、生產域、管理域、三方服務域等等，每個域裡面又會有直網的網段劃分。如果我們將這個概念一股腦地拋給研發，其實代價比較高，也不太利於後續的升級迭代。

我們把機型結合網路劃分，再變成一個個套餐，這樣業務和研發就可以直接基於套餐來進行機器的購買。交付到業務之後，業務再做一些初始化，機器在執行的過程中對上層的應用提供一個穩定性支撐，當機器故障或者需要縮容的時候，就走銷燬流程。在這個生命週期裡面，財務是重要一環。財務人員會有兩個賬單，一個是按照雲廠商的各種計費規則，包年包月、按量計費等算出的一個賬單流水，用於跟雲廠商對賬，然後進行一個對公的付款;另外一個賬單，是研發部門的一個用量檢視。

服務治理：註冊發現、通訊、感知、管控

多雲中，下游對上游提供的服務的名字要一致，這樣整個部署拓普就對業務進行透明瞭，便於運維去調整部署。這塊有一個新的挑戰，就是多雲跟容器是同步化來做，如何合攏呢?需要一個註冊發現能力!基於這塊的一個進階的要求，就是虛機和容器如何去解決互相發現通訊的一個問題。更理想一點，服務對外能不能提供一致的名字，有統一的控制面?

作業幫透過雲原生的方式服務治理，兩個服務訪問直接透過Service域名實現單雲、多雲的互通。當然，容器化進展也不是一蹴而就，比如：沒法在一個時間點同時從虛機變到容器;現在的做法是，透過資料打通來完成整個控制面的打通。

除了上述這些基礎能力，多雲架構改造還涉及PaaS層的資料儲存、流量排程等問題，包括SaaS層的改造，這裡不逐一介紹。

從最終結果來看，隨著多雲架構的不斷迭代，收益也是持續上升狀態。核心模組完成多雲部署後，公司實現了60%的收益;核心模組+一般模組完成多雲部署，多雲收益是90%;核心模組+一般模組完成容器化改造，容器收益近乎100%;全部完成多雲部署，多雲收益100%。大體步驟是，先容器化再多雲，先進行基礎建設遷移，再完成邊緣模組、一般模組的遷移，最後是核心模組遷移。

結論：

走到今天，唯一可以肯定的方向是，未來應用服務一定是100%的雲原生。雖然作業幫現在已經完成90%的改造，比如資料儲存、外呼、檢索都是容器化方式，但距離100%還有一些距離，後續計劃會對流媒體等一些服務進行升級。另外，基於多雲的雲邊協同，也是重要探索方向，可以讓業務服務不受雲、機房等基礎設施能力的限制，比如業務出海會基於雲邊協同達到更好的收益目標。最後是，多雲資料儲存目前還是主從為為主，未來會考慮分散式資料庫單元化設施的進一步完備。