參考 來自58到家的沈劍分享的《58到家從IDC到雲端架構遷移之路》。
機房遷移是一個很大的動作：
15年在58同城實施過一次（“逐日”項目），幾千臺物理機，從IDC遷到了騰訊的天津機房，項目做了10個多月，跨所有的部門，與所有的業務都相關；
16年在58到家又實施了一次（“凌雲”項目），幾百臺虛擬機，從IDC遷到阿里雲，前後大概一個季度的時間，也是所有技術部門都需要配合的一個大項目。
“單機房架構-全連”
要說機房遷移，先來看看被遷移的系統是一個什麼樣的架構。
上圖是一個典型的互聯網單機房系統架構：
（1）上游是客戶端，PC瀏覽器或者APP；
（2）然後是站點接入層，爲了面對高流量，保證架構的高可用，站點冗餘了多份；
（3）接下來是服務層，服務層又分爲與業務相關的業務服務，以及業務無關的基礎服務，爲了保證高可用，所有服務也冗餘了多份；
（4）底層是數據層，數據層又分爲緩存數據與數據庫；
至於爲什麼要做分層架構，不是今天的重點，不做展開討論，這是一個典型的互聯網單機房分層架構：所有的應用、服務、數據是部署在同一個機房，這個架構有的一個關鍵詞，叫做“全連”：
（1）站點層調用業務服務層，業務服務複製了多少份，上層就要連接多少個服務；
（2）業務服務層調用基礎服務層，基礎服務複製了多少份，上層就要連多少個服務；
（3）服務層調用數據庫，從庫冗餘了多少份，上層就要連多少個從庫；
比如說，站點接入層某一個應用有10臺機器，業務服務層某一個服務有8層機器，那肯定是上游的10臺會與下游的8臺進行一個全相連的。系統架構的可用性保證，負載均衡保證，是服務的連接池去做的。不僅僅接入層連接業務服務層是這樣，業務服務層連接基礎服務層，服務層連接數據庫也都是這樣，這就是所謂的“全連”。
“機房遷移的目標是平滑”
單機房架構的特點是“全連”，那麼機房遷移我們是要做一個什麼樣的事情呢？先看這張圖：
之前單機房架構部署在機房A內，遷移之後仍然是單機房架構，只是換了一個B機房，做完這個遷移，有什麼好的方案？最容易想到的一個方案，把所有服務在新機房全部搭一套，然後流量切過來了。
當系統有幾千臺機器，有非常非常多的業務的時候，這是一種“不成功便成仁”的方案。做技術的都知道，設計時要考慮回滾方案，如果只有上線方案而沒有回滾方案，這便是一個“不成功便成仁”的方案，根據經驗，不成功便成仁的操作結果，往往就“便成仁”了。
最重要的是，全量搭建一套再流量切換，數據層你怎麼搭建一套？怎麼切？數據層原來都在A機房，B機房還沒有全量的數據，是沒辦法直接切的。要做一個數據同步的方案，最簡單的，停兩個小時服務，把數據從舊機房導到新機房，數據導完流量再切過去，這是一個數據遷移的簡單方案。這個方案對業務有影響，需要停止服務，這個是無法接受的，何況像58同城一樣有兩千多臺機器，無限多的數據庫實例，無限多的數據表的時候，停服務遷移數據根本是不可能的。
所以，機房遷移的難點，是“平滑”遷移，整個過程不停服務，整體遷移方案的目標是：
（1）可以分批遷移；
（2）隨時可以回滾；
（3）平滑遷移，不停服務；
“僞多機房架構-同連”
如果想要平滑的遷移機房，不停服務，在10個月的逐步遷移過程中，肯定存在一箇中間過渡階段，兩邊機房都有流量，兩邊機房都對外提供服務，這就是一個多機房的架構了。
多機房架構是什麼樣的架構呢？剛剛提到了單機房架構，上層連中層，中層連下層，它是一個全連的架構，能不能直接將單機房的全連架構套用到多機房呢？在另一個機房部署好站點層、服務層、數據層，直接使用“全連”的單機房架構，我們會發現：會有非常多跨機房的連接
（1）站點層連接業務服務層，一半的請求跨機房
（2）業務服務層連接基礎服務層，一半的請求跨機房
（3）基礎服務層連數據層（例如從庫），一半的請求跨機房
大量的跨機房連接會帶來什麼樣的問題呢？
我們知道，同機房連接，內網的性能損耗幾乎可以忽略不計，但是一旦涉及到跨機房的訪問，即使機房和機房之間有專線，訪問的時延可能增加到幾毫秒（跟幾房間光纖距離有關）。
用戶訪問一個動態頁面，需要用到很多數據，這些數據可能需要10次的業務服務層調用，業務服務層可能又有若干次基礎服務層的調用，基礎服務層可能又有若干次數據層的調用，假設整個過程中有20次調用，其中有一半調用跨機房，假設機房之間延遲是5毫秒，因爲跨機房調用導致的請求遲延就達到了50毫秒，這個是不能接受的。
因此，在多機房架構設計時，要儘量避免跨機房調用（避免跨機房調用做不到，也要做到“最小化”跨機房調用），會使用“同連”的系統架構。
“同連”也很好理解，在非必須的情況下，優先連接同機房的站點與服務：
（1）站點層只連接同機房的業務服務層；
（2）業務服務層只連接同機房的基礎服務層；
（3）服務層只連接同機房的“讀”庫；
（4）對於寫庫，沒辦法，只有跨機房讀“寫”庫了；
這個方案沒有完全避免跨機房調用，但其實它做到了“最小化”跨機房調用，寫主庫是需要跨機房的。但互聯網的業務，99%都是讀多寫少的業務，例如百度的搜索100%是讀業務，京東淘寶的電商99%的瀏覽搜索是讀業務，只有下單支付是寫業務，58同城99%帖子的列表詳情查看是讀業務，發佈帖子是寫業務，寫業務比例相對少，只有這一部分請求會跨機房調用。
遷移機房的過程使用這樣一個多機房的架構，最大的好處就是，除了“配置文件”，整個單機房的架構不需要做任何修改，這個優點是很誘人的，所有的技術部門，所有的業務線，只需要配合在新機房部署應用與服務（數據庫是DBA統一部署的），然後使用不同的配置文件（如果有配置中心，這一步都省了），就能實現這個遷移過程，大大簡化了遷移步驟。
這個方案當然也有它的不足：
（1）跨機房同步數據，會多5毫秒（舉個栗子，不要叫真這個數值）延時（主從本來會有延時，這個延時會增大），這個影響的是某一個機房的數據讀取；
（2）跨機房寫，會多5毫秒延時，這個影響的是某一個機房的數據寫入，當然這個寫請求比例是很小的；
這個“同連”架構非常適用於做機房遷移，當然也可以用作多機房架構，用作多機房架構時，還有一個缺點：這個架構有“主機房”和“從機房”的區分。
多機房架構的本意是容機房故障，這個架構當出現機房故障時，例如一個機房地震了，把入口處流量切到另一個機房就能容錯，不過：
（1）掛掉的是不包含數據庫主庫的從機房，遷移流量後直接容錯；
（2）掛掉的是包含數據庫主庫的主機房，只遷移流量，其實系統整體99%的讀請求可以容錯，但1%的寫請求其實會受到影響，此時需要人工介入，將從庫變爲主庫，才能完全容錯。這個過程只需要DBA介入，不需要所有業務線上遊修改（除非，除非，業務線直接使用的IP連接，這個，我就不說什麼了）。
也正是因爲這個原因，在機房故障的時候，有一定概率需要少量人工介入，才能容100%的機房故障，因此這個架構才被稱爲“僞多機房架構”，還不是完全的“多機房多活”架構。
“自頂向下的機房遷移方案”
話題收回來，機房遷移的過程中，一定存在一箇中間過渡階段，兩邊機房都有流量，兩邊機房都對外提供服務的多機房架構。具體到機房的逐步遷移，又是個什麼步驟呢？通常有兩種方案，一種是自頂向下的遷移，一種是自底向上的遷移，這兩種方案在58到家和58同城分別實行過，都是可行的，方案有類似的地方，也有很多細節不一樣，因爲時間關係展開說一種，在58到家實施過的“自頂向下”的機房遷移方案，整個過程是平滑的，逐步遷移的，可回滾的，對業務無影響的。
“站點與服務的遷移”
遷移之前當然要做一些提前準備，新機房要準備就緒，專線要準備就緒，這個是前提。
自頂向下的的遷移，最先遷移站點層和服務層：先在新機房，把站點層和服務層搭建好，並做充分的測試（此時數據層比如說緩存和數據庫還是在原來的機房）。測試，測試，測試，只要流量沒有遷移，在新機房想怎麼玩都行，新機房準備的過程中，要注意“同連”，原有機房的配製文件是完全不動的，肯定也是“同連”。
站點層與服務層的遷移，也是一個業務一個業務的逐步遷移的，類似螞蟻搬家。充分的測試完一個業務的站點層和服務層之後，爲了求穩，先切1%的流量到新機房，觀察新機房的站點與服務有沒有異常，沒有問題的話，再5%，10%，20%，50%，100%的逐步放量，直至第一波螞蟻搬完家。
第一個業務的站點和服務遷移完之後，第二個業務、第三個業務，螞蟻繼續搬家，直至所有的業務把站點層和服務層都全流量的遷移到新機房。
在整個遷移的過程中，任何一個業務，任何時間點發現有問題，可以將流量切回，舊機房的站點、服務、配置都沒有動過，依然能提供服務。整個遷移步驟，是比較保險的，有問題隨時可以遷回來。
“緩存的遷移”
站點層和服務層遷移完之後，接下來我們遷數據層，數據層又分爲緩存層和數據庫層，先遷緩存。
經過第一步的遷移，所有的入口流量都已經遷到了新的機房（當然舊機房的站點和服務還是不能停，只要舊機房不停，任何時間點出問題，最壞的情況下流量遷回來），接下來遷移緩存，先在新機房要搭建好緩存，緩存的規模和體量與舊機房一樣大。
流程上仍然是螞蟻搬家，按照業務線逐步的遷緩存，使用同連的方式。這個緩存切換的步驟非常的簡單：運維做一個緩存內網DNS的切換（內網域名不變，IP切到新機房），並殺掉原有緩存連接，業務線不需要做任何修改，只需要配合觀察服務。運維殺掉原有緩存連接之後，程序會自動重連，重連上的緩存就是新機房的緩存了，bingo，遷移完畢。
這裏要注意幾個點：
（1）有些公司緩存沒有使用內網域名，而是採用IP直連的話，則需要業務層配合，換新機房IP重啓一下即可（如果是IP直連，說明這個架構還有改進的空間喲）；
（2）這個操作儘量選在流量低峯期，舊緩存中都是熱數據，而新緩存是空數據，如果選在流量高峯期，緩存切換之後，短時間內可能會有大量請求透傳到數據庫上去，導致數據庫壓力過大；
（3）這個通用步驟，適用於允許cache miss的業務場景，如果業務對緩存有高可用的要求，不允許cache miss，則需要雙寫緩存，或者緩存使用主從同步的架構。大部分緩存的業務場景都是允許cache miss的，少數特殊業務使用特殊的方案遷移。
緩存的遷移也是按照業務線，一步步螞蟻搬家式完成的。在遷移過程中，任何一個業務，任何時間點發現有問題，可以將流量切回原來的緩存。所以遷移的過程中，不僅是站點層和服務層，舊機房的緩存層也是不停服務的，至少保證了流量遷回這個兜底方案。
“數據庫的遷移”
站點層，服務層，緩存層都遷移完之後，最後是數據庫的遷移。
數據庫還是在舊機房，其他的緩存，服務，站點都遷移到新機房了，服務通過專線跨機房連數據庫。
如何進行數據庫遷移呢，首先肯定是在新機房搭建新的數據庫，如果是自建的IDC機房，需要自己搭建數據庫實例，58到家直接用的是阿里雲的RDS。
搭建好數據庫之後，接下來進行數據同步，自建機房可以使用數據庫MM/MS架構同步，阿里雲可以使用DTS同步，DTS同步有一個大坑，只能使用公網進行同步，但問題也不大，只是同步的時間比較長（不知道現能通過專線同步數據了嗎？）。
數據庫同步完之後，如何進行切換和遷移呢？能不能像緩存的遷移一樣，運維改一個數據庫內網DNS指向，然後切斷數據庫連接，讓服務重連新的數據庫，這樣業務服務不需要改動，也不需要重啓，這樣可以麼？
這個方式看上去很不錯，但數據庫的遷移沒有那麼理想：
第一，得保證數據庫同步完成，才能切流量，但數據同步總是有遲延的，舊機房一直在不停的寫如數據，何時纔算同步完成呢？
第二，只有域名和端口不發生變化，才能不修改配置完成切換，但如果域名和端口（主要是端口）發生變化，是做不到不修改配置和重啓的。舉個例子，假設原有數據庫實例端口用了5858，很吉利，而阿里雲要求你使用3200，就必須改端口重啓。
所以，我們最終的遷移方案，是DBA在舊機房的數據庫設置一個read only，停止數據的寫入，在秒級別，RDS同步完成之後，業務線修改數據庫端口，重啓連接新機房的數據庫，完成數據層的切換。
經過上述站點、服務、緩存、數據庫的遷移，我們的平滑機房的目標就這麼一步步完成啦。
總結與問答
四十分鐘很短，focus講了幾個點，希望大家有收穫。
做個簡要的總結：
（1）互聯網單機房架構的特點，全連，站點層全連業務服務層，業務服務層全連的基礎服務層，基礎服務層全連數據庫和緩存；
（2）多機房架構的特點，同連，接入層同連服務層，服務層同連緩存和數據庫，架構設計上最大程度的減少跨機房的調用；
（3）自頂向下的機房遷移方案：先進行站點接入層、業務服務層和基礎服務層的遷移，搭建服務，逐步的遷移流量；然後是緩存遷移，搭建緩存，運維修改緩存的內網DNS指向，斷開舊連接，重連新緩存，完成遷移；最後數據庫的遷移，搭建數據庫，數據進行同步，只讀，保證數據同步完成之後，修改配置，重啓，完成遷移。整個過程分批遷移，一個業務線一個業務線的遷移，一塊緩存一塊緩存的遷移，一個數據庫一個數據庫的遷移，任何步驟出現問題是可以回滾的，整個過程不停服務。
主持人：講的很細緻，大家有什麼問題嗎，可以提一些問題，可以舉手示意我。
提問：做數據遷移的時候，因爲您講的數據中心的都是在同一個老機房，同時又在做同步，我就在想這個數據庫的壓力是不是特別大。
沈劍：非常好的問題，這個地方一方面要考慮壓力，更重要的是考慮跨機房的專線，風險最大的是在帶寬這一部分，你在第一步遷移完之後，其實所有的緩存，數據庫用其實都是跨機房的，都是通過專線去走的，這個專線帶寬是需要重點考慮與評估的，數據庫的壓力其實還好。
提問：我想請教一個問題，你這個流量切換的過程中，有測試性的階段還是直接切過去的。
沈劍：在切流量之前，肯定是有測試的，在新機房將服務搭建，在切換流量之前，測試的同學需要進行迴歸，迴歸的過程可以提前發現很多問題。逐步的切流量也是爲了保證可靠性，我們不是一次性百分之百流量都切過來，先切1%的流量過來，觀察服務沒有問題，再逐步增大流量切換。
主持人：上午先到這裏，也歡迎大家關注沈老師的“架構師之路”微信公衆號，下午我們準時開始，大家注意好休息時間，謝謝大家。