|
（2）機房遷移方案的設(shè)計目標(biāo)是：平滑遷移，不停服務(wù)；可以分批遷移；隨時可以回滾；（3）想要平滑的實施機房遷移，臨時性的多機房架構(gòu)不可避免；（1）理想多機房多活架構(gòu)，是純粹的“同機房連接”，僅有異步數(shù)據(jù)同步會跨機房；（2）理想多機房多活架構(gòu)，會有較嚴(yán)重數(shù)據(jù)一致性問題，僅適用于具備數(shù)據(jù)聚集效應(yīng)的業(yè)務(wù)場景，例如：滴滴，快狗打車；（3）偽多機房多活架構(gòu)，思路是“最小化跨機房連接”，機房區(qū)分主次，落地性強，對原有架構(gòu)沖擊較小，強烈推薦；多機房多活，只是平滑上云的一個中間狀態(tài)，那上云的步驟究竟是怎么樣的呢？如上圖，系統(tǒng)分層架構(gòu)包含：web，業(yè)務(wù)服務(wù)，基礎(chǔ)服務(wù)，緩存，數(shù)據(jù)庫，它們都需要進行遷移。（1）自底向上的遷移方案，從數(shù)據(jù)庫開始遷移；這兩種方案我分別在58同城和58到家實踐過，都是平滑的，螞蟻搬家式的，隨時可回滾，對業(yè)務(wù)無任何影響的，本文重點介紹“自頂向下”的方案。畫外音：14-15年58同城“逐日”項目，2000臺物理機平滑遷移至天津機房，我是當(dāng)時項目總架構(gòu)師。一、站點與服務(wù)遷移：無狀態(tài)，遷移容易 站點和服務(wù)無狀態(tài)，遷移起來并不困難。
步驟一，前置條件：步驟二，在新機房搭建好待遷移的子業(yè)務(wù)，部署好web站點，業(yè)務(wù)服務(wù)，基礎(chǔ)服務(wù)，做好充分的測試。（1）垂直拆分遷移，每次遷移的范圍不要太大，劃分好子業(yè)務(wù)和子系統(tǒng)；（2）緩存和數(shù)據(jù)庫還未遷移，存在跨機房連接；（3）新機房的配置文件注意“同連”，不要跨機房調(diào)用業(yè)務(wù)服務(wù)與基礎(chǔ)服務(wù)；步驟三，灰度切流量，將被遷移的子業(yè)務(wù)切5%的流量到新機房，觀察新機房的站點與服務(wù)是否異常。如果沒有問題，再10%，20%，50%，100%的逐步放量，直至某個子業(yè)務(wù)遷移完成。第一個子業(yè)務(wù)的站點和服務(wù)遷移完之后，第二個子業(yè)務(wù)、第三個子業(yè)務(wù)，螞蟻繼續(xù)搬家，直至所有的業(yè)務(wù)把站點和服務(wù)都全流量的遷移到新機房。在遷移過程中，任何一個子業(yè)務(wù)，任何時間發(fā)生異常，可以將流量切回舊機房。舊機房的站點、服務(wù)、配置都沒有改動，依然能提供服務(wù)。二、緩存遷移：有狀態(tài)，但數(shù)據(jù)可重建站點和服務(wù)遷移完之后，接下來再遷緩存。 （1）所有的入口流量都已經(jīng)遷到了新的機房；（2）緩存和數(shù)據(jù)庫，仍然使用舊機房；畫外音：舊機房的站點和服務(wù)不能停，只要舊機房不停，就保留了切回流量回滾的可能性。步驟四，在新機房搭建好緩存，緩存的規(guī)模和體量與舊機房一樣。
步驟五，按照子業(yè)務(wù)垂直逐步切換使用新機房的緩存，切換細(xì)節(jié)為：（1）運維做一個緩存內(nèi)網(wǎng)DNS的切換（內(nèi)網(wǎng)域名不變，IP切到新機房）；（2）殺掉原有緩存連接，業(yè)務(wù)線不需要做任何修改，只需要配合觀察服務(wù)；（3）緩存連接池會自動重連，重連會自動連接新機房的緩存；bingo，一個子業(yè)務(wù)緩存遷移完畢。（1）如果沒有使用內(nèi)網(wǎng)域名，而是采用IP直連緩存，則需要業(yè)務(wù)層配合，換新機房IP重啟；畫外音：說過無數(shù)次，一定要使用內(nèi)網(wǎng)域名。（2）緩存遷移時間，盡量選在流量低峰期，新緩存是空數(shù)據(jù)，如果選在流量高峰期，短時間內(nèi)可能會有大量請求透傳到數(shù)據(jù)庫上；（3）對于同一個服務(wù)，緩存的切換時瞬時的，不會同時使用新舊機房的緩存；緩存的遷移也是按照子業(yè)務(wù)，垂直拆分，螞蟻搬家式遷移的。整個遷移過程除了運維操作切內(nèi)網(wǎng)域名，研發(fā)和測試都只是配合觀察服務(wù)，風(fēng)險非常低。緩存允許cache miss，不用轉(zhuǎn)移舊緩存內(nèi)的數(shù)據(jù)，所以遷移方案比較簡單。
三、數(shù)據(jù)庫遷移：有狀態(tài)，數(shù)據(jù)也要遷移站點層，服務(wù)層，緩存層都遷移完之后，最后是數(shù)據(jù)庫的遷移。
在遷移數(shù)據(jù)庫之前，服務(wù)通過專線跨機房連數(shù)據(jù)庫。步驟六，先在新機房搭建新的數(shù)據(jù)庫。畫外音：自建機房，需要自己搭建新的MySQL實例；到家直接使用阿里云的RDS。步驟七，數(shù)據(jù)同步。自建機房可以使用數(shù)據(jù)庫MM/MS架構(gòu)同步數(shù)據(jù)，阿里云可以使用DTS同步數(shù)據(jù)。畫外音：DTS同步有一個大坑，只能通過公網(wǎng)同步非RDS的數(shù)據(jù)，至少在16年是這樣，不知道現(xiàn)在產(chǎn)品升級了沒有。數(shù)據(jù)庫同步完之后，如何進行數(shù)據(jù)源切換呢？能不能像緩存的遷移一樣，運維修改一個數(shù)據(jù)庫內(nèi)網(wǎng)DNS指向，然后切斷數(shù)據(jù)庫連接，讓服務(wù)重連新的數(shù)據(jù)庫呢？這樣的話，業(yè)務(wù)服務(wù)不需要改動，也不需要重啟。
（1）一定得保證數(shù)據(jù)庫同步完成，才能切流量，但數(shù)據(jù)同步總是有遲延的，舊機房一直在不停的寫如數(shù)據(jù)，何時才算同步完成？（2）只有域名和端口不發(fā)生變化，才能不修改配置完成切換，但如果域名和端口（主要是端口）發(fā)生變化，是做不到不修改配置和重啟的。舉個例子，假設(shè)原有數(shù)據(jù)庫實例端口用了5858，而阿里云要求你使用3200，就必須改端口重啟。步驟八，最終的方案是，DBA在舊機房的數(shù)據(jù)庫設(shè)置一個ReadOnly，停止數(shù)據(jù)的寫入，在秒級別，RDS同步完成之后，服務(wù)修改數(shù)據(jù)庫端口，重啟連接新機房的數(shù)據(jù)庫，完成數(shù)據(jù)層的切換。這個過程中，為了保證數(shù)據(jù)的一致性，會損失秒級別的寫入可用性。
經(jīng)過上述站點、服務(wù)、緩存、數(shù)據(jù)庫的遷移，平滑的螞蟻搬家式上云目標(biāo)就這么完成啦。自頂向下的機房遷移方案總結(jié)一、先遷移站點層、業(yè)務(wù)服務(wù)層和基礎(chǔ)服務(wù)層（1）準(zhǔn)備新機房與專線；（2）搭建集群，充分測試，子業(yè)務(wù)垂直拆分遷移；（3）灰度切流量；二、緩存層遷移（4）搭建新緩存；（5）運維修改緩存內(nèi)網(wǎng)DNS，切斷舊緩存連接，重連新緩存（這一步很騷），切流量；三、數(shù)據(jù)庫遷移（6）搭建新數(shù)據(jù)庫；（7）同步數(shù)據(jù)；（8）舊庫ReadOnly，同步完成后（秒級），服務(wù)指向新庫，改配置重啟，切流量；
以上8大步驟，整個過程分批遷移，一個子業(yè)務(wù)一個子業(yè)務(wù)的遷移，一塊緩存一塊緩存的遷移，一個數(shù)據(jù)庫一個數(shù)據(jù)庫的遷移，任何步驟出現(xiàn)問題都可以回滾的，整個過程不停服務(wù)。
|
