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