架構

從0到10億,微信后臺架構及基礎設施設計與實踐!

廣告
廣告

微信掃一掃,分享到朋友圈

從0到10億,微信后臺架構及基礎設施設計與實踐!
1 0

摘要: 微信后臺業務類型眾多,包括即時通信,社交網絡,金融支付等等。本次分享著重討論如何在海量用戶場景下,后臺架構設計中的共性部分如高可用、強一致、快速迭代等等,微信是如何在不斷變化的背景下設計統一的架構與基礎設施來解決核心難題。

許家滔,微信技術架構部后臺總監,專家工程師,多年來伴隨QQ郵箱和微信后臺成長,歷經系統從0到10億級用戶的過程。目前負責微信后臺工作,包括消息,資料與關系鏈,后臺基礎設施等內容。

本文根據許家滔老師在2018年10月17日【第十屆中國系統架構師大會(SACC2018)】現場演講內容整理而成。

回顧微信發展歷程

2011年,我們發布了第一版微信,2012年,推出視頻聊天功能。如今,微信的活躍用戶數已經達到10億。后臺涉及到的技術很多,我這邊主要聚焦于數據存儲、微服務等。

微信后臺系統架構

這是最新的微信后臺系統架構圖,邏輯上最前面會有一個終端,后面會有一個長鏈接接入層,在線有幾億的管理連接部分。底層上,因為數據比較敏感而且數據量比較大,所以我們的存儲并沒有基于開源來搭建,而是自己開發了一整套存儲,這也是迭代比較多的部分。

最開始,也就是2011年,我們用的是第一代存儲。早期的微信與QQ不同,它更像是一個郵箱。

這幾年,我們逐漸完善,包括內部安全、管理等。

目前,我們最關心的有兩個方面,一是高可用。微信作為一個國民應用,對高可用有著極高的要求,是不可以停頓的。早期的微信迭代速度很快,幾乎每兩周一個版本,還包括大量的修改。二是敏捷開發的一些問題。例如內存泄露、Coredump等。

數據業務背景與挑戰

接下來,我重點講一下數據存儲和微服務框架這兩塊。今天的微信,用戶數達10億,每天的微信消息達1000+億,朋友圈每日發表和點贊數達10+億,每日瀏覽數達100+億,開放平臺,微信支付等業務活躍度持續增長。

總結成如下四大挑戰:

1.海量存儲

我們需要一個能容錯、容災的高可用存儲與計算的框架;

2.數據強一致性

保障10億用戶數據不會出現問題;

3.突發洪峰流量

圣誕節、元旦、除夕以及突發熱點事件;

4.后臺數據服務節點每分鐘超過百億次數據存取服務;

目標

關于可用性,大家可能已經很熟悉了,這里我再細化一下。

最下面的2個9,是指一年故障時間不超過3.65天;最上面5個9 ,是指金融應用,一年故障時間不超過5分鐘。

那么微信是一個什么樣的應用呢?微信包含了金融應用,也就是大家常用的微信支付。

那么我們希望達到怎樣的目標呢?有兩大點:

1、機器故障是常態,微信希望提供連續無間斷的服務能力

  • 業界數據可用性通常通過RAFT,Paxos租約等來實現數據復制
  • 機器故障時,系統會進入等待租約過期并重新選主的狀態,即會產生30秒級別的服務中斷,我們希望能夠規避。

2、相對于傳統的基于故障轉移的系統設計,我們需要構建一個多主同時服務的系統

  • 系統始終在多個數據中心中運行
  • 數據中心之間自適應地移動負載
  • 透明地處理不同規模的中斷(主機,機房,城市園區等)

關鍵設計

微信關鍵技術演變。最初,微信是異步復制,比較傳統的一個場景。中間這部分是選主同步復制。

業界有兩種比較經典的系統:一種是基于故障切換的系統,包括兩個主要的協議,Raft協議和基于租約Paxos Log。來保證數據的一致性,但對服務的可用性有一定影響。另一種是基于多主的系統,是在可用性方面做的最徹底的系統。它是基于非租約Paxos Log,Google MegaStore以及微信PaxosStore。

多主系統有很多的難點。第一, 海量Paxos Log管理,對存儲引擎的要求很高;第二,代碼假設在一個cas環境中運行。

要做到服務隨時可用,對cache和熱點處理的要求很高。同時它對于追流水/恢復流程有時效性的要求。

多主系統的收益

多主系統收益很大,可以分為幾個點。

一是7×24小時的可用性,它可以應對有計劃和無計劃的停機維護。不再有封塵已久的切換流程,由于多主可用,類似快照與數據對齊等行為,已經在在線核心邏輯中充分體現。其次是變更發布,因為這些系統寫出來并非一直不變,最大的可用性需求是來自于我們的程序版本發布。

第二點是資源調度,當系統變多主之后,相當于有了多臺隨時都可以用的機器,它們的模式都是一樣的,為了回避弱的節點去使用更多計算資源,只要切流量就可以了。所以切存儲跟切邏輯是一樣的,統稱為切流量。

最后一點是成本,多主系統的預留冗余成本是相對低的,因為所有的機器都可以服務用戶,所以在多主系統方面我們只需預留1/3的成本即可。

設計與實踐

微信的設計主要分為三大塊:

第一,實現同步復制,在數據分區內部實現完整ACID語義,維護細粒度的海量數據分區,且每一次數據讀寫都基于非租約的Paxos交互實現,每分鐘超過百億次。

第二,存儲引擎方面,針對微信豐富的業務場景,設計多種高性能的存儲模型,其次,我們還支持單表過億行的二維表格/FIFO隊列/key-value等數據結構。

第三,負載均衡方面,我們希望存儲系統可以動態切換計算資源,數據節點動態計算負載能力盡力服務,超過服務能力部分自動轉移到其他復制節點。

實際成果

目前微信的實際成果,核心數據存儲服務可用性達6個9。整個系統有一個創新的技術點,具體細節我們發表在:

http://www.vldb.org/pvldb/vol10/p1730-lin.pdf

論文相關示例代碼開源:github.com/tencent/paxosstore。

早期大家對Paxos算法都是認為很難實現的,近兩年逐漸有一些公司開始對這方面有一些分享。上面提到的這個論文是微信PaxosStore的一點創新,貢獻出了一些簡潔的算法實現流程,大家可以很輕松的去理解和實現。

PaxosStore廣泛支持微信在線應用

這些數據的應用基本都是PaxosStore在支持。

PaxosStore整體架構

下面,簡單介紹下PaxosStore的整體架構。

分成幾個園區,園區必須有獨立的網絡和電力。 舉個例子,假設有些機房實際上共享了一套電力甚至交換機的話,只要單點故障一樣會掛掉。

所以,園區只是一個概念,至少要滿足網絡和電力獨立,然后在考慮跨層或跨省的問題,PaxosStore實際上也有跨華東,華南,華北三個遙遠距離的服務。

中間我們會把PaxosStore共識層和計算層、存儲層分離起來,PaxosStore其實是一整套框架,它可以容納不同的共識算法和存儲。

下面是一個存儲引擎。微信的存儲引擎包括很多種,最早是Bitcask模型,現在廣泛使用的是LSM,它可以支持比較多的業務。

最下面是遷移系統、備份系統、路由中心。

PaxosStore支持類SQL的filter,format,limit,groupby等能力,單表可以支持億行記錄。下一步,我們可能會根據業務的需求去開展。

PaxosStore:數據分布與復制

這一套分布式,其實是延伸了之前老系統的分布方式,數據會分成兩層,它會按一致性hash劃分到不同的節點。每個節點都有六個節點,它們交叉實現了復制的邏輯,可以達到一個比較好的負載均衡。

基于PaxosStore的在線基礎組件

2017年之后,將整個微信90%的存儲切完后,繼續往下發展。隨著業務的發展,我們把很多的立體圖連起來。有了PaxosStore框架之后,很多系統都相對容易實現,像比較典型的zookeeper、hdfs、hbase等。

除了基本的數據系統之外,我們還有很多特殊的場景,例如遠距離跨省常量存儲。如,微信支付訂單等場景,都有強烈的數據庫需求,而且需要跨省容災。

什么是遠距離?考慮到故障的實際影響范圍以及專線的物理情況,在地點的選擇上,是有一定要求的,因此,在選點的選擇上,一般選在整個中國跨越比較遠的一些地方,如,上海、深圳、天津,構成了一個三角,相互間距大概2000公里左右。但有個實際問題,如果跨省,必須給它大概三四十毫秒左右的延遲。另外,像深圳跟汕頭,上海跟天津,這些都不算遠距離跨省。如果上海掛了,杭州的線也一定會出現問題,因為它倆距離比較近。

常量存儲有什么特點?它的寫需要有跨越三四十毫秒的跨城通信過程,但讀是本地的。

另外,我們還針對微信支付復雜業務定制了事務容器以及針對搜索推薦業務的高性能特征存儲。

微信chubby

Chubby是Google一個論文提到的系統,我們也延伸了這樣一個邏輯,基本上跟它的接口是一樣的。

當時,我們有一個很奇怪的發現,不管是Google Chubby論文提到的代碼量還是zookeeper的實際代碼量都很大,但有了PaxosStore之后,根本不需要那么多的代碼,所以接下來我們的處理也可能會考慮開源。

然后,我們基于PaxosStore也實現了分布式文件存儲。

微信分布式文件系統

微信分布式文件系統Namenode 基于PaxosStore,DataNode基于Raft協議。Raft是基于租約機制的完美實現。基于Raft我們可以做到DataNode的強一致寫。另外,它支持文件AppendWrite和隨機讀以及文件回收等功能。

分布式表格:架構圖

這個其實對應的是hbase。我們也基于PaxosStore去做了它的核心部分,然后把整套實現起來。

微服務框架

我們數據存儲跟微服務架構是兩大塊。微服務包含了服務定義、服務發現、錯誤重試、監控容災、灰度發布等一系列面向服務的高級特性的統一框架。中間有一個配置管理和下發的過程,這一塊也是PaxosStore實現的,它可以完全控制代碼的安全性。

下面是一個發布的過程,因為微信有很多臺服務器,之前我們也有一個資源化系統,有可能一個服務會橫跨幾千臺機器,這時候,發布一個二進制,只能在幾百兆時間內,所以,內部也是一套BT協議。

然后,我們有一些監控處理,最后我們會有過載保護保護,在系統里面過載保護是很關鍵的一塊。因為在后臺,當一個請求過來的時候,某些節點產生了一個慢延遲和性能差,就會影響整條鏈路,所以我們會有一個整套的過載保護的實現。

業務邏輯Worker模型選擇

一般開源的東西就是在對標誰的性能高,但是在實際的后臺服務當中,你的可用性要求都會很高。

所以我們會分成兩種不同的服務,PaxosStore是比較重要的核心服務,使用多線程。但是在大量的應用開發中,我們始終是多進程的服務,而且多進程框架是可以定時重啟的。

多進程的一個重點就在于內存泄漏與coredump容忍度很高,在快速開發特性時候尤其重要。

最后,不管是多進程還是多線程,都類似一個協程的處理,可以把我們的并發能力提得很高。

Libco背景

協程是在2013、2014年開始構建的。2013年,開始運行在微信的后臺。基于2013年的那一次故障, 我們開始整體優化微信后臺的過載保護能力,也促使我們去提升整個微信后臺的高并發能力。

思考了幾個月后,總結兩個方法,一個是把整個代碼逐步重構成一個異步模型,但這個工程量巨大。第二個是,去探索協程解決方案,少量修改代碼達到同步編碼,異步執行效果。但當時采取這個方案的案例不太多,所以,我們也很擔心。

舉個例子,如果把Leveldb的本地文件切換為遠程文件系統,那么異步代碼如何實現?協程如何實現?

異步服務與協程服務的對比

傳統基于事件驅動的異步網絡服務優勢高、性能高、CPU利用率高,但編寫困難,需要業務層維護狀態機,業務邏輯被異步編碼拆分得支離破碎。Future/promise等技術,趨近于同步編程,但仍然繁瑣,并且并發任務難以編寫與維護。

協程服務,同步編程、異步執行,由于不需要自己設計各種狀態保存數據結構,臨時狀態/變量在一片連續的棧中分配,性能比手寫異步通常要高,重要的一點是編寫并發任務很方便。

協程定義

協程到底是什么?可以說它是微線程,也可以說它是用戶態線程。協程切換流程其實不復雜,它主要任務是把上下文保存起來。上下文只有兩個部分,第一部分是內存和寄存器,第二部分是棧的狀態。

函數調用的基本原理

我們看一下函數調用的基本原理,32位程序為例的話,其實函數調用的過程很簡單,就是把函數壓棧,用Call指令跳到某個地方。因為eip不能直接修改,所以只能間接操作。Ret指令跟這個比較類似。

Libco協程切換核心代碼

這是主要的代碼。協程本身并不復雜,一個是因為基于上述的原理只要一些匯編代碼可以了,它主要保存了一些寄存器,并把一些狀態存起來,然后只處理一些寄存器的狀態就可以。但只有這一部分是不夠的,因為如果我們提供了一個協程,用戶還是要做很多代碼。

Libco框架

一個純粹的協程必須跟網絡框架結合在一起才能實現它的價值。

我們對協程做了最基本的源語,因為我們并不想發明更多的概念出來。協程的源語包括co_create/co_resume/co_yield,協程間同步cond/signal。

同時我們還提供了一個輕量級網絡事件庫。基于同樣的考慮,這個庫是基于epoll的事件回調以及基于時間輪盤的定時器設計。

另外Socket族函數hook,我們實現網絡讀寫api hook,支持mysqlclient/gethostbyname,支持aio讀磁盤,支持cgi(getenv/setenv)。

經過這套設計之后,我們就開始對微信的后臺進行改造,目前基本上改造完成。

線程內協程切換圖

這是一些具體的情況。我們可以看到,我們必須實現一個主的EventLoop去處理后發出的所有事件,在事件被觸發的時候,可以保證為通。

用一個標準的線程,基于網絡事件切換協程。如果異步處理才能把邏輯分成很多分片,然后在事件觸發過程中用回調來完成你的邏輯,但是反過來在協程里面就簡單很多。

Libco下編程需要注意的點

現在Libco棧大小默認設置為128K,它可以支持一個共享執行,支持單機千萬協程,那需要注意什么呢?有兩點:

首先需要用poll代替sleep,其次對于計算較重的服務,需要分離計算線程與網絡線程,避免互相影響。

在實踐的過程中,遇到的問題還有很多,只要把所有的情況都考慮進去,就可能有很好的提升。這些年,有了這兩大基礎組件的支撐,微信現在進入比較穩定的時期。

今天分享大概就是這樣,謝謝大家。

老魚,企業級老編一枚,你若有故事,歡迎聯系!

即使站在風口也未必能飛:SaaS公司生存指南

上一篇

從MySQL到POLARDB, 三位CTO講述遷移背后的故事!

下一篇

你也可能喜歡

從0到10億,微信后臺架構及基礎設施設計與實踐!

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆时时彩官网直播开奖