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