微信后臺架構及基礎設施設計與實踐

1、 微信后臺架構及基礎設施設計與實踐摘要：微信后臺業(yè)務類型眾多，包括即時通信，社交網(wǎng)絡，金融支付等等。本次分享著重討論如何在海量用戶場景下，后臺架構設計中的共性部分如高可用、強一致、快速迭代等等，微信是如何在不斷變化的背景下設計統(tǒng)一的架構與基礎設施來解決核心難題。目 錄 TOC o 1-3 h z u HYPERLINK l _Toc13032399 1.回顧微信發(fā)展歷程 PAGEREF _Toc13032399 h 4 HYPERLINK l _Toc13032400 2.微信后臺系統(tǒng)架構 PAGEREF _Toc13032400 h 4 HYPERLINK l _Toc13032401 3.

2、數(shù)據(jù)業(yè)務背景與挑戰(zhàn) PAGEREF _Toc13032401 h 6 HYPERLINK l _Toc13032402 4.目標 PAGEREF _Toc13032402 h 7 HYPERLINK l _Toc13032403 5.關鍵設計 PAGEREF _Toc13032403 h 8 HYPERLINK l _Toc13032404 6.多主系統(tǒng)的收益 PAGEREF _Toc13032404 h 10 HYPERLINK l _Toc13032405 7.設計與實踐 PAGEREF _Toc13032405 h 10 HYPERLINK l _Toc13032406 8.實際成果 P

3、AGEREF _Toc13032406 h 11 HYPERLINK l _Toc13032407 9.PaxosStore廣泛支持微信在線應用 PAGEREF _Toc13032407 h 12 HYPERLINK l _Toc13032408 10.PaxosStore整體架構 PAGEREF _Toc13032408 h 13 HYPERLINK l _Toc13032409 11.PaxosStore：數(shù)據(jù)分布與復制 PAGEREF _Toc13032409 h 14 HYPERLINK l _Toc13032410 12.基于PaxosStore的在線基礎組件 PAGEREF _To

4、c13032410 h 15 HYPERLINK l _Toc13032411 13.微信chubby PAGEREF _Toc13032411 h 16 HYPERLINK l _Toc13032412 14.微信分布式文件系統(tǒng) PAGEREF _Toc13032412 h 17 HYPERLINK l _Toc13032413 15.分布式表格：架構圖 PAGEREF _Toc13032413 h 17 HYPERLINK l _Toc13032414 16.微服務框架 PAGEREF _Toc13032414 h 18 HYPERLINK l _Toc13032415 17.業(yè)務邏輯Wo

5、rker模型選擇 PAGEREF _Toc13032415 h 20 HYPERLINK l _Toc13032416 18.Libco背景 PAGEREF _Toc13032416 h 21 HYPERLINK l _Toc13032417 19.異步服務與協(xié)程服務的對比 PAGEREF _Toc13032417 h 21 HYPERLINK l _Toc13032418 20.協(xié)程定義 PAGEREF _Toc13032418 h 22 HYPERLINK l _Toc13032419 21.函數(shù)調用的基本原理 PAGEREF _Toc13032419 h 23 HYPERLINK l _

6、Toc13032420 22.Libco協(xié)程切換核心代碼 PAGEREF _Toc13032420 h 23 HYPERLINK l _Toc13032421 23.Libco框架 PAGEREF _Toc13032421 h 24 HYPERLINK l _Toc13032422 24.線程內協(xié)程切換圖 PAGEREF _Toc13032422 h 25 HYPERLINK l _Toc13032423 25.Libco下編程需要注意的點 PAGEREF _Toc13032423 h 26回顧微信發(fā)展歷程2011年，我們發(fā)布了第一版微信，2012年，推出視頻聊天功能。如今，微信的活躍用戶數(shù)已

7、經(jīng)達到10億。后臺涉及到的技術很多，我這邊主要聚焦于數(shù)據(jù)存儲、微服務等。微信后臺系統(tǒng)架構這是最新的微信后臺系統(tǒng)架構圖，邏輯上最前面會有一個終端，后面會有一個長鏈接接入層，在線有幾億的管理連接部分。底層上，因為數(shù)據(jù)比較敏感而且數(shù)據(jù)量比較大，所以我們的存儲并沒有基于開源來搭建，而是自己開發(fā)了一整套存儲，這也是迭代比較多的部分。最開始，也就是2011年，我們用的是第一代存儲。早期的微信與QQ不同，它更像是一個郵箱。這幾年，我們逐漸完善，包括內部安全、管理等。目前，我們最關心的有兩個方面，一是高可用。微信作為一個國民應用，對高可用有著極高的要求，是不可以停頓的。早期的微信迭代速度很快，幾乎每兩周一個版

8、本，還包括大量的修改。二是敏捷開發(fā)的一些問題。例如內存泄露、Coredump等。數(shù)據(jù)業(yè)務背景與挑戰(zhàn)接下來，我重點講一下數(shù)據(jù)存儲和微服務框架這兩塊。今天的微信，用戶數(shù)達10億，每天的微信消息達1000+億，朋友圈每日發(fā)表和點贊數(shù)達10+億，每日瀏覽數(shù)達100+億，開放平臺，微信支付等業(yè)務活躍度持續(xù)增長。總結成如下四大挑戰(zhàn)：1.海量存儲我們需要一個能容錯、容災的高可用存儲與計算的框架;2.數(shù)據(jù)強一致性保障10億用戶數(shù)據(jù)不會出現(xiàn)問題;3.突發(fā)洪峰流量圣誕節(jié)、元旦、除夕以及突發(fā)熱點事件;4.后臺數(shù)據(jù)服務節(jié)點每分鐘超過百億次數(shù)據(jù)存取服務;目標關于可用性，大家可能已經(jīng)很熟悉了，這里我再細化一下。最下面的2

9、個9，是指一年故障時間不超過3.65天；最上面5個9 ，是指金融應用，一年故障時間不超過5分鐘。那么微信是一個什么樣的應用呢？微信包含了金融應用，也就是大家常用的微信支付。那么我們希望達到怎樣的目標呢？有兩大點：1、機器故障是常態(tài)，微信希望提供連續(xù)無間斷的服務能力業(yè)界數(shù)據(jù)可用性通常通過RAFT，Paxos租約等來實現(xiàn)數(shù)據(jù)復制機器故障時，系統(tǒng)會進入等待租約過期并重新選主的狀態(tài)，即會產生30秒級別的服務中斷，我們希望能夠規(guī)避。2、相對于傳統(tǒng)的基于故障轉移的系統(tǒng)設計，我們需要構建一個多主同時服務的系統(tǒng)系統(tǒng)始終在多個數(shù)據(jù)中心中運行數(shù)據(jù)中心之間自適應地移動負載透明地處理不同規(guī)模的中斷（主機，機房，城市園

10、區(qū)等）關鍵設計微信關鍵技術演變。最初，微信是異步復制，比較傳統(tǒng)的一個場景。中間這部分是選主同步復制。業(yè)界有兩種比較經(jīng)典的系統(tǒng)：一種是基于故障切換的系統(tǒng)，包括兩個主要的協(xié)議，Raft協(xié)議和基于租約Paxos Log。來保證數(shù)據(jù)的一致性，但對服務的可用性有一定影響。另一種是基于多主的系統(tǒng)，是在可用性方面做的最徹底的系統(tǒng)。它是基于非租約Paxos Log，Google MegaStore以及微信PaxosStore。多主系統(tǒng)有很多的難點。第一， 海量Paxos Log管理，對存儲引擎的要求很高；第二，代碼假設在一個cas環(huán)境中運行。要做到服務隨時可用，對cache和熱點處理的要求很高。同時它對于追流

11、水/恢復流程有時效性的要求。多主系統(tǒng)的收益多主系統(tǒng)收益很大，可以分為幾個點。一是724小時的可用性，它可以應對有計劃和無計劃的停機維護。不再有封塵已久的切換流程，由于多主可用，類似快照與數(shù)據(jù)對齊等行為，已經(jīng)在在線核心邏輯中充分體現(xiàn)。其次是變更發(fā)布，因為這些系統(tǒng)寫出來并非一直不變，最大的可用性需求是來自于我們的程序版本發(fā)布。第二點是資源調度，當系統(tǒng)變多主之后，相當于有了多臺隨時都可以用的機器，它們的模式都是一樣的，為了回避弱的節(jié)點去使用更多計算資源，只要切流量就可以了。所以切存儲跟切邏輯是一樣的，統(tǒng)稱為切流量。最后一點是成本，多主系統(tǒng)的預留冗余成本是相對低的，因為所有的機器都可以服務用戶，所以在

12、多主系統(tǒng)方面我們只需預留1/3的成本即可。設計與實踐微信的設計主要分為三大塊：第一，實現(xiàn)同步復制，在數(shù)據(jù)分區(qū)內部實現(xiàn)完整ACID語義，維護細粒度的海量數(shù)據(jù)分區(qū)，且每一次數(shù)據(jù)讀寫都基于非租約的Paxos交互實現(xiàn)，每分鐘超過百億次。第二，存儲引擎方面，針對微信豐富的業(yè)務場景，設計多種高性能的存儲模型，其次，我們還支持單表過億行的二維表格/FIFO隊列/key-value等數(shù)據(jù)結構。第三，負載均衡方面，我們希望存儲系統(tǒng)可以動態(tài)切換計算資源，數(shù)據(jù)節(jié)點動態(tài)計算負載能力盡力服務，超過服務能力部分自動轉移到其他復制節(jié)點。實際成果目前微信的實際成果，核心數(shù)據(jù)存儲服務可用性達6個9。整個系統(tǒng)有一個創(chuàng)新的技術點，

13、具體細節(jié)我們發(fā)表在：/pvldb/vol10/p1730-lin.pdf 論文相關示例代碼開源：/tencent/paxosstore。早期大家對Paxos算法都是認為很難實現(xiàn)的，近兩年逐漸有一些公司開始對這方面有一些分享。上面提到的這個論文是微信PaxosStore的一點創(chuàng)新，貢獻出了一些簡潔的算法實現(xiàn)流程，大家可以很輕松的去理解和實現(xiàn)。PaxosStore廣泛支持微信在線應用這些數(shù)據(jù)的應用基本都是PaxosStore在支持。PaxosStore整體架構下面，簡單介紹下PaxosStore的整體架構。分成幾個園區(qū)，園區(qū)必須有獨立的網(wǎng)絡和電力。 舉個例子，假設有些機房實際上共享了一套電力甚至交

14、換機的話，只要單點故障一樣會掛掉。所以，園區(qū)只是一個概念，至少要滿足網(wǎng)絡和電力獨立，然后在考慮跨層或跨省的問題，PaxosStore實際上也有跨華東，華南，華北三個遙遠距離的服務。中間我們會把PaxosStore共識層和計算層、存儲層分離起來，PaxosStore其實是一整套框架，它可以容納不同的共識算法和存儲。下面是一個存儲引擎。微信的存儲引擎包括很多種，最早是Bitcask模型，現(xiàn)在廣泛使用的是LSM，它可以支持比較多的業(yè)務。最下面是遷移系統(tǒng)、備份系統(tǒng)、路由中心。 PaxosStore支持類SQL的filter，format，limit，groupby等能力，單表可以支持億行記錄。下一步，

15、我們可能會根據(jù)業(yè)務的需求去開展。PaxosStore：數(shù)據(jù)分布與復制這一套分布式，其實是延伸了之前老系統(tǒng)的分布方式，數(shù)據(jù)會分成兩層，它會按一致性hash劃分到不同的節(jié)點。每個節(jié)點都有六個節(jié)點，它們交叉實現(xiàn)了復制的邏輯，可以達到一個比較好的負載均衡?；赑axosStore的在線基礎組件2017年之后，將整個微信90%的存儲切完后，繼續(xù)往下發(fā)展。隨著業(yè)務的發(fā)展，我們把很多的立體圖連起來。有了PaxosStore框架之后，很多系統(tǒng)都相對容易實現(xiàn)，像比較典型的zookeeper、hdfs、hbase等。除了基本的數(shù)據(jù)系統(tǒng)之外，我們還有很多特殊的場景，例如遠距離跨省常量存儲。如，微信支付訂單等場景，都

16、有強烈的數(shù)據(jù)庫需求，而且需要跨省容災。什么是遠距離？考慮到故障的實際影響范圍以及專線的物理情況，在地點的選擇上，是有一定要求的，因此，在選點的選擇上，一般選在整個中國跨越比較遠的一些地方，如，上海、深圳、天津，構成了一個三角，相互間距大概2000公里左右。但有個實際問題，如果跨省，必須給它大概三四十毫秒左右的延遲。另外，像深圳跟汕頭，上海跟天津，這些都不算遠距離跨省。如果上海掛了，杭州的線也一定會出現(xiàn)問題，因為它倆距離比較近。常量存儲有什么特點？它的寫需要有跨越三四十毫秒的跨城通信過程，但讀是本地的。另外，我們還針對微信支付復雜業(yè)務定制了事務容器以及針對搜索推薦業(yè)務的高性能特征存儲。微信chu

17、bbyChubby是Google一個論文提到的系統(tǒng)，我們也延伸了這樣一個邏輯，基本上跟它的接口是一樣的。當時，我們有一個很奇怪的發(fā)現(xiàn)，不管是Google Chubby論文提到的代碼量還是zookeeper的實際代碼量都很大，但有了PaxosStore之后，根本不需要那么多的代碼，所以接下來我們的處理也可能會考慮開源。然后，我們基于PaxosStore也實現(xiàn)了分布式文件存儲。微信分布式文件系統(tǒng)微信分布式文件系統(tǒng)Namenode 基于PaxosStore，DataNode基于Raft協(xié)議。Raft是基于租約機制的完美實現(xiàn)。基于Raft我們可以做到DataNode的強一致寫。另外，它支持文件Appe

18、ndWrite和隨機讀以及文件回收等功能。分布式表格：架構圖這個其實對應的是hbase。我們也基于PaxosStore去做了它的核心部分，然后把整套實現(xiàn)起來。微服務框架我們數(shù)據(jù)存儲跟微服務架構是兩大塊。微服務包含了服務定義、服務發(fā)現(xiàn)、錯誤重試、監(jiān)控容災、灰度發(fā)布等一系列面向服務的高級特性的統(tǒng)一框架。中間有一個配置管理和下發(fā)的過程，這一塊也是PaxosStore實現(xiàn)的，它可以完全控制代碼的安全性。下面是一個發(fā)布的過程，因為微信有很多臺服務器，之前我們也有一個資源化系統(tǒng)，有可能一個服務會橫跨幾千臺機器，這時候，發(fā)布一個二進制，只能在幾百兆時間內，所以，內部也是一套BT協(xié)議。然后，我們有一些監(jiān)控處理

19、，最后我們會有過載保護保護，在系統(tǒng)里面過載保護是很關鍵的一塊。因為在后臺，當一個請求過來的時候，某些節(jié)點產生了一個慢延遲和性能差，就會影響整條鏈路，所以我們會有一個整套的過載保護的實現(xiàn)。業(yè)務邏輯Worker模型選擇一般開源的東西就是在對標誰的性能高，但是在實際的后臺服務當中，你的可用性要求都會很高。所以我們會分成兩種不同的服務，PaxosStore是比較重要的核心服務，使用多線程。但是在大量的應用開發(fā)中，我們始終是多進程的服務，而且多進程框架是可以定時重啟的。多進程的一個重點就在于內存泄漏與coredump容忍度很高，在快速開發(fā)特性時候尤其重要。最后，不管是多進程還是多線程，都類似一個協(xié)程的處

20、理，可以把我們的并發(fā)能力提得很高。Libco背景協(xié)程是在2013、2014年開始構建的。2013年，開始運行在微信的后臺?；?013年的那一次故障， 我們開始整體優(yōu)化微信后臺的過載保護能力，也促使我們去提升整個微信后臺的高并發(fā)能力。思考了幾個月后，總結兩個方法，一個是把整個代碼逐步重構成一個異步模型，但這個工程量巨大。第二個是，去探索協(xié)程解決方案，少量修改代碼達到同步編碼，異步執(zhí)行效果。但當時采取這個方案的案例不太多，所以，我們也很擔心。舉個例子，如果把Leveldb的本地文件切換為遠程文件系統(tǒng)，那么異步代碼如何實現(xiàn)？協(xié)程如何實現(xiàn)？異步服務與協(xié)程服務的對比傳統(tǒng)基于事件驅動的異步網(wǎng)絡服務優(yōu)勢高

21、、性能高、CPU利用率高，但編寫困難，需要業(yè)務層維護狀態(tài)機，業(yè)務邏輯被異步編碼拆分得支離破碎。Future/promise等技術，趨近于同步編程，但仍然繁瑣，并且并發(fā)任務難以編寫與維護。協(xié)程服務，同步編程、異步執(zhí)行，由于不需要自己設計各種狀態(tài)保存數(shù)據(jù)結構，臨時狀態(tài)/變量在一片連續(xù)的棧中分配，性能比手寫異步通常要高，重要的一點是編寫并發(fā)任務很方便。協(xié)程定義協(xié)程到底是什么？可以說它是微線程，也可以說它是用戶態(tài)線程。協(xié)程切換流程其實不復雜，它主要任務是把上下文保存起來。上下文只有兩個部分，第一部分是內存和寄存器，第二部分是棧的狀態(tài)。函數(shù)調用的基本原理我們看一下函數(shù)調用的基本原理，32位程序為例的話，其實函數(shù)調用的過程很簡單，就是把函數(shù)壓棧，用Call指令跳到某個地方。因為eip不能直接修改，所以只能間接操作。Ret指令跟這個比較類似。Libco協(xié)程切換核心代碼這是主要的代碼。協(xié)程本身并不復雜，一個是因為基于上述的原理只要一些匯編代碼可以了，它主要保