異地多活的好處阿里巴巴的同學已經充分闡述，微博的初始出發點包括異地災備、提升南方電信用戶訪問速度、提升海外用戶訪問速度、降低部署成本（北京機房機架費太貴了）等。通過實踐，我們發現優勢還包括異地容災、動態加速、流量均衡、在線壓測等，而挑戰包括增加研發複雜度、增加存儲成本等。
微博外部歷程
先說說微博外部的歷程，整個過程可謂是一波多折。微博的主要機房都集中在北京，只有很小一部分業務在廣州部署，2010年10月，因微博高速發展，所以準備擴大廣州機房服務器規模，並對微博做異地雙活部署。
第一版跨機房消息同步方案採取的是基於自研的MytriggerQ（藉助MySQL從庫的觸發器將INSERT、UPDATE、DELETE等事件轉為消息）的方案，這個方案的好處是，跨機房的消息同步是通過MySQL的主從完成的，方案成熟度高。而缺點則是，微博同一個業務會有好幾張表，而每張表的信息又不全，這樣每發一條微博會有多條消息先後到達，這樣導致有較多時序問題，緩存容易花。
第一套方案未能成功，但也讓我們認識到跨機房消息同步的核心問題，並促使我們全面下線MytriggerQ的消息同步方案，而改用基於業務寫消息到MCQ（MemcacheQ，新浪自研的一套消息隊列，類MC協議）的解決方案。
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動態部署的範圍，進一步擴大動態調度的機器源範圍。
總結
以上是對微博和阿里異地多活部署的一些總結和思考，希望能夠對大家有所啟發，也希望看到更多的同學分享一下各自公司的異地多活架構方案。
閱讀更多 Java架構師客棧 的文章
