一、雙中心建設(shè)的核心目標(biāo)與需求拆解
同程旅行在 2021 年啟動(dòng) MySQL 雙中心項(xiàng)目，核心目標(biāo)是實(shí)現(xiàn)機(jī)房級容災(zāi)，確保 A 中心故障時(shí) B 中心能獨(dú)立支撐核心業(yè)務(wù)，保障服務(wù)穩(wěn)定性。項(xiàng)目啟動(dòng)前需明確三個(gè)關(guān)鍵問題：
WHAT（做什么）：確定納入雙中心的業(yè)務(wù)范圍。初期聚焦核心業(yè)務(wù)（如核心應(yīng)用 A/B/C），涉及 20000 + 應(yīng)用、10000+MySQL 數(shù)據(jù)庫及 40000+Redis/MongoDB 實(shí)例。通過 SRE 與 DBA 聯(lián)合梳理應(yīng)用列表與數(shù)據(jù)庫依賴關(guān)系，利用配置中心抓取會(huì)話地址，最終形成雙中心業(yè)務(wù)清單。
WHY（為何做）：區(qū)別于傳統(tǒng)異地災(zāi)備的 “冷備份” 模式，雙中心要求 B 中心具備實(shí)時(shí)讀寫能力，滿足業(yè)務(wù)連續(xù)性需求。原有的異步復(fù)制架構(gòu)因延遲高、切換風(fēng)險(xiǎn)大被淘汰，需構(gòu)建低延遲、高可用的集群架構(gòu)。
WHEN（何時(shí)完成）：分階段推進(jìn)建設(shè)，2021 年 3 月啟動(dòng)摸底與首批設(shè)備采購，5 月完成 B 中心節(jié)點(diǎn)搭建，8 月實(shí)現(xiàn)核心業(yè)務(wù)寫庫切換，12 月通過斷網(wǎng)演練驗(yàn)收。
二、技術(shù)架構(gòu)設(shè)計(jì)與實(shí)施策略
（一）架構(gòu)選型與優(yōu)化
初期方案（傳統(tǒng)主從架構(gòu)）：采用 MariaDB+MySQL 組合，A 中心主庫通過 MHA 管理 Slave 節(jié)點(diǎn)，B 中心作為災(zāi)備集群。但該架構(gòu)存在 “機(jī)房切換模塊與數(shù)據(jù)庫強(qiáng)耦合” 問題，切換時(shí)需手動(dòng)調(diào)整應(yīng)用配置，導(dǎo)致業(yè)務(wù)中斷風(fēng)險(xiǎn)高。
優(yōu)化方案（解耦架構(gòu)）：引入公有云資源構(gòu)建中心 C，通過智能解析模塊（TVS+Proxy）實(shí)現(xiàn)應(yīng)用與數(shù)據(jù)庫 IP 解耦。APP 調(diào)用統(tǒng)一 VIP+VPORT，底層通過 Proxy 動(dòng)態(tài)路由至 A/B 中心數(shù)據(jù)庫，切換時(shí)僅需修改解析規(guī)則，無需重啟應(yīng)用。該架構(gòu)支持讀寫分離，讀請求可負(fù)載至 B 中心 Slave 節(jié)點(diǎn)，提升資源利用率。
（二）實(shí)施策略與風(fēng)險(xiǎn)控制
分批次切換：避免一次性遷移帶來的業(yè)務(wù)沖擊，選擇業(yè)務(wù)低峰期（如夜間）執(zhí)行操作。先為每個(gè)集群在 B 中心添加節(jié)點(diǎn)，通過自動(dòng)化工具（如節(jié)點(diǎn)配置系統(tǒng)）批量完成環(huán)境初始化，再逐步將寫流量切換至 B 中心主庫。
自動(dòng)化與監(jiān)控：開發(fā)數(shù)據(jù)庫節(jié)點(diǎn)自動(dòng)化管理平臺(tái)，支持集群創(chuàng)建、節(jié)點(diǎn)添加 / 刪除等操作，單次節(jié)點(diǎn)部署耗時(shí)從人工 3 小時(shí)縮短至自動(dòng)化 10 分鐘。結(jié)合 Grafana 實(shí)時(shí)監(jiān)控復(fù)制延遲、連接數(shù)等指標(biāo)，設(shè)置閾值告警，提前發(fā)現(xiàn)主從同步異常。
三、斷網(wǎng)演練：從異常復(fù)盤到驗(yàn)收標(biāo)準(zhǔn)
（一）演練流程與關(guān)鍵指標(biāo)
斷網(wǎng)演練是雙中心驗(yàn)收的核心環(huán)節(jié)，目標(biāo)為：A 中心斷網(wǎng)后，B 中心在 10 秒內(nèi)自動(dòng)接管業(yè)務(wù)，且數(shù)據(jù)零丟失、業(yè)務(wù)恢復(fù)率 100%。具體步驟如下：
網(wǎng)絡(luò)隔離：通過 SDN 控制器切斷 A 中心數(shù)據(jù)庫集群網(wǎng)絡(luò)連接，模擬機(jī)房級故障。
狀態(tài)驗(yàn)證：利用會(huì)話采集器（Processlist 監(jiān)控）檢查是否有 A 中心 IP 訪問殘留，通過 MySQL 復(fù)制狀態(tài)接口驗(yàn)證 B 中心主庫角色是否激活。
業(yè)務(wù)驗(yàn)證：調(diào)用核心業(yè)務(wù)接口（如訂單查詢、用戶登錄），確保請求路由至 B 中心且響應(yīng)正常。
（二）異常復(fù)盤與優(yōu)化
首次演練暴露兩大問題：
網(wǎng)絡(luò)隔離不徹底：部分集群因防火墻規(guī)則未同步，仍存在 A 中心節(jié)點(diǎn)通信，通過自動(dòng)化腳本批量校驗(yàn)并更新防火墻策略解決。
應(yīng)用依賴未完全遷移：個(gè)別應(yīng)用硬編碼 A 中心數(shù)據(jù)庫 IP，導(dǎo)致切換后連接失敗。通過配置中心強(qiáng)制掃描并替換所有硬編碼地址，實(shí)現(xiàn)依賴關(guān)系全解耦。
最終演練結(jié)果顯示，98% 的集群在 10 秒內(nèi)完成切換，核心業(yè)務(wù)恢復(fù)時(shí)間控制在 1 分鐘內(nèi)，滿足驗(yàn)收標(biāo)準(zhǔn)。
四、未來規(guī)劃：技術(shù)債務(wù)與長期演進(jìn)
（一）技術(shù)債務(wù)解決
當(dāng)前架構(gòu)仍存在部分歷史遺留問題：
異步復(fù)制延遲：部分非核心業(yè)務(wù)仍使用異步復(fù)制，計(jì)劃引入半同步復(fù)制或 Group Replication 提升一致性。
容器化改造：現(xiàn)有數(shù)據(jù)庫節(jié)點(diǎn)基于物理機(jī)部署，后續(xù)將遷移至 K8s 容器平臺(tái)，實(shí)現(xiàn)資源彈性調(diào)度與快速擴(kuò)縮容。
（二）容災(zāi)能力升級
兩地三中心拓展：在現(xiàn)有 A/B 雙中心基礎(chǔ)上，于公有云部署第三中心（C 中心），形成 “本地 + 云端” 的混合容災(zāi)架構(gòu)，應(yīng)對區(qū)域性自然災(zāi)害等極端場景。
智能化切換：結(jié)合機(jī)器學(xué)習(xí)預(yù)測數(shù)據(jù)庫故障，在主庫出現(xiàn)異常前自動(dòng)觸發(fā)切換，變 “被動(dòng)容災(zāi)” 為 “主動(dòng)預(yù)防”。
總結(jié)
同程旅行 MySQL 雙中心建設(shè)是一場 “目標(biāo)驅(qū)動(dòng)、分階落地” 的技術(shù)實(shí)踐。通過明確業(yè)務(wù)邊界、解耦架構(gòu)設(shè)計(jì)與自動(dòng)化工具支撐，成功實(shí)現(xiàn)核心業(yè)務(wù)容災(zāi)能力從 “分鐘級恢復(fù)” 到 “秒級切換” 的跨越。未來將持續(xù)優(yōu)化底層架構(gòu)，推動(dòng)容災(zāi)體系向智能化、云原生方向演進(jìn)，為業(yè)務(wù)高速發(fā)展提供更堅(jiān)實(shí)的數(shù)據(jù)保障。
