《多機房平滑遷移架構方案目標》介紹了上雲的背景,以及三個重要結論:
(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大步驟,整個過程分批遷移,一個子業務一個子業務的遷移,一塊緩存一塊緩存的遷移,一個數據庫一個數據庫的遷移,任何步驟出現問題都可以回滾的,整個過程不停服務。
思路比結論重要。