異地多活的好處阿里巴巴的同學(xué)已經(jīng)充分闡述，微博的初始出發(fā)點(diǎn)包括異地災(zāi)備筷登、提升南方電信用戶訪問速度欧募、提升海外用戶訪問速度、降低部署成本（北京機(jī)房機(jī)架費(fèi)太貴了）等仆抵。通過實踐，我們發(fā)現(xiàn)優(yōu)勢還包括異地容災(zāi)种冬、動態(tài)加速镣丑、流量均衡、在線壓測等娱两，而挑戰(zhàn)包括增加研發(fā)復(fù)雜度莺匠、增加存儲成本等。

微博外部歷程

先說說微博外部的歷程十兢，整個過程可謂是一波多折趣竣。微博的主要機(jī)房都集中在北京，只有很小一部分業(yè)務(wù)在廣州部署旱物，2010年10月遥缕，因微博高速發(fā)展，所以準(zhǔn)備擴(kuò)大廣州機(jī)房服務(wù)器規(guī)模宵呛，并對微博做異地雙活部署单匣。

第一版跨機(jī)房消息同步方案采取的是基于自研的MytriggerQ（借助MySQL從庫的觸發(fā)器將INSERT、UPDATE、DELETE等事件轉(zhuǎn)為消息）的方案户秤，這個方案的好處是码秉，跨機(jī)房的消息同步是通過MySQL的主從完成的，方案成熟度高鸡号。而缺點(diǎn)則是转砖，微博同一個業(yè)務(wù)會有好幾張表，而每張表的信息又不全鲸伴，這樣每發(fā)一條微博會有多條消息先后到達(dá)府蔗，這樣導(dǎo)致有較多時序問題，緩存容易花挑围。

第一套方案未能成功礁竞，但也讓我們認(rèn)識到跨機(jī)房消息同步的核心問題，并促使我們?nèi)嫦戮€MytriggerQ的消息同步方案杉辙，而改用基于業(yè)務(wù)寫消息到MCQ（MemcacheQ模捂，新浪自研的一套消息隊列，類MC協(xié)議）的解決方案蜘矢。

2011年底在微博平臺化完成后狂男，開始啟用基于MCQ的跨機(jī)房消息同步方案，并開發(fā)出跨機(jī)房消息同步組件WMB（Weibo Message Broker）品腹。經(jīng)過與微博PC端等部門同學(xué)的共同努力岖食，終于在2012年5月完成Weibo.com在廣州機(jī)房的上線，實現(xiàn)了“異地雙活”舞吭。

由于廣州機(jī)房總體的機(jī)器規(guī)模較小泡垃，為了提升微博核心系統(tǒng)容災(zāi)能力，2013年年中我們又將北京的機(jī)房進(jìn)行拆分羡鸥，至此微博平臺實現(xiàn)了異地三節(jié)點(diǎn)的部署模式蔑穴。依托于此模式，微博具備了在線容量評估惧浴、分級上線存和、快速流量均衡等能力，應(yīng)對極端峰值能力和應(yīng)對故障能力大大提升衷旅，之后歷次元旦捐腿、春晚峰值均順利應(yīng)對，日常上線導(dǎo)致的故障也大大減少柿顶。上線后茄袖，根據(jù)微博運(yùn)營情況及成本的需要，也曾數(shù)次調(diào)整各個機(jī)房的服務(wù)器規(guī)模九串，但是整套技術(shù)上已經(jīng)基本成熟绞佩。????

異地多活面臨的挑戰(zhàn)

根據(jù)微博的實踐寺鸥，一般做異地多活都會遇到如下的問題：

機(jī)房之間的延時：微博北京的兩個核心機(jī)房間延時在1ms左右，但北京機(jī)房到廣州機(jī)房則有近40ms的延時品山。對比一下胆建，微博核心Feed接口的總平均耗時也就在120ms左右。微博Feed會依賴幾十個服務(wù)上百個資源肘交，如果都跨機(jī)房請求笆载，性能將會慘不忍睹；

專線問題：為了做廣州機(jī)房外部涯呻，微博租了兩條北京到廣州的專線凉驻，成本巨大。同時單條專線的穩(wěn)定性也很難保障复罐，基本上每個月都會有或大或小的問題涝登；

數(shù)據(jù)同步問題：MySQL如何做數(shù)據(jù)同步？HBase如何做數(shù)據(jù)同步效诅？還有各種自研的組件胀滚，這些統(tǒng)統(tǒng)要做多機(jī)房數(shù)據(jù)同步。幾十毫秒的延時乱投，加上路途遙遠(yuǎn)導(dǎo)致的較弱網(wǎng)絡(luò)質(zhì)量（我們的專線每個月都會有或大或小的問題）咽笼，數(shù)據(jù)同步是非常大的挑戰(zhàn)；

依賴服務(wù)部署問題：如同阿里巴巴目前只做了交易單元的“異地雙活”戚炫，微博部署時也面臨核心服務(wù)過多依賴小服務(wù)的問題剑刑。將小服務(wù)全部部署，改造成本双肤、維護(hù)成本過大施掏，不部署則會遇到之前提到的機(jī)房之間延時導(dǎo)致整體性能無法接受的問題；

配套體系問題：只是服務(wù)部署沒有流量引入就不能稱為“雙活”茅糜，而要引入流量就要求配套的服務(wù)和流程都能支持異地部署其监，包括預(yù)覽、發(fā)布限匣、測試、監(jiān)控毁菱、降級等都要進(jìn)行相應(yīng)改造米死。

微博異地多活解決方案

由于幾十毫秒的延時，跨機(jī)房服務(wù)調(diào)用性能很差贮庞，異地多活部署的主體服務(wù)必須要做數(shù)據(jù)的冗余存儲峦筒，并輔以緩存等構(gòu)成一套獨(dú)立而相對完整的服務(wù)。數(shù)據(jù)同步有很多層面窗慎，包括消息層面物喷、緩存層面卤材、數(shù)據(jù)庫層面，每一個層面都可以做數(shù)據(jù)同步峦失。由于基于MytriggerQ的方案的失敗扇丛，微博后來采取的是基于MCQ的WMB消息同步方案，并通過消息對緩存更新尉辑，加上微博緩存高可用架構(gòu)帆精，可以做到即便數(shù)據(jù)庫同步有問題，從用戶體驗看服務(wù)還是正常的隧魄。

這套方案中卓练，每個機(jī)房的緩存是完全獨(dú)立的，由每個機(jī)房的Processor（專門負(fù)責(zé)消息處理的程序购啄，類Storm）根據(jù)收到的消息進(jìn)行緩存更新襟企。由于消息不會重復(fù)分發(fā)，而且信息完備狮含，所以MytriggerQ方案存在的緩存更新臟數(shù)據(jù)問題就解決了顽悼。而當(dāng)緩存不存在時，會穿透到MySQL從庫辉川，然后進(jìn)行回種表蝙。可能出現(xiàn)的問題是乓旗，緩存穿透府蛇，但是MySQL從庫如果此時出現(xiàn)延遲，這樣就會把臟數(shù)據(jù)種到緩存中屿愚。我們的解決方案是做一個延時10分鐘的消息隊列汇跨，然后由一個處理程序來根據(jù)這個消息做數(shù)據(jù)的重新載入。一般從庫延時時間不超過10分鐘妆距，而10分鐘內(nèi)的臟數(shù)據(jù)在微博的業(yè)務(wù)場景下也是可以接受的穷遂。

微博的異地多活方案如下圖（三個節(jié)點(diǎn)類似，消息同步都是通過WMB）：

跟阿里巴巴遇到的問題類似娱据，我們也遇到了數(shù)據(jù)庫同步的問題蚪黑。由于微博對數(shù)據(jù)庫不是強(qiáng)依賴，加上數(shù)據(jù)庫雙寫的維護(hù)成本過大中剩，我們選擇的方案是數(shù)據(jù)庫通過主從同步的方式進(jìn)行忌穿。這套方案可能的缺點(diǎn)是如果主從同步慢，并且緩存穿透结啼，這時可能會出現(xiàn)臟數(shù)據(jù)掠剑。這種同步方式已運(yùn)行了三年，整體上非常穩(wěn)定郊愧，沒有發(fā)生因為數(shù)據(jù)同步而導(dǎo)致的服務(wù)故障朴译。從2013年開始井佑，微博啟用HBase做在線業(yè)務(wù)的存儲解決方案，由于HBase本身不支持多機(jī)房部署眠寿，加上早期HBase的業(yè)務(wù)比較小躬翁，且有單獨(dú)接口可以回調(diào)北京機(jī)房，所以沒有做異地部署澜公。到今年由于HBase支撐的對象庫服務(wù)已經(jīng)成為微博非常核心的基礎(chǔ)服務(wù)姆另，我們也在規(guī)劃HBase的異地部署方案，主要的思路跟MySQL的方案類似坟乾，同步也在考慮基于MCQ同步的雙機(jī)房HBase獨(dú)立部署方案迹辐。

阿里巴巴選擇了單元化的解決方案，這套方案的優(yōu)勢是將用戶分區(qū)甚侣，然后所有這個用戶相關(guān)的數(shù)據(jù)都在一個單元里明吩。通過這套方案，可以較好的控制成本殷费。但缺點(diǎn)是除了主維度（阿里巴巴是買家維度）印荔，其他所有的數(shù)據(jù)還是要做跨機(jī)房同步，整體的復(fù)雜度基本沒降低详羡。另外就是數(shù)據(jù)分離后由于拆成了至少兩份數(shù)據(jù)仍律，數(shù)據(jù)查詢、擴(kuò)展实柠、問題處理等成本均會增加較多水泉。總的來講窒盐，個人認(rèn)為這套方案更適用于WhatsApp草则、Instagram等國外業(yè)務(wù)相對簡單的應(yīng)用，而不適用于國內(nèi)功能繁雜蟹漓、依賴眾多的應(yīng)用炕横。

數(shù)據(jù)同步問題解決之后，緊接著就要解決依賴服務(wù)部署的問題葡粒。由于微博平臺對外提供的都是Restful風(fēng)格的API接口份殿，所以獨(dú)立業(yè)務(wù)的接口可以直接通過專線引流回北京機(jī)房。但是對于微博Feed接口的依賴服務(wù)嗽交，直接引流回北京機(jī)房會將平均處理時間從百毫秒的量級直接升至幾秒的量級伯铣，這對服務(wù)是無法接受的。所以轮纫，在2012年我們對微博Feed依賴的主要服務(wù)也做了異地多活部署灯抛，整體的處理時間終于降了下來表箭。當(dāng)然這不是最優(yōu)的解決方案紊册，但在當(dāng)時微博業(yè)務(wù)體系還相對簡單的情況下干奢，很好地解決了問題，確保了2012年5月的廣州機(jī)房部署任務(wù)的達(dá)成糯彬。

而配套體系的問題凭语，技術(shù)上不是很復(fù)雜，但是操作時卻很容易出問題撩扒。比如似扔，微博剛開始做異地多活部署時，測試同學(xué)沒有在上線時對廣州機(jī)房做預(yù)覽測試搓谆，曾經(jīng)導(dǎo)致過一些線上問題炒辉。配套體系需要覆蓋整個業(yè)務(wù)研發(fā)周期，包括方案設(shè)計階段的是否要做多機(jī)房部署泉手、部署階段的數(shù)據(jù)同步黔寇、發(fā)布預(yù)覽、發(fā)布工具支持斩萌、監(jiān)控覆蓋支持缝裤、降級工具支持、流量遷移工具支持等方方面面颊郎，并需開發(fā)憋飞、測試、運(yùn)維都參與進(jìn)來姆吭，將關(guān)鍵點(diǎn)納入到流程當(dāng)中榛做。

關(guān)于為應(yīng)對故障而進(jìn)行數(shù)據(jù)冗余的問題，阿里巴巴的同學(xué)也做了充分的闡述猾编，在此也補(bǔ)充一下我們的一些經(jīng)驗瘤睹。微博核心池容量冗余分兩個層面來做，前端Web層冗余同用戶規(guī)模成正比答倡，并預(yù)留日常峰值50%左右的冗余度轰传，而后端緩存等資源由于相對成本較低，每個機(jī)房均按照整體兩倍的規(guī)模進(jìn)行冗余瘪撇。這樣如果某一個機(jī)房不可用获茬，首先我們后端的資源是足夠的。接著我們首先會只將核心接口進(jìn)行遷移倔既，這個操作分鐘級即可完成恕曲，同時由于冗余是按照整體的50%，所以即使所有的核心接口流量全部遷移過來也能支撐住渤涌。接下來佩谣，我們會把其他服務(wù)池的前端機(jī)也改為部署核心池前端機(jī)，這樣在一小時內(nèi)即可實現(xiàn)整體流量的承接实蓬。同時茸俭，如果故障機(jī)房是負(fù)責(zé)數(shù)據(jù)落地的機(jī)房吊履，DBA會將從庫升為主庫，運(yùn)維調(diào)整隊列機(jī)開關(guān)配置调鬓，承接數(shù)據(jù)落地功能艇炎。而在整個過程中，由于我們核心緩存可以脫離數(shù)據(jù)庫支撐一個小時左右腾窝，所以服務(wù)整體會保持平穩(wěn)缀踪。

異地多活最好的姿勢

以上介紹了一下微博在異地多活方面的實踐和心得，也對比了一下阿里巴巴的解決方案虹脯。就像沒有完美的通用架構(gòu)一樣驴娃，異地多活的最佳方案也要因業(yè)務(wù)情形而定。如果業(yè)務(wù)請求量比較小归形，則根本沒有必要做異地多活托慨，數(shù)據(jù)庫冷備足夠了。不管哪種方案厚棵，異地多活的資源成本婆硬、開發(fā)成本相比與單機(jī)房部署模式彬犯，都會大大增加。????

以下是方案選型時需要考慮的一些維度：

能否整業(yè)務(wù)遷移：如果機(jī)器資源不足宋列，建議優(yōu)先將一些體系獨(dú)立的服務(wù)整體遷移，這樣可以為核心服務(wù)節(jié)省出大量的機(jī)架資源坤邪。如果這樣之后艇纺，機(jī)架資源仍然不足消约，再做異地多活部署。

服務(wù)關(guān)聯(lián)是否復(fù)雜：如果服務(wù)關(guān)聯(lián)比較簡單，則單元化硝岗、基于跨機(jī)房消息同步的解決方案都可以采用。不管哪種方式胀溺，關(guān)聯(lián)的服務(wù)也都要做異地多活部署，以確保各個機(jī)房對關(guān)聯(lián)業(yè)務(wù)的請求都落在本機(jī)房內(nèi)。

是否方便對用戶分區(qū)：比如很多游戲類嫉称、郵箱類服務(wù)，由于用戶可以很方便地分區(qū)蒲稳，就非常適合單元化江耀，而SNS類的產(chǎn)品因為關(guān)系公用等問題不太適合單元化。

謹(jǐn)慎挑選第二機(jī)房：盡量挑選離主機(jī)房較近（網(wǎng)絡(luò)延時在10ms以內(nèi)）且專線質(zhì)量好的機(jī)房做第二中心舌稀。這樣大多數(shù)的小服務(wù)依賴問題都可以簡化掉觉至，可以集中精力處理核心業(yè)務(wù)的異地多活問題。同時应闯，專線的成本占比也比較小。以北京為例骨田，做異地多活建議選擇天津、內(nèi)蒙古、山西等地的機(jī)房。

控制部署規(guī)模：在數(shù)據(jù)層自身支持跨機(jī)房服務(wù)之前姻采，不建議部署超過兩個的機(jī)房。因為異地兩個機(jī)房，異地容災(zāi)的目的已經(jīng)達(dá)成胡陪，且服務(wù)器規(guī)模足夠大，各種配套的設(shè)施也會比較健全妈经，運(yùn)維成本也相對可控鳄厌。當(dāng)擴(kuò)展到三個點(diǎn)之后，新機(jī)房基礎(chǔ)設(shè)施磨合、運(yùn)維決策的成本等都會大幅增加。

消息同步服務(wù)化：建議擴(kuò)展各自的消息服務(wù)伶氢，從中間件或者服務(wù)層面直接支持跨機(jī)房消息同步，將消息體大小控制在10k以下瘪吏，跨機(jī)房消息同步的性能和成本都比較可控癣防。機(jī)房間的數(shù)據(jù)一致性只通過消息同步服務(wù)解決，機(jī)房內(nèi)部解決緩存等與消息的一致性問題掌眠±俣ⅲ跨機(jī)房消息同步的核心點(diǎn)在于消息不能丟，微博由于使用的是MCQ蓝丙，通過本地寫遠(yuǎn)程讀的方式级遭，可以很方便的實現(xiàn)高效穩(wěn)定的跨機(jī)房消息同步。

異地多活的新方向

時間到了2015年渺尘，新技術(shù)層出不窮挫鸽，之前很多成本很高的事情目前都有了很好的解決方案。接下來我們將在近五年異地多活部署探索的基礎(chǔ)上沧烈，繼續(xù)將微博的異地多活部署體系化掠兄。

升級跨機(jī)房消息同步組件為跨機(jī)房消息同步服務(wù)。面向業(yè)務(wù)隔離跨機(jī)房消息同步的復(fù)雜性，業(yè)務(wù)只需要對消息進(jìn)行處理即可蚂夕，消息的跨機(jī)房分發(fā)迅诬、一致性等由跨機(jī)房同步服務(wù)保障。且可以作為所有業(yè)務(wù)跨機(jī)房消息同步的專用通道婿牍，各個業(yè)務(wù)均可以復(fù)用侈贷，類似于快遞公司的角色。

推進(jìn)Web層的異地部署等脂。由于遠(yuǎn)距離專線成本巨大且穩(wěn)定性很難保障俏蛮，我們已暫時放棄遠(yuǎn)程異地部署，而改為業(yè)務(wù)邏輯近距離隔離部署上遥，將Web層進(jìn)行遠(yuǎn)程異地部署搏屑。同時，計劃不再依賴昂貴且不穩(wěn)定的專線粉楚，而借助于通過算法尋找較優(yōu)路徑的方法通過公網(wǎng)進(jìn)行數(shù)據(jù)傳輸辣恋。這樣我們就可以將Web層部署到離用戶更近的機(jī)房，提升用戶的訪問性能模软。依據(jù)我們?nèi)ツ曜鑫⒉〧eed全鏈路的經(jīng)驗伟骨，中間鏈路占掉了90%以上的用戶訪問時間，將Web層部署的離用戶更近燃异，將能大大提升用戶訪問性能和體驗携狭。

借助微服務(wù)解決中小服務(wù)依賴問題。將對資源等的操作包裝為微服務(wù)回俐，并將中小業(yè)務(wù)遷移到微服務(wù)架構(gòu)逛腿。這樣只需要對幾個微服務(wù)進(jìn)行異地多活部署改造，眾多的中小業(yè)務(wù)就不再需要關(guān)心異地部署問題仅颇，從而可以低成本完成眾多中小服務(wù)的異地多活部署改造鳄逾。在這里提供一個大牛交流群：433540541，可以交流技術(shù)灵莲，相互學(xué)習(xí)雕凹，也可以找群主獲取免費(fèi)資料。

利用Docker提升前端快速擴(kuò)容能力政冻。借助Docker的動態(tài)擴(kuò)容能力枚抵，當(dāng)流量過大時分鐘級從其他服務(wù)池摘下一批機(jī)器，并完成本服務(wù)池的擴(kuò)容明场。之后可以將各種資源也納入到Docker動態(tài)部署的范圍汽摹，進(jìn)一步擴(kuò)大動態(tài)調(diào)度的機(jī)器源范圍。

總結(jié)

以上是對微博和阿里異地多活部署的一些總結(jié)和思考苦锨，希望能夠?qū)Υ蠹矣兴鶈l(fā)逼泣，也希望看到更多的同學(xué)分享一下各自公司的異地多活架構(gòu)方案趴泌。