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