轉: ?http://www.infoq.com/cn/articles/weibo-multi-idc-architecture

?

在國內網絡環境下，單機房的可靠性無法滿足大型互聯網服務的要求，如機房掉電，光纜被挖的情況也發生過。微信就曾發生大面積故障，包括微信信息無法發出、無法刷新朋友圈、無法連接微信網頁版，或接收到的圖片無法打開等。同時，微信公眾平臺也出現了503報錯，范圍影響北京、上海、廣東、浙江等近20個省市。故障的原因，微信團隊指出是由于“市政道路施工導致通信光纜被挖斷，影響了微信服務器的正常連接”。單機房除了單點風險之外，另外一個問題是不適應復雜的網絡環境，下圖是調研國外各地區用戶訪問微博的延遲情況，可以看到南方海外用戶的訪問延遲比較大。

為了解決上述問題，微博在2010年啟動了多機房部署的架構升級。微博不同于靜態內容，靜態內容CDN基本上大的互聯網公司都會做，已經非常成熟。動態內容CDN是業內的難點，國內很少有公司能夠做到非常成熟的多機房動態內容發布的成熟方案。同時根據微博業務特點，又要求多機房方案能夠支持海量規模、可擴展、高性能、低延遲、高可用，所以面臨很多技術挑戰。 微博的多機房架構V1版本，解決了海量動態數據的CDN同步問題。一般業界的數據同步架構可以歸納為三種：Master-Slave，Multi-Master，Paxos。考慮到微博的特點是海量數據，低延遲，弱一致性，所以Paxos并不適合微博，而Multi-Master在當時并沒有成熟的產品，所以微博開始采用的是Master-Slave方案，如下圖：

由于Memcached服務端是無狀態的，分布式是在客戶端實現，所以需要解決兩個機房Memcached數據同步的問題。微博研發了MytriggerQ，通過解析Mysql的binlog，還原更新操作實現Memcached數據同步。

數據庫方面Mysql自身的Master-Slave同步實現是比較成熟的。但是在微博的海量數據情況下，廣州兩從的結構就導致同步的數據量翻倍，導致帶寬被大量占用。針對這個問題微博是通過Relay的方式來解決，即北京到廣州僅需要同步一份數據，到廣州后再由Relay服務器同步兩份數據給從庫。由于Relay服務器可以代理多個從庫，所以在基本沒有增加資源的情況下，我們把同步帶寬降低了一倍。 而Redis的同步實現就不太成熟了，由于不支持斷點續傳，一旦網絡抖動導致主從不一致后，導致大量的帶寬被占用，甚至出現過專線100%被占用的情況，嚴重影響正常的機房間通信，同步恢復時間需要幾個小時甚至幾天。所以微博對Redis的同步機制進行了改造，利用AOF特性支持斷點續傳。改造后即使在專線中斷的情況下，同步也可以在幾秒鐘內恢復正常。 V1版本實現了微博多機房從無到有，V2版本重點解決了多機房的可靠性和可擴展性。V2版本實現了Master-Master架構，通過消息總線同步用戶操作行為，而不再依賴底層存儲系統的同步，每個機房都獨立完成讀寫操作。

相關廠商內容

想要快速學習Amazon EMR最佳實踐，趕快報名InfoQ在線課堂

ArchSummit 晚場活動對外招募，邀您和架構師暢聊技術

如何快速搭建一個完整的移動端直播系統

你離成為一位合格的技術領導者還有多遠？

證券行業的Docker應用實踐

相關贊助商

GMTC全球移動技術大會2016年6月24日-25日，北京，點擊了解詳情！

面對微博海量實時數據，業界通用的消息總線產品無法滿足性能要求，所以我們自己基于MemcacheQ實現了一套消息總線WMB，它與普通消息總線產品最大的差別是采用一寫一讀的方式實現消息同步。這種方式最大的好處是消除了并發鎖消耗，單機性能可以發揮到極致，而吞吐量可以通過增加機器線性擴容。目前這套消息總線同步性能單機極限達到每秒10萬消息同步性能。

可靠性方面，由于各機房僅通過消息總線進行同步，不依賴任何底層資源，所以各個機房都可以獨立對外提供服務，任何一個機房出現問題都可以實現流量快速切換。可擴展性方面，增加一個機房僅需線性擴展消息總線即可完成，機房的部署結構與數據同步對業務完全透明。微博多機房已經實現從北京、廣州兩個機房的結構升級到廣州亞太、北京電信、北京聯通三個核心機房的部署結構。

Master-Master架構非常依賴消息總線的一致性，而在網絡延遲比較驗證的多機房環境下，MemcacheQ存在消息丟失的隱患，即而服務端完成消息讀取，但在傳輸過程中超時，客戶端無法再次獲取這條消息。為了解決這個問題，我們在WMB的升級版WeiBus消息總線中實現了消息同步序號的功能，支持客戶端在超時情況下，可重復獲取消息。

但是隨著微博業務的蓬勃發展，業務依賴關系越來越復雜，多機房部署成本壓力越來越大，而且運維成本也不斷攀升，下圖是一個產品的服務依賴關系圖。微博多機房V3版本實現了業務靈活多機房部署架構，支持業務自定義機房部署個數，及部署區域。

業務定制部署需要解決業務路由問題。在當前全國的網絡環境下，南北網絡專線延遲一般在30到40毫秒之間，而機房內延遲一般小于1ms。業務路由需要支持盡可能路由到調用本地機房調用，對需要跨機房調用的請求進行打包以便減少網絡延遲的影響。微博根據自身業務特點，實現了業務路由服務，支持將多個業務請求進行打包，將多個請求打包成一個請求，自動識別本地業務部署，把需要跨機房調用的請求一次性請求到對應機房，并將返回的結果打包后一并返回。并且支持自動識別業務部署結構變更，并對非核心業務異常自動隔離。

隨著移動互聯網的迅猛發展，3個機房的部署結構不能完全解決用戶訪問速度問題，一種解決方案是讓機房更加靠近用戶。但是社交網絡由于數據的網狀訪問，較難選擇合適的切分維度，目前微博核心業務仍需要各機房同步全量數據，部署更多機房的成本壓力比較大。QZone的SET化和Tumblr的Cell化在解決社交網絡拆分維度方面都值得參考，微博也在進行Cell化方面的嘗試，相關信息也會在 @微博平臺架構 微博帳號上與社區進行交流，希望感興趣的同學積極與我們互動。 微博只是多機房之路上邁出了一小步，仍有很多難題有待攻克。希望對多機房系統，對微博的架構感興趣的同學加入到我們微博的團隊，共同打造一流的分布式系統。

感謝劉宇對本文的審校。

轉載于:https://www.cnblogs.com/jhj117/p/5610701.html

總結

以上是生活随笔為你收集整理的转: 微博的多机房部署的实践（from infoq）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。