混合雲的多活架構指南

語言: CN / TW / HK

文/董曉聰 呂亞霖

在之前的 《如何正確選擇多雲架構?》 一文中介紹了混合雲(廣義的多雲)的諸多架構以及各自的優勢,本篇會重點來介紹下混合雲下的多活架構。

背景

企業選擇混合雲的技術訴求中,主要因素還是穩定性和成本 &服務,而對這兩點的極致追求就是多活架構。

  • 穩定性

業務探索階段追求效率,技術上一般會選擇單雲單活的架構。隨著業務的逐步發展,單活的架構無法滿足業務穩定性的要求,技術人員開始進行服務多可用區的部署。這個也是行業內比較主流的做法。

隨著雲廠商的技術建設,穩定性越來越高,且同 region 的多可用區方案進一步降低了企業集中式故障的概率。但云廠商仍存在中心式服務,如 region 的網路匯聚、統一的結算系統等。

對於使用者使用時間視窗特別集中的業務,對穩定性的要求更高。比如線上素養課就是在有限時間內老師和學生完成知識傳授,如果在這段時間內雲服務出現故障,學生的學業受到影響,學生和老師需要重新匹配時間才能完成學習計劃。健康碼、打車軟體這些使用集中在早晚高峰的場景也是同理。對於 SLA 要求更高的業務,選擇多雲多活是必然的趨勢。

  • 成本 &服務

企業上雲後能享受到彈性、標準的雲端計算服務。但隨著網際網路紅利不斷消退,公司希望實現成本效益最大化,引入更多的供應商也是必選的手段之一。新的供應商,可以用來做資料災備,或者用於峰值時的彈性計算,也或者按照不同業務進行切分。

但是,更徹底的方案還是不同雲各自進行服務等量部署,做到真正的多活,隨時可以做到流量和容量的排程。

挑戰

多活架構的優勢很明顯,但背後面臨的挑戰也是巨大的。下面從穩定性、成本、效率幾方面來推演下。

  • 穩定性

多活架構是用來解決穩定性問題的,但若不能做到多雲各自完整的閉環,彼此之間還有千絲萬縷的呼叫依賴,故障率反而會增加。

假設企業使用兩家雲廠商,各自出現中心式嚴重故障的概率為 n 和 m,不論是網路還是容器還是計費等系統。假定這個值為 0.05%,則一年因雲供應商導致的故障時間為 262.8 分鐘。多活多雲架構下理論的故障率為 n * m,千萬分之幾的故障率。考慮到多雲之間的切換時效,故障時間可控制在十幾甚至幾分鐘內。

核心業務的呼叫鏈路一般是較複雜的樹形,由根節點模組逐步發散。若其中存在一支呼叫鏈路,Service A 呼叫 Service B 和 Service C。其中 Service A、Service B 均為雙雲部署,Service C 僅部署在雲廠商 1。那麼當雲廠商 1 出現嚴重故障時,核心業務受影響,無法提供服務。當雲廠商 2 故障時,核心業務可以正常執行。這時的故障率為 max(n,m),取決於短板的雲供應商。

再極端一點,Service A 部署了雙雲,Service B 部署在雲廠商 2、Service 1 部署在雲廠商 1。那麼不論哪個雲出現故障,核心業務都受影響。此種部署架構下的故障率為 n + m,提升到 0.1%,被大大提高。

上面描述的場景並不是危言聳聽,而是真正的客觀現實。當模組較少時,如幾十、幾百的時候,通過研發自治加運維的 double check,在付出持續成本的情況尚可能避免這種異構的部署。可是一旦業務規模增加,模組數量達到上千後就不再是人工可以簡單 check 的。各方向的研發和 SRE 負責人已經很難熟悉和管控每個模組的完整呼叫關係及部署情況。

除了部署異構導致的故障率加劇外,腦裂加劇也是一大隱患。多家雲廠商中資料儲存一般採用主從的方式進行同步,master 所在的主雲故障後,需要將另一邊雲的資料儲存提主。但是主雲並不是完整掛掉,運維人員無法從控制檯登陸,無法將 master 降為 slave。但使用者南北流量或者定時任務還在持續請求,主雲仍有可能還在處理寫入流量。這時候從雲的切主,就會導致不可避免的腦裂。腦裂無法簡單的進行修復,需要業務研發 case by case 的進行修復,代價巨大。

  • 成本

多雲本質上是來解決成本問題的,但兩邊雲穩定性做的不好,業務不得不加大冗餘。極端情況下,兩家供應商各自 100%的容量,但常態下只承擔 50%的流量,帶來巨大的成本浪費。

  • 效率

效率包含研發效率和運維效率,效率的降低又會反作用於穩定性。

如果做不到多雲的對等部署,不得不通過持續演練的方式來應對墒增,保證多雲架構的有效性。一旦鬆懈了,很有可能導致花大精力做的架構升級,但在真正的單雲故障面前不起任何作用。另外,在兩次演練之間的視窗內,架構能否很好的應對單雲故障也是存疑的。

每家雲廠商提供的 IaaS、PaaS 能力看上去差異不大:計算無外乎是物理機、裸金屬、虛擬機器、serverless,網路無外乎是 EIP、LB、NAT、VPC 等實體。PaaS 是各種持久化、記憶體型儲存儲存、大資料離線、實時計算產品,但深入到產品特性後就會發現差異很大,管控面凹凸不齊。

多雲管控面要作為膠水層,對上游抹平這些差異。這個對齊不僅僅是 API 的統一,也會有邏輯的封裝。比如,一家雲廠商的某項資源管控比較寬鬆,僅用一個 API 即可實現功能,但另一家因為產品策略的收緊,需要結合多個產品才能實現類似功能。運維平臺就需要將這些包成事務,對外提供統一的能力。

管控面通過付出一定成本還是可以收斂的,但對於各家的優勢功能,主要集中 PaaS 往往無法抹平。如特殊的資料儲存方案、大資料實時方案,這時候就要去找尋其他的替代方案。

設計目標

講了這麼多,該如何設計多雲多活的方案。作業幫線上業務堅定地選擇多活多雲的策略,只有這樣才能帶來理想的穩定性和成本收益。

生活在雲原生的時代,我們是幸運的。K8S 統一的北向介面,極大地抹平了多雲部署的差異,讓應用的交付和執行變的統一。

在架構拓撲方面,多雲間的網路是介於單雲多可用區和中心-邊緣之間的一種狀態,內網有一定可靠性,但並不能完全依賴。

基於此,應用應儘可能地減少多雲間的網路通訊。除了資料儲存的同步和寫主外,常態的應用間呼叫應該閉環在單雲內部。所以並不需要做一套納管各雲應用的服務註冊發現機制,僅需要單雲內部獨立註冊發現即可。

當然不可否認,在某些場景下跨雲呼叫還是有需求的。比如新擴一家雲時,各業務節奏沒法做到完整的步調一致,一定會有模組先部署,而它沒有同步部署的依賴模組就需要路由回原叢集。但這個也只需要叢集間發現即可,不需要叢集乘以服務把問題的複雜度提高。多雲部署了全量服務,南北向流量就可以優先通過 DNS 進行排程。

架構概述

企業技術架構從大的層次來說,會分成兩層:底下的一層是資源層,包括計算、儲存、網路等 IaaS 資源;應用這個層面,有底下各種各樣的 PaaS 元件,包括資料儲存、訊息佇列、安全、大資料的等等,然後再往上一層是各種各樣的業務中臺,再往上的話就是具體的業務線。

以 docker 和 k8s 為代表的容器技術,通過容器映象、作業編排、作業排程、資源管理實現了對上層應用的資源透明。上層應用想要跑得更快的話,其實還是需要一套服務治理的體系。整體的服務治理體系以註冊發現為基石,包含觀察、通訊協議、流量管控等方面,這就是作業幫雲原生架構的全貌。

下面介紹下作業幫各層多活建設的概要,後面每一個方向還會有單獨的文章再進行詳細介紹。

網路

作業幫在實踐中逐步摸索出一套“多雲組網+CPE 管控”的方案,實現在雙雲間甚至多雲拓撲下的網路互通,以及諸多其他特性,如彈性-頻寬快速擴縮、可觀測性-跨雲異常流量的分析、韌性-單節點單線路故障自動切換、可持續-新增雲供應商的快速接入等。

計算

單雲架構下,SYS 團隊運維繁多的機型已然負擔較重了,多雲架構帶來的機型組合爆炸是一場運維災難。只有根據應用場景制定機型規格,收斂到可控的主力機型,才能帶來生產力的解放。這個還只是第一步,後面還需要通過場景套餐的方式來更標準的管理計算生命週期。

容器技術

容器技術是抹平 IaaS 資源差異的核心,但這還遠遠不夠。雲原生帶來的諸多優勢,如在離線混部、Serverless 等,作業幫希望在每一個主力雲廠商上都享受到。這就要求企業自身有一套標準,有一套容器中介軟體的可控能力。

服務註冊發現

服務部署應該對業務透明,這樣混合雲的排程才可能儘量減少對業務的擾動。作業幫除了混合雲建設外,還在同步做容器化改造,且做了服務註冊發現機制的替換。在這種難上加難的場景下,基礎架構團隊設計並落地了一套平穩過渡的方案。

除了同步 RPC 呼叫外,非同步呼叫也面臨同樣的問題。

服務觀察

不論是日誌、監控,還是鏈路追蹤,技術人員都需要一套統一視角,減少混合雲架構的影響。

流量排程

這裡的排程主要指的南北向,使用者流量的排程。排程的單位一般是域名。

多雲間流量如何精準分配,將誤差控制在 1%只內?單雲故障後切流後如何讓使用者在 5 分鐘內完成恢復?只靠 DNS 是遠遠不夠。作業幫基於 CoreDNS 自研了一套 DoH 的解決方案。除了解決使用者網路被劫持外,也成為多雲流量排程的一大利器。

資料儲存

多雲場景下,資料儲存主要面臨的還是經典的 CAP 問題,在出現資料分割槽的情況下,A 可用性和 C 一致性無法兼得,要麼 AP,要麼 CP。作業幫這塊根據具體業務場景選擇對應方案,除了主從架構外,也在實踐單元化、MGR 等的方案。

應用

多雲架構在應用層面臨兩個需求。一是常態情況下應用間禁止跨雲訪問,這樣才能有效防止墒增,不出現增量的跨雲呼叫。另一個則是特殊情況下,如機房遷移、單雲服務異常等,需要能夠靈活排程多雲間流量。

這兩個需求是矛盾的,但又都是客觀存在的。作業幫在這塊使用“隔離區+互通區”的設計巧妙的解決了這個難題。

應用層的問題不只這一個,線上應用和大資料實時服務的耦合也十分棘手。

隨著業務運營的精細化,對大資料實時查詢的需求越來越多。線上服務會直接呼叫大資料實時引擎處理結果,但大資料實時服務還不像 MySQL、Redis、ES 等具有完備的多雲能力,甚至很多就是單家雲供應商提供的 PaaS 元件。這種情況下借鑑上述思路,實現單雲服務和多雲服務間的隔離。

編後語

一路走來,筆者對作業幫混合雲多活架構的建設感受良多,其不單單是容器多叢集的管理和流量排程,更是一整套貫穿資源和應用的企業架構整體解決方案。

混合雲多活架構,需要 SYS、容器研發、中介軟體研發、SRE、DBA、DevOps、FinOps、安全等基礎架構諸多方向精誠合作,需要所有業務研發部門鼎力支援,需要一個強有力的技術組織體系才能完成。

上述為作業幫混合雲多活架構的綜述,後續文章會逐漸為大家介紹多活架構中 IaaS、PaaS、SaaS 的技術細節以及遷移新雲的 SOP,請大家持續關注。

作者介紹:

董曉聰,作業幫基礎架構負責人、阿里云云原生方向 MVP、騰訊云云原生方向 TVP,主要負責作業幫架構研發、運維、DBA、安全等工作。曾在百度、滴滴等公司負責架構和技術管理工作,擅長業務中臺、技術中臺、研發中臺的搭建和迭代。

呂亞霖,作業幫基礎架構 - 架構研發團隊負責人。負責技術中臺和基礎架構工作。在作業幫期間主導了雲原生架構演進、推動實施容器化改造、服務治理、GO 微服務框架、DevOps 的落地實踐。