在雲原生架構下，中介軟體管理方式和傳統方式有較大差別。首先在 K8s 上如何管理中介軟體叢集，其次雲原生架構將運維能力下沉，如何高效利用雲原生能力並實現中介軟體跨可用區高可用？在 10 月 18-19 日舉辦的 QCon 全球軟體開發大會上，網易雲信資深架構師裴明明為我們帶來了精彩的專題演講“雲原生架構下中介軟體聯邦高可用架構實踐”，重點介紹了網易雲信基於 K8s 的叢集聯邦能力實現中介軟體有狀態應用跨可用區高可用的最佳實踐，分享了網易雲信在 K8s 中管理中介軟體遇到的難題和解決方案，並且會分享最終的落地效果和上雲收益。 內容亮點利用雲原生技術棧實現中介軟體叢集的自動化管理，提升叢集管理運維效率和自愈能力，增加中介軟體叢集的彈性。利用 K8s 的叢集聯邦能力實現中介軟體這類有狀態應用的跨可用高可用。以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。本次演講我與大家探討的主題是“雲原生架構下中介軟體聯邦高可用架構實踐”。首先，我會簡要介紹中介軟體在雲原生平臺上的運維管理方式。接著，我們將深入探討在雲原生環境下實現中介軟體高可用性的實踐方法。特別是聯邦高可用性，這是中介軟體高可用性中的一個特殊場景。整個討論將分為四個部分。概述雲原生中介軟體的基本概念。探討雲原生中介軟體的管理策略，以尋求最佳實踐。介紹如何在雲原生架構中實現中介軟體的跨可用區高可用性，這是技術領域的一個熱點話題。展望未來，探討雲原生中介軟體的發展方向。
雲原生中介軟體
在傳統的架構中，部署中介軟體可能需要編寫大量指令碼和應用管理，以確保其健康執行和故障恢復。例如，我們可能需要使用特定的命令或系統服務來重啟失敗的服務。如果需要更高階的健康檢查和狀態管理，傳統架構下這些工作可能會變得相當複雜。在雲原生架構中，這些任務變得簡單許多。透過利用 Kubernetes（K8S）等技術，我們可以更容易地實現服務的自動恢復、健康檢測和優雅退出。雲原生架構的核心在於將應用層的運維特性與底層基礎設施的運維能力分離，並將它們整合到一箇中間層，從而封裝運維的複雜性，讓專業人員來處理。雲原生生態主要包括幾個部分：首先是容器技術，如 Kubernetes 和 Docker；其次是微服務領域的技術，如 Istio 和 HELM 等；此外，還有 Karmada 和 Operator Framework，這些技術共同構成了雲原生生態的基礎，使得我們可以更高效地部署和管理中介軟體，同時保持系統的高可用性和靈活性。
中介軟體的發展經歷了幾個階段。最初，人們接觸中介軟體時，通常是透過開源社群獲取相關的軟體包和部署方法，這是實現中介軟體的最基礎方式。雖然這種方法能夠實現中介軟體的基本功能，但其複雜度高，使用起來並不方便。隨後，許多廠商開始提供基於虛擬機器的中介軟體解決方案，這種方式已經能夠滿足大多數人的需求。使用者可以透過圖形介面輕鬆建立中介軟體叢集，例如 Redis 等。這種模式雖然方便，但也存在一些弊端，比如資料安全性無法得到保證，以及對於特定功能的定製需求難以在短時間內得到滿足。現在，隨著雲原生技術的發展，中介軟體的實現方式也在發生變化。我們更傾向於在雲原生環境中，以私有化的方式交付中介軟體。這種方式能夠充分利用雲原生的運維特性，快速實現基礎能力的部署，同時保證了資源的低消耗，提高了中介軟體的靈活性和安全性。雲原生中介軟體的實現依賴於 Kubernetes 的核心特性。這些特性包括：宣告式定義，基礎設施即程式碼，標準統一，易於編排；構建於標準 Kubernetes 之上，利用其靈活排程、故障自愈、彈性伸縮等內建能力簡化中介軟體的運維；自動化管控，資源統一排程，有效提升資源利用率，降低基礎設施成本；更適合構建私有化部署的 PaaS 中介軟體服務。
雲原生中介軟體管理
雲原生中介軟體的管理涉及到將中介軟體有效地部署到雲環境中，並確保其高效執行。實現這一目標，我們可以利用 K8S 提供的 operator 和相關能力。透過簡單的命令如 kubectl apply，我們可以迅速在 K8S 叢集中拉起容器，實現中介軟體的基本功能，至少在訪問層面沒有問題。然而，在實際使用過程中，我們會遇到一系列挑戰。首先，K8S 的 Pod 網路是隔離的，我們需要考慮如何優雅地從外部訪問這些中介軟體服務。由於中介軟體對流量和網路有依賴，網路配置變得尤為重要。此外，中介軟體通常是資源密集型的，比如對磁碟 IO 效能有高要求，我們需要考慮 K8S 提供的儲存解決方案是否合適。在中介軟體部署到 K8S 之後，我們還需要確保其穩定性。這包括可觀測性的建設，雖然 Prometheus 提供了基於 exporter 的監控採集框架，但我們還需要進一步強化監控能力，豐富監控指標。同時，我們要考慮中介軟體在雲環境中是否能保持原有的特性，比如在主機或虛擬機器上執行得很好的中介軟體，遷移到雲後是否還能保持這些特性。另一個問題是中介軟體的發現機制。在傳統的物理主機或虛擬機器環境中，中介軟體可能基於 IP 進行服務發現，但在雲環境中，IP 可能會變化，這就需要我們找到新的解決方案來處理這種變化。
網易雲信雲原生中介軟體實踐
這是網易雲信在雲原生中介軟體基礎架構圖。我們基於 K8s 構建了一個支援各種型別的底層架構，無論是來自不同廠商的解決方案，我們都能在此基礎上進行擴充套件。第二層是我們自研的雲原生基礎平臺，它能夠遮蔽多雲、多叢集和多版本的複雜性，方便管理底層資源。這一層支援節點親和性、節點分配等特性，並提供一致的 API，使得使用者可以從多個叢集中聚合資源。在此之上是我們的中介軟體層，主要基於 API 和 Operator 實現。我們還提供了獨特的 API 層來管理 Operator 的特性和自定義 CRD。中介軟體的種類相對集中，包括 Redis、Kafka、Nginx 等。我們內部已經部署了幾十種中介軟體，依據其使用頻率進行分類。在使用中介軟體時，我們也面臨一些挑戰，特別是如何滿足企業級特性。為此，我們與平臺整合，增強了審計、監控告警和日誌採集等功能。最上層是網路層的管理，我們提供了基礎的負載均衡（LB）、Nodeport 等解決方案，以確保訪問的穩定性和可靠性。
高效能與高可靠
在將中介軟體遷移到雲端並確保其高效能的過程中，我們面臨幾個關鍵挑戰，包括網路瓶頸和磁碟管理。網路效能對吞吐量和響應時間有著直接影響。為了實現高效的網路，我們採用了多種策略。由於 K8S 的 Pod 網路預設是隔離的，叢集外訪問會多進行一次轉發，影響效能。通常情況下，我們採用基於 BGP 的網路協議實現負載均衡，這樣可以分散流量並減少轉發跳數。此外，我們還基於 NodePort 提供了一種基礎能力，即使在沒有 BGP 支援的情況下，也能實現外部訪問，透過 Operator 將節點 IP 暴露給使用者，直接將流量路由到目標節點。磁碟管理對於依賴磁碟 IO 效能的中介軟體至關重要。我們發現本地磁碟更為可靠，並自研了一套基於 Linux 磁碟管理的系統，實現磁碟的動態管理，並與 PV 和 PVC 結合使用，快速完成生命週期管理。同時，我們還支援獨佔盤和共享盤，以滿足不同業務需求。中介軟體容器化功能適配和最佳化也是我們關注的重點。我們對不適應雲環境的中介軟體進行了最佳化，如服務發現適配 K8S 等。核心調優也是一個關鍵領域，我們透過軟中斷、CPU 繫結和網路卡 IO 最佳化等措施，確保容器化中介軟體的效能至少不會低於主機或虛擬機器上的效能。中介軟體的配置管理，將我們的經驗和最佳實踐整合到平臺中，幫助使用者快速部署和設定高效能中介軟體叢集。
雲原生中介軟體高可靠，我總結了兩個方面：高可用和可觀測。中介軟體高可用單中介軟體叢集透過節點反親和、拓撲分割槽排程實現節點的互斥；提供中介軟體實時備份和一鍵恢復能力；雲原生生態的叢集熱備多活，實現故障自動檢測，自動轉移，快速切流；基於 Kubernetes 叢集聯邦的同城多機房高可用。雲原生可觀測增強Prometheus 技術體系建設的中介軟體監控告警系統；雲原生日誌自動化採集元件 Loggie （網易雲信開源），對中介軟體叢集進行無侵入日誌採集；基於雲原生事件建立中介軟體事件管理能力，實現事件監控告警；中介軟體運維中心，提供風險巡檢、根因分析、自主診斷等能力，增強運維能力，提升叢集穩定性。
運維自動化
雲原生中介軟體的運維自動化主要依賴於 Operator 模式，其核心功能是監控中介軟體的狀態，並在狀態發生變化或出現問題時，迅速執行 Operator 中預設的邏輯來恢復服務。此外，我們還結合了 K8S 的監控和自動伸縮能力，實現了自動化伸縮，包括水平自動伸縮（HPA）等技術。在無狀態服務的情況下，自動伸縮相對簡單，只需增加副本數量即可。在有狀態的服務中，自動伸縮就變得複雜得多，需要特別的處理。我們內部有一套實踐方案，基於時間的 HPA 是一個比較可靠的方法。彈性伸縮在實際應用中較為困難，尤其是在有狀態的服務中。此外，我們還在探索 Serverless 化中介軟體，這也是基於自動化伸縮的能力來實現的。透過這些自動化運維的實踐，我們能夠提高中介軟體的可用性和彈性，同時降低人工干預。
中介軟體上雲確實帶來了許多優勢，但同時也伴隨著一些挑戰。如果能夠妥善解決這些難點，我們不僅能夠獲得技術上的優勢，還能構建起一個統一的能力平臺，這將極大地方便未來的擴充套件。因此，我們堅信雲原生技術是未來的發展方向。我們一直在內部以及與客戶合作中推進雲原生技術，並不斷地進行最佳化和改進。這包括提升通用能力、高階特性和統一運維等方面，我們持續不斷地進行這些方面的工作，以期達到更好的效果。同時，我們也將自己的一些經驗和成果，比如 Loggie 等專案，開源出來，與大家分享我們在這一領域的實踐和探索。
中介軟體跨可用區高可用
實現中介軟體跨可用區的高可用性是一個複雜的問題，尤其是在需要多機房容災能力的情況下。以 Elasticsearch（ES）為例，如果我們的業務架構設計得很好，業務本身是無狀態的，而所有的狀態和特性都依賴於中介軟體層，那麼我們就需要確保在一個機房當機時，ES 和業務都不受影響。面對這樣的挑戰，我們首先會考慮 ES 原生提供的能力，比如跨可用區資料同步的 CCR（Cross Cluster Replication）。但是，我們發現這種能力有限制，並且不是開源的。在深入研究 ES 的程式碼後，我們考慮是否可以基於 Translog 實現資料同步。但 Translog 的生命週期管理與我們的需求不符，因為它是一個快速的生命週期，使用後就會被刪除。在探索了一圈之後，我們發現要實現 ES 的資料同步，可能需要修改核心，沒有現成的好方案。這時，我們轉而考慮另一種方案：既然 ES 已經有了主從同步的能力，為什麼不將中介軟體部署在多個機房中呢？這樣，即使一個機房出現問題，其他機房的 ES 例項仍然可以繼續工作，保證業務的連續性。這種方法也是我們在傳統架構中實現高可用性的基礎能力。總結而言，如何實現中介軟體跨多個可用區的高可用性。最基本的方法是實現多個叢集之間的資料同步。資料同步實現後，我們就可以進一步考慮流量切換的問題，這直接影響到整個解決方案的穩定性和可靠性。我們的構建方案如下：中介軟體叢集高可用方式：多叢集資料同步單叢集跨可用區多叢集資料同步：熱備、雙活、多活等高可用能力單叢集跨可用區：聯邦多活，依賴中介軟體自身高可用多數選主的分散式一致性協議：要求至少三個可用區來保證任意可用區故障中介軟體依然可用對底層基礎設施要求較高：不同可用區叢集節點間的網路連通性和網路質量要求
中介軟體叢集聯邦的問題與挑戰
在雲原生環境中使用叢集聯邦的方式部署有狀態服務面臨著一系列問題和挑戰。首先，有狀態服務的部署並不容易，因為這些服務之間存在著緊密的聯絡。例如，在進行有序的滾動更新時，服務例項之間的依賴關係使得狀態管理變得複雜。以最簡單的狀態集（如 0、1、2、3）為例，它們的服務發現和資料關係都是相互關聯的，這就要求我們在管理狀態時必須非常謹慎。其次，中介軟體的聯邦排程也是一個重要挑戰。當中介軟體分佈在多個 K8S 叢集中時，我們需要考慮如何合理地分配節點和分片。合理的排程不僅能確保資源的有效利用，還能在節點當機或進行滾動升級時，最小化變動帶來的影響。最後，故障恢復能力同樣至關重要。在一個由三個可用區組成的 K8S 叢集中，如果其中一個叢集出現故障，我們需要確保系統能夠快速恢復。如果多個叢集都出現問題，我們的體系是否能有效處理這些故障場景？這就是在設計聯邦高可用性時必須考慮的關鍵因素。
雲原生下跨可用區高可用
在業內，跨可用區高可用性的解決方案備受關注。我們很早就開始關注社群，並研究了許多開源專案是如何實現聯邦高可用性的。其中，Federation 2.0 是社群早期開源的一個專案，而目前比較出名的是 Karmada，我們與這個專案有很多合作，併為社群做出了貢獻。Karmada 是基於聯邦高可用性理念自主研發的系統，它對中介軟體聯邦高可用性提供了支援。然而 Karmada 本身有一些侷限性，比如部署時需要依賴額外的 ETCD 叢集和 API Server，所以我們在它的基礎上做了許多最佳化和改進。例如，我們對有狀態服務的狀態聚合進行了最佳化；最佳化架構使得 Karmada 可以直接部署在管控的 K8S 叢集中。此外，我們還實現了對 Kubernetes API Server 的直接相容，並提供了面向使用者的查詢介面。在狀態聚合、spec 下發以及 annotation 管理等方面，我們做了很多特殊處理，以適應中介軟體的下發和狀態聚合，從而實現中介軟體跨可用區的部署。
中介軟體叢集聯邦實現
中介軟體的聯邦高可用性實現是一個複雜的架構設計。在我們的設計中，至少需要五個 K8S 叢集來實現聯邦高可用性。這包括一個主管控叢集和一個備用管控叢集，以及三個計算叢集。我們認為至少需要三個可用區來實現最佳的高可用能力。具體實現時，我們的架構包括三個計算叢集和兩個管控叢集。在聯邦排程元件方面，我們有聯邦控制器和聯邦分發元件，還有負責跨叢集的流量治理元件，確保所有叢集之間能夠順暢通訊，並對外提供服務。同時，主備管控叢集在中介軟體的生命週期管理和故障恢復能力方面也扮演著關鍵角色，它們依賴管控面的 Operator 進行統一排程。此外，我們還實現了跨叢集選主高可用效能力。在發生故障時，系統能夠自動進行故障恢復，確保服務的連續性和資料的一致性。
有狀態服務聯邦管控
狀態服務的聯邦管控是一個複雜的過程，涉及到資源的建立、分發和狀態管理。當建立一箇中介軟體資源時，首先需要在管控層面進行建立，然後透過我們的分發元件將資源分發到不同的可用區。這個過程會根據建立的拓撲結構來決定資源如何分配到各個可用區，比如將 20 個節點分佈在 5 個可用區中。一旦確定了拓撲結構，資源就會被下發到各個子叢集。子叢集的控制器接收到資源後，就會根據這些資訊來管理中介軟體在本叢集中的形態和拓撲結構。子控制器只需要關注自己叢集內的狀態，並將其寫入狀態資訊中即可。聯邦控制器會進一步聚合這些狀態資訊，從而瞭解整個聯邦叢集的狀態。接下來，聯邦控制器會根據叢集的組網情況和節點關係，告訴子控制器整個叢集的配置和節點發現應該如何設定，以及下一步的狀態應該是什麼樣子。整個過程是一個漸進式的交付流程，涉及到管控和計算之間的協作。透過幾輪的迭代，服務最終會達到一致狀態，實現叢集的成功交付。此外，這個流程還確保了叢集具備自愈能力，能夠在出現問題時自動恢復，確保服務的高可用性。
有狀態服務聯邦排程演算法
有狀態服務的聯邦排程演算法的實現涉及幾個關鍵方面。首先，在新建叢集時，需要計算叢集的初始狀態和排程策略，決定資源如何在多個叢集中分佈，以及每個叢集內的拓撲結構。其次，在執行滾動操作，如擴縮容或更新時，需要重新計算拓撲結構的變化，以確定最佳的資源分佈。最後，在故障遷移時，需要確定如何處理故障轉移，例如一個叢集故障後無法恢復，或者需要將叢集數量從三個擴充套件到五個。了應對這些場景，我們總結了如下核心規則。半數約束：部署中介軟體節點和 K8S 叢集分佈規則，約束任意 K8S 叢集中節點數不超過半數，要求節點在 K8s 叢集中儘可能均分。擴容約束：中介軟體叢集擴縮容時，演算法應該在滿足上述約束的情況下，確保排程演算法一致性，存量節點不會重新排程。故障 約束：叢集故障時，中介軟體角色相對集中，會打破上述規則。故障恢復時，應重新滿足上述約束。除了這些核心規則，還有許多細節邏輯，比如考慮節點資源是否滿足需求，以及每個節點的資源是否能夠支援最最佳化的排程。聯邦排程演算法與 K8S 的排程類似，但特點是所有排程都是上下文相關的，不能單獨對一個節點進行排程，這增加了排程的複雜度。一旦排程演算法計算出整個拓撲結構，結果會儲存在相應的自定義資源（CR）中，並通知控制器繼續下發拓撲。這樣，控制器就知道如何根據計算出的拓撲結構進行下一步操作，確保有狀態服務的聯邦排程演算法能夠有效地管理和最佳化資源分佈。
叢集聯邦網路管理
叢集聯邦網路管理的核心挑戰在於處理不同可用區中的節點網路連通性問題。由於這些節點的網路本身可能不連通，或者相互之間難以發現，我們需要確保 Pod 網路是通暢的。然而當 Pod IP 發生變化時，服務發現就變得複雜，通常需要依賴域名來實現。為了解決這個問題，我們設計了一些方案。其中較為可靠的方案之一是利用 External DNS 伺服器，透過改寫 DNS 的能力，讓我們的註冊元件能夠監控所有 Service 和 EP 的變更，並將對應的 DNS 解析資訊更新到所有自建的 DNS 伺服器中。這樣，在 CoreDNS 進行域名解析請求時，能夠轉發到我們的外部 DNS 伺服器進行解析，這是一個實現相對複雜的設計方案。此外，我們還有些更簡化或輕量級的方法。例如，我們可以直接在 EP 中透過 Operator 監控對端資源的列表變化。一旦獲取變化，我們在自己的叢集中建立一個 EP，並將對應的 Hostname 和 IP 填入，從而實現在這個叢集內部的訪問。這種方法減少了對外部 DNS 伺服器的依賴，簡化了網路管理流程。
聯邦元件高可用
聯邦元件的高可用性對於整個聯邦叢集的穩定執行至關重要。我們需要確保聯邦元件能夠在計算叢集或管控叢集中的任何一個叢集發生故障時，依然保持正常執行。為此，我們實現了管控叢集的主備高可用方案，這個方案相對簡單，基於分散式選舉演算法，類似於 Keepalived 的能力，透過分配不同的優先順序值來確定哪個節點能夠成為 leader。在啟動時，如果發現資料不一致，我們會阻止服務恢復，以保證資料的一致性，儘管這可能會犧牲一些可用性。在網易雲信的實踐中，我們已經在許多中介軟體上實現了聯邦高可用。其中，Redis 是一個相對複雜的案例，因為它不僅涉及拓撲結構，還包括分片、主從分片等。如果一個可用區發生故障，Redis 的分片需要重新分配，這可能導致不均衡。在叢集恢復後，我們需要 operator 介入，重新調整以達到均衡狀態，因為雖然節點數是均衡的，但角色分配可能不均衡，這增加了實現的複雜性。其他中介軟體，如 Elasticsearch 也會面臨一些複雜性，對叢集節點間通訊方式和證書管理要求較高；而 ZooKeeper 則因為配置方式對暴露 IP 的要求較高，但是相對來說是一個更簡單的案例。透過這些實踐，我們不斷最佳化聯邦元件的高可用性，以確保在各種故障情況下，聯邦叢集都能保持穩定執行。
未來展望
我們計劃在雲原生領域進一步利用其底座能力，以實現持續迭代、穩定提升和降本增效。我們將持續在雲原生建設上投入，利用雲原生的可觀測性來完善我們的服務，同時在 FinOps 方面，我們在內部已經有所實踐，併產生效果。雲原生中介軟體的運維與人工智慧的結合也是我們的核心方向。我們的目標是從故障發現到故障消除，實現根因分析和故障恢復的自動化。我們的探索從神經網路演算法開始，已經積累了豐富的經驗，尤其是在小型模型的應用上已經取得了良好的效果。現在，我們正在探索大型模型，並基於智慧體技術進行分析能力和故障恢復的開發提升。我們希望將來能夠藉助人工智慧技術，進一步提升中介軟體的穩定性，使雲原生中介軟體的發展更加穩健。
立即瞭解雲原生中介軟體、微服務等相關~！