<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      擁抱云原生,作業幫多云架構實踐之路

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

        本期分享嘉賓:

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

        簡介:

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

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

      ? ? ? ? 技術現狀


        作業幫的技術現狀可以歸納為兩點,即規?;蛷碗s化?!耙幠;?。是指作業幫有數千個應用服務,然后對應數萬個服務實例,這么多的業務實例跑在數十萬的計算核心之上; “復雜化”,是指作業幫的技術棧比較多元,基本上主流的技術棧都有,其中占比最高的像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%還有一些距離,后續計劃會對流媒體等一些服務進行升級。另外,基于多云的云邊協同,也是重要探索方向,可以讓業務服務不受云、機房等基礎設施能力的限制,比如業務出海會基于云邊協同達到更好的收益目標。最后是,多云數據存儲目前還是主從為為主,未來會考慮分布式數據庫單元化設施的進一步完備。

      0
      相關文章
        漂亮的苏酥全文阅读