今年的中國系統架構師大會（SACC）在我所在的城市廣州舉辦，很榮幸受邀參加。這次能接觸到國內最優秀的架構師，學習他們的架構思想和行業經驗。對我而言非常有意義。
大會分為上下午共4場，我參加了上午的多雲多活架構設計專場和下午的AIGC專場。
本篇文章就多雲多活架構設計專場，我選取幾位老師的觀點進行分享。（我並不是架構師，只是對架構感興趣，如有錯誤，還請指正）
張曉輝 Flomesh 高階雲原生架構師
張老師分享了混合多雲架構的技術方案，這裡可以體現一個企業在技術層面發展到什麼樣的程度，根據這張圖可以看看企業架構的複雜程度。可能大部分企業還在容器化，分散式架構和單一叢集的複雜程度。
在資源抽象層面，利用統一的K8s Api，可以實現不同雲廠商的資源抽象，實現資源的複用。K8s多叢集可以作為防腐層，遮蔽基礎設施層差異，避免廠商鎖定
李中原 （平安銀行股份有限公司 國產資料庫技術負責人 ）
銀行系統的技術架構需要滿足高吞吐、低延遲要求，業務可靠性的要求，以及資料安全性的要求，同時，基於監管和法規的要求，技術架構需要自主可控。
李老師分享了銀行架構的“去IOE化”的變遷。
對於可靠性要求，從傳統的不能容許服務中斷，逐漸過渡到允許服務中斷但必須迅速恢復。
黃奕青 （騰訊雲 技術專家）
黃老師對兩位講師做了補充，著重對異地多活架構中的問題，以及解決方案和設計要點等“三階六要點”進行了分享。
- 技術架構的三個階段：
- 第一階段是對業務需求的解讀：一個是傳統的需求分析，一個是企業聘請領域專家對需求建模
- 第二階段是確立架構，目前較為合理的架構是標準的微服務架構，已經被廣泛應用（兩地三中心架構）。
- 第三階段是在微服務架構之上構建單元化，該階段需要解決如下異地多活架構中的挑戰。
- 異地多活架構的挑戰：
- 因為網路基礎設施的物理侷限性，需要考慮異地資源使用時的延遲問題。
- 資料訪問效率問題：跨地域的資料訪問速度慢會導致核心交易延遲，需要考慮資料切分和流量閉環治理。
- 分散式事務成本問題：跨地域的分散式事務會帶來高成本和複雜性。
- 中介軟體的單元化考慮：在異地架構中，需要考慮中介軟體的單元化和排程。
- 六大設計要點：
- 資料切分：設計大型分散式系統時首先要考慮資料如何切分。 資料按什麼維度切分最合適，(如按客戶號，還是雜湊，按range範圍？)
- 流量閉環與單元化架構：黃老師強調了流量閉環的重要性，特別是在單元化架構中。這意味著流量需要在特定的單元內部迴圈，而不是跨單元流動，以減少無效的橫向流量。為了實現這一目標，閘道器需要具有狀態感知能力，能夠識別客戶資訊並將流量路由到正確的單元。此外，單元和上層計算資源之間的邏輯繫結也是關鍵。
- 中介軟體單元化：在單元化架構中，中介軟體（如MQ、Redis等）的鏈路也需要考慮單元化。特別是在跨單元的場景下，如客戶之間的轉賬，會涉及到分散式事務的問題。這種分散式事務的排程和管理在異地多活架構下會被放大，成為實現的難點。
- 資料切分與聚合查詢：資料被切分到多個庫後，聚合查詢變得困難。黃老師提到了從前在一個庫下可以輕鬆進行多表的聚合查詢，但現在需要訪問多個庫進行查詢。這需要對現有的查詢策略和技術進行重新的設計和最佳化。
- 業務連續性保障：單元之間的互備和業務連續性保障是必要的。
- 分散式運維：針對大型核心系統的分散式運維需要特別關注。
戴駿賢 （網易遊戲資深資料庫系統工程師 ）
網易遊戲對於RPO的要求相對苛刻（資料要求無損）。但更多是以成本最小化為考量實現雙活高可用架構。因此目前僅採用同城雙副本。
李運華 網際網路大廠 資深技術專家
企業是否需要上雲取決於成本和技術實力兩個主要因素。
- 成本考量：
- 企業規模：一般來說，如果企業的伺服器規模在一千臺以下，上雲通常是成本效益較高的選擇。對於規模在一千到五千臺之間的企業，上雲可能並不一定省成本，而取決於其在雲平臺上的使用程度。然而，如果伺服器規模超過五千臺，可能會發現下雲（即從雲平臺遷移到自建環境）會更經濟合算，尤其是對於大型企業。這是因為大型企業可能會擁有足夠的資源和資金來自建雲或自建機房，並且會節省大量成本。
- 全面成本考量：除了物理伺服器成本之外，還需要考慮人員成本、維護成本等方面的費用。這些費用在決定是否上雲時也至關重要。
- 技術實力：
- 企業規模與技術實力：大型企業通常擁有更多的人力資源和技術實力，因此更有能力獨立管理和運維自己的伺服器環境。相比之下，中小型企業可能缺乏專業技能和資源，難以應對複雜的技術挑戰，因此更傾向於使用雲服務提供商提供的解決方案。
- 雲產品的功能和強大程度：雲服務提供商提供了豐富的雲產品和服務，包括分散式一致性資料庫等高階功能。然而，自行實現這些功能需要大量的時間、資源和技術實力。對於中小型企業而言，使用雲平臺提供的功能可能更為經濟實惠和可行。（ocean base一個幾百上千人的團隊，從2013年開始，搞了12年）
同城雙活和異地多活有哪些方案？
-
同城雙活方案：
由於同城機房之間的網路延遲可以做到非常低，通常可以在幾毫秒以內，因此同城雙核在邏輯上可以看作是一個統一的機房。可以直接按照叢集的方式運作，成本和複雜度會低。
-
近鄰的異地多活：
這種方案通常是指在相鄰的兩個城市之間進行異地多活部署。例如，廣州與深圳、杭州與上海等相鄰城市之間的部署。由於網路延遲相對較低，大約在十毫秒左右，因此可以接受。近鄰的異地多活方案通常可以透過分散式一致性演算法來實現投票和選舉，確保系統的可用性。 -
遠端的異地多活：
在距離較遠的城市之間進行異地多活部署，如廣州與北京之間的部署。網路延遲可能較高（30ms以上），本質上沒有辦法實現這種叢集的運作。
馬洪喜（深圳行雲創新科技有限公司 CEO）
馬老師分享了三個不同企業的案例：
- 區域性銀行的高可用解決方案：
- 該銀行實施了同城雙活的雲原生高可用解決方案，這是一個強需求，因為銀行業務對高可用性有極高的要求。
- 他們的方案是基於一個排程器實現的，使得業務在發生故障時可以切換到單機群模式。
- 某超大型電器公司的混合雲方案：
- 該公司實施了混合雲，將國內業務部署在私有云上，將海外業務部署在AWS上。
- 這是出於業務需求的考慮，例如海外業務需要在AWS上就近訪問。
- 某鋰電製造企業的工業場景需求：
- 該企業有著複雜的IT/OT融合場景，需要在製造業中實現微服務和AI的應用。
- 他們的需求包括在本地資料中心或廠區內的小型資料中心處理資料，而不是將資料從生產線傳送回總部或雲平臺。
- 製造業趨向於建立一個多級算力體系，包括本地資料中心、雲平臺和邊緣計算，而不僅僅是簡單的雙活或多活部署。
另外在與公有云對接的過程中，確實會遇到一些挑戰和坑：比如公有云平臺通常會限制使用者在容器服務中執行某些特定型別的應用程式或容器映象。以及路由設定、網路安全限制等。此外，有些雲服務商在網路層面可能會實施一些特殊的技術手段，如MAC地址劫持等，導致一些不必要的麻煩和延遲。
順熾國 （某製造集團 雲平臺基礎服務負責人 ）
常見的一些網際網路應用很多隻關注C端的，也就是隻需要考慮北線（使用者入口）入口流量一個分流跟分發或者流量管控。但是在物聯網行業還需要考慮南線（裝置入網）的流量管理，這兩部分只有配網繫結的階段需要打通南北兩線的資料。
-
成本壓力：集團的伺服器規模正好在一千到五千個主機之間，導致了巨大的成本和運維壓力。解決這個問題正在考慮下雲。
-
業務複雜性：智慧家電行業有獨特的業務特點，需要同時關注北線（使用者入口）和南線（裝置入網）的流量管理，確保裝置與使用者之間的關聯和通訊暢通。
-
多雲節點部署：需要根據業務需求，在各個區域部署多雲節點，以提供更快的服務響應時間，降低使用者體驗的糟糕程度。
-
單元化思路：採用單元化的思路，儘量減少資料同步帶來的問題，透過北線和南線的閘道器，將業務閉環在單元內，以降低對專線的重度依賴，提高業務穩定性。
張觀石（ 泰健科技 CTO）
張老師講了個故事： 初始階段，自建CDN成本高，後接入雲CDN，但談判降價困難。後期透過多雲CDN架構，平衡質量和成本，使各廠商主動降價爭取份額。
他從一個比較新穎的角度談論了多雲架構的優勢：根據提供商的服務質量和價格，分配負載份額
另外他談到了多雲架構的優勢：
- 多雲並非只為實現多活，而是為了在架構中靈活利用不同雲服務的特點和價格優勢（使用特定GPU型號的業務只能在相應雲上部署，提高架構靈活性）
- 利用不同雲的產品優勢，如低價儲存，以降低整體成本。
透過多雲策略，企業可以增加與雲服務商的談判地位，從而更好地爭取資源、降低成本。同時，多雲策略也提供了更靈活的資源供給方式，可以根據業務需求在不同雲之間排程資源，確保服務的穩定性和容災能力。
另外由於多雲架構的複雜性，監控告警、排障流程等運維問題複雜度增加，需要考慮跨雲溝通和統一運維平臺的建設。這就引入了另一個問題：如何建立多雲融合統一管理（CMDB）
CMDB的核心功能是收集和儲存關於雲環境中各種資源的詳細資訊，包括虛擬機器、儲存、網路裝置等。管理員可以實現統一的互動介面，方便地查詢、分析和修改資源的配置狀態
根據企業對於多雲管理的管理要求，可以採用以下幾種方式：
-
十幾二十幾臺伺服器，沒有必要上CMDB系統，透過管理員登入各雲的控制檯進行管理
-
資源管理型：建立虛擬機器，配置網路等，基於開源的管理工具（比如rental？）二次開發較為容易，各家雲廠商的API介面並不複雜。
-
應用管理型，屬於高階別應用，可以與應用交付系統結合，從應用的視角出發，自動選擇合適的雲資源來部署和交付應用，基本要採購商業產品。定製化開發。或尋求混合雲廠商，有現有的解決方案可選。
--完結--