近期阿里巴巴的同學(xué)分享了阿里在“異地雙活”（微博稱“多機(jī)房部署”，為便于理解本文統(tǒng)稱“異地多活”）的一些經(jīng)驗(yàn)（ http://www.infoq.com/cn/articles/interview-alibaba-bixuan ），由于我曾代表平臺(tái)在2012年主導(dǎo)微博的廣州機(jī)房部署項(xiàng)目以及北京雙機(jī)房部署項(xiàng)目，也分享一下微博在多機(jī)房部署方面的一些心得和踩過(guò)的坑。
異地多活的好處阿里同學(xué)已經(jīng)充分闡述，微博的初始出發(fā)點(diǎn)包括異地災(zāi)備、提升南方電信用戶訪問(wèn)速度、提升海外用戶訪問(wèn)速度、降低部署成本（北京機(jī)房機(jī)架費(fèi)太貴了）等。通過(guò)實(shí)踐發(fā)現(xiàn)優(yōu)勢(shì)包括異地容災(zāi)、動(dòng)態(tài)加速、流量均衡、在線壓測(cè)等，而挑戰(zhàn)包括增加研發(fā)復(fù)雜度、存儲(chǔ)成本增加等。
微博外部歷程
先說(shuō)說(shuō)微博外部的歷程，整個(gè)過(guò)程可謂是一波多折。微博的主要機(jī)房都集中在北京，只有很小一部分業(yè)務(wù)在廣州部署，2010年10月因微博高速發(fā)展準(zhǔn)備擴(kuò)大廣州機(jī)房服務(wù)器規(guī)模，并對(duì)微博做異地雙活部署。第一版跨機(jī)房消息同步方案采取的是基于自研的MytriggerQ（借助MySQL從庫(kù)的觸發(fā)器將INSERT、UPDATE、DELETE等事件轉(zhuǎn)為消息）的方案，這個(gè)方案的好處是跨機(jī)房的消息同步通過(guò)MySQL的主從完成的，方案的成熟度高。而缺點(diǎn)則是，微博同一個(gè)業(yè)務(wù)會(huì)有好幾張表，而每張表的信息又不全，這樣每發(fā)一條微博會(huì)有多條消息先后到達(dá)，這樣導(dǎo)致有較多時(shí)序問(wèn)題，緩存容易花。第一套方案未能成功，但也讓我們認(rèn)識(shí)了跨機(jī)房消息同步的核心問(wèn)題，并促使我們?nèi)嫦戮�MytriggerQ的消息同步方案，而改用基于業(yè)務(wù)寫消息到MCQ（MemcacheQ，新浪自研的一套消息隊(duì)列，類MC協(xié)議，參見(jiàn) http://memcachedb.org/memcacheq/ ）的解決方案。
2011年底在微博平臺(tái)化完成后，開(kāi)始啟用基于MCQ（微博自研的消息隊(duì)列）的跨機(jī)房消息同步方案，并開(kāi)發(fā)出跨機(jī)房消息同步組件WMB（Weibo Message Broker）。經(jīng)過(guò)與微博PC端等部門同學(xué)的共同努力，終于在2012年5月完成Weibo.com在廣州機(jī)房的上線，實(shí)現(xiàn)了“異地雙活”。
由于廣州機(jī)房總體的機(jī)器規(guī)模較小，為了提升微博核心系統(tǒng)容災(zāi)能力，2013年年中我們又將北京的機(jī)房進(jìn)行拆分，至此微博平臺(tái)實(shí)現(xiàn)了異地三節(jié)點(diǎn)的部署模式。依托于此模式，微博具備了在線容量評(píng)估、分級(jí)上線、快速流量均衡等能力，應(yīng)對(duì)極端峰值能力和應(yīng)對(duì)故障能力大大提升，之后歷次元旦、春晚峰值均順利應(yīng)對(duì)，日常上線導(dǎo)致的故障也大大減少。上線后，根據(jù)微博運(yùn)營(yíng)情況及成本的需要，也曾數(shù)次調(diào)整各個(gè)機(jī)房的服務(wù)器規(guī)模，但是整套技術(shù)上已經(jīng)基本成熟。
異地多活面臨的挑戰(zhàn)
根據(jù)微博的實(shí)踐，一般做異地多活都會(huì)遇到如下的問(wèn)題：
機(jī)房之間的延時(shí)：微博北京的兩個(gè)核心機(jī)房間延時(shí)在1ms左右，但北京機(jī)房到廣州機(jī)房則有近40ms的延時(shí)。對(duì)比一下，微博核心Feed接口的總平均耗時(shí)也就在120ms左右。微博Feed會(huì)依賴幾十個(gè)服務(wù)上百個(gè)資源，如果都跨機(jī)房請(qǐng)求，性能將會(huì)慘不忍睹；
專線問(wèn)題：為了做廣州機(jī)房外部，微博租了兩條北京到廣州的專線，成本巨大。同時(shí)單條專線的穩(wěn)定性也很難保障，基本上每個(gè)月都會(huì)有或大或小的問(wèn)題；
數(shù)據(jù)同步問(wèn)題：MySQL如何做數(shù)據(jù)同步？HBase如何做數(shù)據(jù)同步？還有各種自研的組件，這些統(tǒng)統(tǒng)要做多機(jī)房數(shù)據(jù)同步。幾十毫秒的延時(shí)，加上路途遙遠(yuǎn)導(dǎo)致的較弱網(wǎng)絡(luò)質(zhì)量（我們的專線每個(gè)月都會(huì)有或大或小的問(wèn)題），數(shù)據(jù)同步是非常大的挑戰(zhàn)；
依賴服務(wù)部署問(wèn)題：如同阿里目前只做了交易單元的“異地雙活”，微博部署時(shí)也面臨核心服務(wù)過(guò)多依賴小服務(wù)的問(wèn)題。將小服務(wù)全部部署改造成本、維護(hù)成本過(guò)大，不部署則會(huì)遇到之前提到的機(jī)房之間延時(shí)導(dǎo)致整體性能無(wú)法接受的問(wèn)題；
配套體系問(wèn)題：只是服務(wù)部署沒(méi)有流量引入就不能稱為“雙活”，而要引入流量就要求配套的服務(wù)和流程都能支持異地部署，包括預(yù)覽、發(fā)布、測(cè)試、監(jiān)控、降級(jí)等都要進(jìn)行相應(yīng)改造；
微博異地多活解決方案
由于幾十毫秒的延時(shí)，跨機(jī)房服務(wù)調(diào)用性能很差，異地多活部署的主體服務(wù)必須要做數(shù)據(jù)的冗余存儲(chǔ)，并輔以緩存等構(gòu)成一套獨(dú)立而相對(duì)完整的服務(wù)。數(shù)據(jù)同步有很多層面，包括消息層面、緩存層面、數(shù)據(jù)庫(kù)層面，每一個(gè)層面都可以做數(shù)據(jù)同步。由于基于MytriggerQ的方案的失敗，微博后來(lái)采取的是基于MCQ的WMB消息同步方案，并通過(guò)消息對(duì)緩存更新，加上微博緩存高可用架構(gòu)，可以做到即便數(shù)據(jù)庫(kù)同步有問(wèn)題從用戶體驗(yàn)看服務(wù)還是正常的。
這套方案中，每個(gè)機(jī)房的緩存是完全獨(dú)立的，由每個(gè)機(jī)房的Processor（專門負(fù)責(zé)消息處理的程序，類Storm）根據(jù)收到的消息進(jìn)行緩存更新。由于消息不會(huì)重復(fù)分發(fā)，而且信息完備，所以MytriggerQ方案存在的緩存更新臟數(shù)據(jù)問(wèn)題就解決了。而當(dāng)緩存不存在時(shí)，會(huì)穿透到MySQL從庫(kù)，然后進(jìn)行回種�？赡艹霈F(xiàn)的問(wèn)題是，緩存穿透，但是MySQL從庫(kù)如果此時(shí)出現(xiàn)延遲，這樣就會(huì)把臟數(shù)據(jù)種到緩存中。我們的解決方案是做一個(gè)延時(shí)10分鐘的消息隊(duì)列，然后由一個(gè)處理程序來(lái)根據(jù)這個(gè)消息做數(shù)據(jù)的重新載入。一般從庫(kù)延時(shí)時(shí)間不超過(guò)10分鐘，而10分鐘內(nèi)的臟數(shù)據(jù)在微博的業(yè)務(wù)場(chǎng)景下也是可以接受的。
微博的異地多活方案如下圖（三個(gè)節(jié)點(diǎn)類似，消息同步都是通過(guò)WMB）：
跟阿里同學(xué)遇到的問(wèn)題類似，我們也遇到數(shù)據(jù)庫(kù)同步的問(wèn)題。由于微博對(duì)數(shù)據(jù)庫(kù)不是強(qiáng)依賴，加上數(shù)據(jù)庫(kù)雙寫的維護(hù)成本過(guò)大，我們選擇的方案是數(shù)據(jù)庫(kù)通過(guò)主從同步的方式進(jìn)行。這套方案可能的缺點(diǎn)是如果主從同步慢，并且緩存穿透，這時(shí)可能會(huì)出現(xiàn)臟數(shù)據(jù)。這種同步方式已運(yùn)行了三年，整體上非常穩(wěn)定，沒(méi)有發(fā)生因?yàn)閿?shù)據(jù)同步而導(dǎo)致的服務(wù)故障。從2013年開(kāi)始，微博啟用HBase做在線業(yè)務(wù)的存儲(chǔ)解決方案，由于HBase本身不支持多機(jī)房部署，加上早期HBase的業(yè)務(wù)比較小，且有單獨(dú)接口可以回調(diào)北京機(jī)房，所以沒(méi)有做異地部署。到今年由于HBase支撐的對(duì)象庫(kù)服務(wù)已經(jīng)成為微博非常核心的基礎(chǔ)服務(wù)，我們也在規(guī)劃HBase的異地部署方案，主要的思路跟MySQL的方案類似，同步也在考慮基于MCQ同步的雙機(jī)房HBase獨(dú)立部署方案。
阿里選擇了單元化的解決方案，這套方案的優(yōu)勢(shì)是將用戶分區(qū)，然后所有這個(gè)用戶相關(guān)的數(shù)據(jù)都在一個(gè)單元里。通過(guò)這套方案，可以較好的控制成本。但缺點(diǎn)是除了主維度（阿里是買家維度），其他所有的數(shù)據(jù)還是要做跨機(jī)房同步，整體的復(fù)雜度基本沒(méi)降低。另外就是數(shù)據(jù)分離后由于拆成了至少兩份數(shù)據(jù)，數(shù)據(jù)查詢、擴(kuò)展、問(wèn)題處理等成本均會(huì)增加較多�？偟膩�(lái)講，個(gè)人認(rèn)為這套方案更適用于WhatSAPp、Instagram等國(guó)外業(yè)務(wù)相對(duì)簡(jiǎn)單的應(yīng)用，而不適用于國(guó)內(nèi)功能繁雜依賴眾多的應(yīng)用。
數(shù)據(jù)同步問(wèn)題解決之后，緊接著就要解決依賴服務(wù)部署的問(wèn)題。由于微博平臺(tái)對(duì)外提供的都是Restful風(fēng)格的API接口，所以獨(dú)立業(yè)務(wù)的接口可以直接通過(guò)專線引流回北京機(jī)房。但是對(duì)于微博Feed接口的依賴服務(wù)，直接引流回北京機(jī)房會(huì)將平均處理時(shí)間從百毫秒的量級(jí)直接升至幾秒的量級(jí)，這對(duì)服務(wù)是無(wú)法接受的。所以，在2012年我們對(duì)微博Feed依賴的主要服務(wù)也做了異地多活部署，整體的處理時(shí)間終于降了下來(lái)。當(dāng)然這不是最優(yōu)的解決方案，但在當(dāng)時(shí)微博業(yè)務(wù)體系還相對(duì)簡(jiǎn)單的情況下很好的解決了問(wèn)題，確保了2012年5月的廣州機(jī)房部署任務(wù)的達(dá)成。
而配套體系的問(wèn)題，技術(shù)上不是很復(fù)雜，但是操作的時(shí)候缺很容易出問(wèn)題。比如，微博剛開(kāi)始做異地多活部署時(shí)，測(cè)試同學(xué)沒(méi)有在上線時(shí)對(duì)廣州機(jī)房做預(yù)覽測(cè)試，曾經(jīng)導(dǎo)致過(guò)一些線上問(wèn)題。配套體系需要覆蓋整個(gè)業(yè)務(wù)研發(fā)周期，包括方案設(shè)計(jì)階段的是否要做多機(jī)房部署、部署階段的數(shù)據(jù)同步、發(fā)布預(yù)覽、發(fā)布工具支持、監(jiān)控覆蓋支持、降級(jí)工具支持、流量遷移工具支持等方方面面，并需開(kāi)發(fā)、測(cè)試、運(yùn)維都參與進(jìn)來(lái)，將關(guān)鍵點(diǎn)納入到流程當(dāng)中。
關(guān)于為應(yīng)對(duì)故障而進(jìn)行數(shù)據(jù)冗余問(wèn)題，阿里的同學(xué)也做了充分的闡述，在此也補(bǔ)充一下我們的一些經(jīng)驗(yàn)。微博核心池容量冗余分兩個(gè)層面來(lái)做，前端Web層冗余同用戶規(guī)模成正比，并預(yù)留日常峰值50%左右的冗余度，而后端緩存等資源由于相對(duì)成本較低，每個(gè)機(jī)房均按照整體兩倍的規(guī)模進(jìn)行冗余。這樣如果某一個(gè)機(jī)房不可用，首先我們后端的資源是足夠的。接著我們首先會(huì)只將核心接口進(jìn)行遷移，這個(gè)操作分鐘級(jí)即可完成，同時(shí)由于冗余是按照整體的50%，所以即使所有的核心接口流量全部遷移過(guò)來(lái)也能支撐住。接下來(lái)，我們將會(huì)把其他服務(wù)池的前端機(jī)也改為部署核心池前端機(jī)，這樣在一小時(shí)內(nèi)即可實(shí)現(xiàn)整體流量的承接。同時(shí)，如果故障機(jī)房是負(fù)責(zé)數(shù)據(jù)落地的機(jī)房，DBA會(huì)將從庫(kù)升為主庫(kù)，運(yùn)維調(diào)整隊(duì)列機(jī)開(kāi)關(guān)配置，承接數(shù)據(jù)落地功能。而在整個(gè)過(guò)程中，由于我們核心緩存可以脫離數(shù)據(jù)庫(kù)支撐一個(gè)小時(shí)左右，所以服務(wù)整體會(huì)保持平穩(wěn)。
異地多活最好的姿勢(shì)
以上介紹了一下微博在異地多活方面的實(shí)踐和心得，也對(duì)比了一下阿里的解決方案。就像沒(méi)有完美的通用架構(gòu)一樣，異地多活的最佳方案也要因業(yè)務(wù)情形而定。如果業(yè)務(wù)請(qǐng)求量比較小，則根本沒(méi)有必要做異地多活，數(shù)據(jù)庫(kù)冷備足夠了。不管哪種方案，異地多活的資源成本、開(kāi)發(fā)成本相比與單機(jī)房部署模式都會(huì)大大增加。
以下是方案選型時(shí)需要考慮的一些維度：
能否整業(yè)務(wù)遷移：如果機(jī)器資源不足，建議優(yōu)先將一些體系獨(dú)立的服務(wù)整體遷移，這樣可以為核心服務(wù)節(jié)省出大量的機(jī)架資源。如果這樣之后，機(jī)架資源仍然不足，再做異地多活部署；
服務(wù)關(guān)聯(lián)是否復(fù)雜：如果服務(wù)關(guān)聯(lián)比較簡(jiǎn)單，則單元化、基于跨機(jī)房消息同步的解決方案都可以采用。不管哪種方式，關(guān)聯(lián)的服務(wù)也都要做異地多活部署，以確保各個(gè)機(jī)房對(duì)關(guān)聯(lián)業(yè)務(wù)的請(qǐng)求都落在本機(jī)房?jī)?nèi)；
是否方便對(duì)用戶分區(qū)：比如很多游戲類、郵箱類服務(wù)由于用戶可以很方便分區(qū)就非常適合單元化，而SNS類的產(chǎn)品因?yàn)殛P(guān)系公用等問(wèn)題不太適合單元化；
謹(jǐn)慎挑選第二機(jī)房：盡量挑選離主機(jī)房較近（網(wǎng)絡(luò)延時(shí)在10ms以內(nèi)）且專線質(zhì)量好的機(jī)房做第二中心。這樣大多數(shù)的小服務(wù)依賴問(wèn)題都可以簡(jiǎn)化掉，可以集中精力處理核心業(yè)務(wù)的異地雙活問(wèn)題。同時(shí)，專線的成本占比也比較小。以北京為例，做異地多活建議選擇天津、內(nèi)蒙古、山西等地的機(jī)房；
控制部署規(guī)模：在數(shù)據(jù)層自身支持跨機(jī)房服務(wù)之前，不建議部署超過(guò)兩個(gè)的機(jī)房。因?yàn)楫惖貎蓚�(gè)機(jī)房，異地容災(zāi)的目的已經(jīng)達(dá)成，且服務(wù)器規(guī)模足夠大各種配套的設(shè)施也會(huì)比較健全，運(yùn)維成本也相對(duì)可控。當(dāng)擴(kuò)展到三個(gè)點(diǎn)之后，新機(jī)房基礎(chǔ)設(shè)施磨合、運(yùn)維決策的成本等都會(huì)大幅增加；
消息同步服務(wù)化：建議擴(kuò)展各自的消息服務(wù)，從中間件或者服務(wù)層面直接支持跨機(jī)房消息同步，將消息體大小控制在10k以下，跨機(jī)房消息同步的性能和成本都比較可控。機(jī)房間的數(shù)據(jù)一致性只通過(guò)消息同步服務(wù)解決，機(jī)房?jī)?nèi)部解決緩存等與消息的一致性問(wèn)題�？鐧C(jī)房消息同步的核心點(diǎn)在于消息不能丟，微博由于使用的是MCQ，通過(guò)本地寫遠(yuǎn)程讀的方式，可以很方便的實(shí)現(xiàn)高效穩(wěn)定的跨機(jī)房消息同步；
異地多活的新方向
時(shí)間到了2015年，新技術(shù)層出不窮，之前很多成本很高的事情目前都有了很好的解決方案。接下來(lái)我們將在近五年異地多活部署探索的基礎(chǔ)上，繼續(xù)將微博的異地多活部署體系化。
升級(jí)跨機(jī)房消息同步組件為跨機(jī)房消息同步服務(wù)。面向業(yè)務(wù)隔離跨機(jī)房消息同步的復(fù)雜性，業(yè)務(wù)只需要對(duì)消息進(jìn)行處理即可，消息的跨機(jī)房分發(fā)、一致性等由跨機(jī)房同步服務(wù)保障。且可以作為所有業(yè)務(wù)跨機(jī)房消息同步的專用通道，各個(gè)業(yè)務(wù)均可以復(fù)用，類似于快遞公司的角色。
推進(jìn)Web層的異地部署。由于遠(yuǎn)距離專線成本巨大且穩(wěn)定性很難保障，我們已暫時(shí)放棄遠(yuǎn)程異地部署，而改為業(yè)務(wù)邏輯近距離隔離部署，將Web層進(jìn)行遠(yuǎn)程異地部署。同時(shí)，計(jì)劃不再依賴昂貴且不穩(wěn)定的專線，而借助于通過(guò)算法尋找較優(yōu)路徑的方法通過(guò)公網(wǎng)進(jìn)行數(shù)據(jù)傳輸。這樣我們就可以將Web層部署到離用戶更近的機(jī)房，提升用戶的訪問(wèn)性能。依據(jù)我們?nèi)ツ曜鑫⒉〧eed全鏈路的經(jīng)驗(yàn)，中間鏈路占掉了90%以上的用戶訪問(wèn)時(shí)間，將Web層部署的離用戶更近將能大大提升用戶訪問(wèn)性能和體驗(yàn)。
借助微服務(wù)解決中小服務(wù)依賴問(wèn)題。將對(duì)資源等的操作包裝為微服務(wù)，并將中小業(yè)務(wù)遷移到微服務(wù)架構(gòu)。這樣只需要對(duì)幾個(gè)微服務(wù)進(jìn)行異地多活部署改造，眾多的中小業(yè)務(wù)就不再需要關(guān)心異地部署問(wèn)題，從而可以低成本完成眾多中小服務(wù)的異地多活部署改造。
利用Docker提升前端快速擴(kuò)容能力。借助Docker的動(dòng)態(tài)擴(kuò)容能力，當(dāng)流量過(guò)大時(shí)分鐘級(jí)從其他服務(wù)池摘下一批機(jī)器，并完成本服務(wù)池的擴(kuò)容。之后也可以將各種資源也納入到Docker動(dòng)態(tài)部署的范圍，進(jìn)一步擴(kuò)大動(dòng)態(tài)調(diào)度的機(jī)器源范圍。
以上是對(duì)微博異地多活部署的一些總結(jié)和思考，希望能夠?qū)Υ蠹矣兴鶈l(fā)。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標(biāo)題：“異地多活”多機(jī)房部署經(jīng)驗(yàn)談
本文網(wǎng)址：http://www.oesoe.com/html/consultation/10839418255.html
相關(guān)文章
