當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

混合云应用双活容灾实践

發布時間：2025/3/20 编程问答 60 豆豆

生活随笔收集整理的這篇文章主要介紹了混合云应用双活容灾实践小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

作者：遠跖

前言

越來越多的企業在數字化轉型和上云進程中選擇混合云的形態（云+自建 IDC 或云+其他廠商云）來進行容災建設，一方面不會過度依賴單一云廠商，另一方面還能充分利用已有的線下 IDC 資源。

MSHA 云原生多活容災解決方案 [1] ，也發布了混合云多活容災產品能力。本文會通過一個業務 Demo 案例，介紹混合云容災建設的難點，以及如何基于 MSHA 來快速搭建應用雙活架構并具備分鐘級業務恢復能力。

業務混合云容災實踐

業務背景信息

A 企業是一個零售行業電商交易平臺，業務系統部署在自建 IDC 機房，存在以下痛點：

業務僅在 IDC 單機房部署，缺少容災能力。
IDC 容量不足，物理機器升級替換周期長，不足以支撐業務的快速發展。

業務在快速發展過程中，多次遇到的容量不足以及故障問題引起了公司高層的重視，決心進行容災能力建設。由于自建 IDC 是公司已有資產且穩定使用多年，同時不希望過度依賴于云，因此期望建立 IDC+云的混合云形態容災架構。

當前應用部署架構

電商交易平臺包含的應用：

frontend：Web 應用，負責和用戶交互。
cartservice：購物車應用，提供購物車添加、存儲和查詢服務。
productservice：商品應用，提供商品、庫存服務。

技術棧：

SpringBoot。
RPC 框架：SpringCloud、Dubbo，注冊中心使用自建的 Nacos、Zookeeper。
數據庫 Redis 和 MySQL。

混合云容災目標

業務容災需求歸納如下：

云上云下互容災，切換 RTO 為分鐘級。 期望云上云下相互容災，繼續發揮 IDC 的價值，且不 100% 依賴于云。面對 IDC 或云故障場景，關鍵時刻要敢切換、能切換，且切換 RTO 要求小于 10 分鐘。
無數據一致性風險。 云上云下的兩個數據中心數據強一致，日常態和容災切換過程中都要避免存在臟寫等數據一致性風險。
一站式管控。 業務容災涉及的技術棧框架和云產品，需要統一管控、統一運維、統一切換，操作收斂在一站式管控平臺，方便故障場景快速白屏化操作，自動化執行。
實施周期短，改造成本低。 業務存在多個產品線，依賴關系復雜、調用鏈路長，且處于高速發展頻繁迭代時期，期望容災建設不會給業務研發團隊帶來改造負擔。

建設難點

流量管理難度高
若采用 DNS 將流量按權重解析到云上和云下，存在修改 DNS 解析生效時間長的問題（通常為十分鐘或小時級，參見?DNS 解析生效時間 FAQ [2] ），不能滿足容災切換小于 10 分鐘的要求。
業務應用所依賴的 Redis 和 MySQL，IDC內采用開源自建而云上直接使用云產品，要實現開源自建+云產品的容災切換能力難。
容災切換數據質量保障難
容災切換過程中，可能因數據同步延遲導致讀到舊數據，以及切換規則推送到分布式應用節點時間不一致等原因可能造成云上云下數據庫同時讀寫而出現臟寫的問題，整個切換過程數據質量保障是個關鍵點，同時也是難點。
無業務代碼侵入難
要實現 Redis、MySQL 容災切換能力，通常需要業務應用配合改造，對業務代碼侵入大。

解決方案

結合業務容災需求和混合云 IDC+云形態的特點，采用應用雙活架構能夠較好的滿足業務容災訴求。

應用雙活架構

架構簡圖：

架構規范：

選擇離 IDC 物理距離<=200km 的云上 Region，網絡延遲較低（約 5~7ms）。
應用、中間件云上云下冗余對稱部署，同時對外提供服務（應用雙活）。
數據庫異地主備，異步復制備份。應用讀寫同一數據中心的數據庫，避免考慮一致性問題。

詳細方案

應用流量雙活

業務應用云上云下對稱部署，并基于 MSHA 接入層集群，來承接入口 HTTP/HTTPS 流量，按照比例或精準路由規則云上云下分流。多活控制臺提供 MSFE 集群界面白屏化的部署、擴縮容、監控等常規運維能力，以及應對故障場景的分鐘級切流能力。

服務互通和同單元優先調用

業務應用需要按業務產品線分批上云，過程中存在下游應用僅 IDC 部署的情況。利用 MSHA 注冊中心同步功能，可實現云上云下服務互通，助力業務上云。同時基于 MSHA-Agent 的切面能力，在 Dubbo/SpringCloud 服務調用時，Consumer 優先調用同單元內的Provider，從而避免跨機房調用帶來的網絡延遲，減小業務請求 RT。

數據同步&數據庫連接切換

數據庫異地主備部署，云上云下應用日常態均讀寫云上 Redis 和 RDS 數據庫，無需考慮數據一致性問題。MSHA 控制臺通過集成 DTS 同步組件，支持云上云下的數據同步（異步復制）。同時基于 MSHA-Agent 切面能力，具備應用數據庫訪問連接的切換能力，云上 Redis 或 RDS 故障則可將讀寫訪問連接切換到 IDC 內的 Redis 或 MySQL，反之亦然。切換過程中還具備禁寫保護能力，避免產生讀到舊數據以及臟寫等數據質量問題。

一站式管控&無業務代碼侵入

MSHA 控制臺，支持 HTTP、數據庫訪問流量的統一管控、統一切換，操作收斂在一站式管控平臺，方便故障場景快速白屏化操作，自動化執行。同時針對業務應用 MSHA 提供了 Agent 接入方式，無需業務代碼改造即可獲得相關容災切換能力。

改造內容

應用上云
選擇跟自建 IDC 較近的阿里云地域，云上完全冗余的部署一套應用、中間件和數據庫，以便搭建云上云下雙活容災架構。在這個 Demo 案例中，選擇杭州 Region 作為容災單元。
網絡打通：
接入 CEN 云企業網，實現云上云下網絡互通（詳見多接入方式構建企業級混合云文檔 [3 ] ）。
接入集群部署和配置：
云上云下部署 MSHA 接入層集群（MSFE），上掛 SLB 用于公網接入以及 MSFE 集群的負載均衡（參見使用文檔 [4 ] ）。
錄入域名、URI 和后端應用地址，從而具備云上云下分流和分鐘級切流能力（參見使用文檔 [5 ] ）。
應用：
云上分批部署業務應用。
JAVA 應用安裝 MSHA-Agent，并使用 Nacos 作為管控命令下發通道，從而具備微服務同單元優先調用以及數據庫訪問連接切換能力（參見使用文檔 [6 ] ）。
中間件和數據庫：
云上部署 MSE 托管 ZK/Nacos 注冊中心、云數據庫 Redis 和 RDS，建議使用跨可用區部署高可用版本，具備同城雙活容災能力。
若存在某應用僅 IDC 部署的情況，需要配置注冊中心的服務同步（參見使用文檔 [7 ] ）。
配置云數據庫 Redis/RDS 和自建 Redis/MySQL 的數據同步（參見使用文檔 [8 ] ）。

改造后的應用部署架構

日常場景：IDC+云上同時承擔業務流量–應用雙活

訪問電商 Demo 首頁，查看實際流量調用鏈：概率性的訪問到北京或杭州單元，均讀寫北京單元內的數據庫。

容災能力

RPO：<=1min（依賴于 DTS 同步性能）
RTO：<=1min（依賴于 DTS 同步延遲，MSHA 組件實現秒級切換。整體 RTO<=1min）

容災能力驗證

基于 MSHA 完成應用雙活架構建設后，還需驗證業務容災能力是否符合預期。接下來將制造真實的故障，來驗證容災恢復能力。

7.1 演練準備

進入 MSHA 控制臺，在左側菜單欄選擇監控大盤。頁面頂部，下拉選擇切換到實際使用的命名空間。

查看頁面中的各項監控指標。

說明：演練前，基于 MSHA 流量監控或其他監控產品，確定業務穩態的監控指標（如日常情況 RT<=200ms，錯誤率<1%），以便在故障發生時判斷故障影響面以及在故障恢復后判斷業務的實際恢復情況。

7.2 應用故障注入

這里我們使用阿里云故障演練產品，對阿里云-北京的商品應用注入故障。

進入?Chaos 故障演練產品控制臺 [9 ] ，頂部選擇切換到相應地域，左側導航欄選擇我的空間。

在我的空間選擇配置好的演練（50% 概率網絡丟包），然后單擊執行演練。

故障注入成功后，打開電商首頁或進行下單，有概率出現訪問異常，符合預期。

7.3 切流恢復

在北京單元的商品應用故障的情況下，可以通過 MSHA 切流功能，將云上入口流量切 0，快速恢復業務。

預期

100% 流量切換到杭州單元后，業務完全恢復，不受北京單元的故障影響。

切流操作

進入 MSHA 控制臺，在左側導航欄選擇切流>異地應用雙活切流。

在切流頁面，對北京單元點擊一鍵切零。

單擊執行預檢查，在切流檢查區域，單擊確認，開始切流。

在切流任務頁面的當前狀態顯示切流完成，表示切流已成功。

刷新電商 Demo 首頁，多次訪問均能正常展示，符合預期。

查看實際流量調用鏈：流量始終訪問到杭州單元，讀寫北京單元內的數據庫。

7.4 數據庫故障注入

從上面調用鏈可以看出，杭州單元內的應用仍然訪問的是北京單元的 Redis、MySQL 數據庫。我們繼續使用?Chaos 故障演練 [10 ] 產品對北京單元的 Redis、MySQL 數據庫注入故障，制造數據庫故障場景。

故障注入成功后，打開電商首頁或進行下單始終訪問異常，符合預期。

7.5 切換數據庫進行恢復

在北京單元的數據庫故障的情況下，可以通過 MSHA 數據庫切換功能，將應用訪問的 Redis/MySQL 的連接切換至杭州單元的數據庫（切換過程中會等待數據同步追平，期間會短暫禁寫）。

預期

應用連接的數據庫切換到杭州后，業務完全恢復，不受北京單元的故障影響。

切流操作

進入 MSHA 控制臺，在左側導航欄選擇異地應用雙活>數據層配置。

2.在數據保護規則列表中，找到商品、訂單、購物車數據庫，逐個點擊主備切換。

點擊主備切換后，會進入預檢查頁面，確認各檢查項狀態正常后，點擊在確認執行，則進入切換詳情頁，并自動執行切換流程。

主備切換詳情頁，可以看到切換進度和切換結果，任務進度 100% 后，表示切換完成。

商品、訂單、購物車數據庫都主備切換完成后。多次訪問電商 Demo 首頁或進行下單，發現均已正常，主備切換后業務功能完全恢復，符合預期。

總結

在本篇文章中，我們介紹了 MSHA 多活容災助力企業進行混合云應用雙活容災建設的實踐案例，給出了容災架構建設實踐方法，同時利用 Chaos 故障演練產品注入真實故障，來驗證故障場景業務容災能力是否符合預期。

最后，歡迎大家掃描下方二維碼或搜索群號（31623894）進釘釘群進行咨詢和交流，群名稱：多活容災(MSHA)交流釘釘群。

總結

以上是生活随笔為你收集整理的混合云应用双活容灾实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

双活容灾

上一篇：全面容器化之后，来电科技如何实现微服务治
下一篇：如何定位并修复 HttpCore5 中的

编程问答

混合云应用双活容灾实践

前言

業務混合云容災實踐

業務背景信息

當前應用部署架構

混合云容災目標

建設難點

解決方案

應用雙活架構

詳細方案

改造內容

改造后的應用部署架構

容災能力

容災能力驗證

7.1 演練準備

7.2 應用故障注入

7.3 切流恢復

預期

切流操作

7.4 數據庫故障注入

7.5 切換數據庫進行恢復

預期

切流操作

總結

相關閱讀

總結