在雲原生架構下，中間件管理方式和傳統方式有較大差別。首先在 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 方面，我們在內部已經有所實踐，併產生效果。雲原生中間件的運維與人工智能的結合也是我們的核心方向。我們的目標是從故障發現到故障消除，實現根因分析和故障恢復的自動化。我們的探索從神經網絡算法開始，已經積累了豐富的經驗，尤其是在小型模型的應用上已經取得了良好的效果。現在，我們正在探索大型模型，並基於智能體技術進行分析能力和故障恢復的開發提升。我們希望將來能夠藉助人工智能技術，進一步提升中間件的穩定性，使雲原生中間件的發展更加穩健。

立即瞭解雲原生中間件、微服務等相關~！