《多機房平滑遷移架構方案目標》介紹了上雲的背景，以及三個重要結論：

（1）單機房架構的核心是“全連接”；

（2）機房遷移方案的設計目標是：平滑遷移，不停服務；可以分批遷移；隨時可以回滾；

（3）想要平滑的實施機房遷移，臨時性的多機房架構不可避免；

《多機房多活架構》說明了在機房遷移的過程中，一定有一個“多機房多活”的中間狀態：

（1）理想多機房多活架構，是純粹的“同機房連接”，僅有異步數據同步會跨機房；

（2）理想多機房多活架構，會有較嚴重數據一致性問題，僅適用於具備數據聚集效應的業務場景，例如：滴滴，快狗打車；

（3）偽多機房多活架構，思路是“最小化跨機房連接”，機房區分主次，落地性強，對原有架構衝擊較小，強烈推薦；

多機房多活，只是平滑上雲的一箇中間狀態，那上雲的步驟究竟是怎麼樣的呢？

【5】核心問題五，如何分批平滑上雲？

如上圖，系統分層架構包含：web，業務服務，基礎服務，緩存，數據庫，它們都需要進行遷移。

大的方向，有兩種方案：

（1）自底向上的遷移方案，從數據庫開始遷移；

（2）自頂向下的遷移方案，從web開始遷移；

這兩種方案我分別在58同城和58到家實踐過，都是平滑的，螞蟻搬家式的，隨時可回滾，對業務無任何影響的，本文重點介紹“自頂向下”的方案。

畫外音：14-15年58同城“逐日”項目，2000臺物理機平滑遷移至天津機房，我是當時項目總架構師。

一、站點與服務遷移：無狀態，遷移容易

站點和服務無狀態，遷移起來並不困難。

（1）新機房準備就緒；

（2）專線準備就緒；

步驟二，在新機房搭建好待遷移的子業務，部署好web站點，業務服務，基礎服務，做好充分的測試。

這裡要重點說明的是：

（1）垂直拆分遷移，每次遷移的範圍不要太大，劃分好子業務和子系統；

（2）緩存和數據庫還未遷移，存在跨機房連接；

（3）新機房的配置文件注意“同連”，不要跨機房調用業務服務與基礎服務；

畫外音，只要不切流量：

（1）依然老機房提供服務；

（2）新機房隨便玩；

步驟三，灰度切流量，將被遷移的子業務切5%的流量到新機房，觀察新機房的站點與服務是否異常。如果沒有問題，再10%，20%，50%，100%的逐步放量，直至某個子業務遷移完成。

第一個子業務的站點和服務遷移完之後，第二個子業務、第三個子業務，螞蟻繼續搬家，直至所有的業務把站點和服務都全流量的遷移到新機房。

如何應對異常？

在遷移過程中，任何一個子業務，任何時間發生異常，可以將流量切回舊機房。舊機房的站點、服務、配置都沒有改動，依然能提供服務。

這是一個非常穩的遷移方案。

二、緩存遷移：有狀態，但數據可重建

站點和服務遷移完之後，接下來再遷緩存。

經過第一步的遷移，如上圖：

（1）所有的入口流量都已經遷到了新的機房；

（2）緩存和數據庫，仍然使用舊機房；

畫外音：舊機房的站點和服務不能停，只要舊機房不停，就保留了切迴流量回滾的可能性。

步驟四，在新機房搭建好緩存，緩存的規模和體量與舊機房一樣。

步驟五，按照子業務垂直逐步切換使用新機房的緩存，切換細節為：

（1）運維做一個緩存內網DNS的切換（內網域名不變，IP切到新機房）；

（2）殺掉原有緩存連接，業務線不需要做任何修改，只需要配合觀察服務；

（3）緩存連接池會自動重連，重連會自動連接新機房的緩存；

bingo，一個子業務緩存遷移完畢。

這裡要注意幾個點：

（1）如果沒有使用內網域名，而是採用IP直連緩存，則需要業務層配合，換新機房IP重啟；

畫外音：說過無數次，一定要使用內網域名。

（2）緩存遷移時間，儘量選在流量低峰期，新緩存是空數據，如果選在流量高峰期，短時間內可能會有大量請求透傳到數據庫上；

（3）對於同一個服務，緩存的切換時瞬時的，不會同時使用新舊機房的緩存；

畫外音：否則容易出現一致性問題。

緩存的遷移也是按照子業務，垂直拆分，螞蟻搬家式遷移的。整個遷移過程除了運維操作切內網域名，研發和測試都只是配合觀察服務，風險非常低。

緩存允許cache miss，不用轉移舊緩存內的數據，所以遷移方案比較簡單。

三、數據庫遷移：有狀態，數據也要遷移

站點層，服務層，緩存層都遷移完之後，最後是數據庫的遷移。

在遷移數據庫之前，服務通過專線跨機房連數據庫。

如何進行數據庫遷移呢？

步驟六，先在新機房搭建新的數據庫。

畫外音：自建機房，需要自己搭建新的MySQL實例；到家直接使用阿里雲的RDS。

步驟七，數據同步。自建機房可以使用數據庫MM/MS架構同步數據，阿里雲可以使用DTS同步數據。

畫外音：DTS同步有一個大坑，只能通過公網同步非RDS的數據，至少在16年是這樣，不知道現在產品升級了沒有。

數據庫同步完之後，如何進行數據源切換呢？

能不能像緩存的遷移一樣，運維修改一個數據庫內網DNS指向，然後切斷數據庫連接，讓服務重連新的數據庫呢？這樣的話，業務服務不需要改動，也不需要重啟。

這個方式看上去很不錯，但是：

（1）一定得保證數據庫同步完成，才能切流量，但數據同步總是有遲延的，舊機房一直在不停的寫如數據，何時才算同步完成？

（2）只有域名和端口不發生變化，才能不修改配置完成切換，但如果域名和端口（主要是端口）發生變化，是做不到不修改配置和重啟的。舉個例子，假設原有數據庫實例端口用了5858，而阿里雲要求你使用3200，就必須改端口重啟。

步驟八，最終的方案是，DBA在舊機房的數據庫設置一個ReadOnly，停止數據的寫入，在秒級別，RDS同步完成之後，服務修改數據庫端口，重啟連接新機房的數據庫，完成數據層的切換。

這個過程中，為了保證數據的一致性，會損失秒級別的寫入可用性。

畫外音：幾百臺機器，幾千個集群，耗時一個季度。

自頂向下的機房遷移方案總結

一、先遷移站點層、業務服務層和基礎服務層

（1）準備新機房與專線；

（2）搭建集群，充分測試，子業務垂直拆分遷移；

（3）灰度切流量；

二、緩存層遷移

（4）搭建新緩存；

（5）運維修改緩存內網DNS，切斷舊緩存連接，重連新緩存（這一步很騷），切流量；

三、數據庫遷移

（6）搭建新數據庫；

（7）同步數據；

（8）舊庫ReadOnly，同步完成後（秒級），服務指向新庫，改配置重啟，切流量；

以上8大步驟，整個過程分批遷移，一個子業務一個子業務的遷移，一塊緩存一塊緩存的遷移，一個數據庫一個數據庫的遷移，任何步驟出現問題都可以回滾的，整個過程不停服務。

思路比結論重要。

閱讀更多 Java高級架構師 的文章

關鍵字: DNS 設計 DTS