01?微信發(fā)展主要的技術里程碑

微信在2011年1月21日發(fā)布了1.0版本，以即時消息為主；2011年5月上線了語音對講、查看附近的人；2012年4年發(fā)布了里程碑式的朋友圈功能；2013年游戲中心、表情商店、微信支付等。直到現(xiàn)在有了小程序生態(tài)。

02?微信后臺的系統(tǒng)架構(gòu)

邏輯上講，最前面會有一個終端，后面會有一個長鏈接接入層，在線有幾億的管理連接部分。

底層上，因為數(shù)據(jù)比較敏感而且數(shù)據(jù)量比較大，所以我們的存儲并沒有基于開源來搭建，而是自己開發(fā)了一整套存儲，這也是迭代比較多的部分。

2011年，用的是第一代存儲。早期的微信與QQ不同，它更像是一個郵箱。

后來逐漸完善，包括內(nèi)部安全、管理等。

目前，最關注的有兩個方面：

第一是，高可用。微信作為國民級應用，對高可用有著極高的要求，是不可以有服務暫停的。早期的微信迭代速度很快，幾乎每兩周一個版本，還包括大量的變更。

第二是，敏捷開發(fā)的一些問題。例如Coredump、內(nèi)存泄露等等。

03?微信后臺系統(tǒng)主要面臨的挑戰(zhàn)

微信的用戶規(guī)模已達10億，每天的微信消息達1000+億，朋友圈每日發(fā)表和點贊數(shù)達10+億，每日瀏覽數(shù)達100+億，開放平臺，微信支付等業(yè)務活躍度持續(xù)增長。

系統(tǒng)方面主要面臨4大挑戰(zhàn)：

1.海量存儲。需要一個能容錯、容災的高可用存儲與計算的框架。

2.數(shù)據(jù)強一致性。保障10億用戶數(shù)據(jù)不會出現(xiàn)問題。

3.突發(fā)洪峰流量。春節(jié)、元旦、以及突發(fā)熱點事件。

4.數(shù)據(jù)存取壓力大。后臺數(shù)據(jù)服務節(jié)點，每分鐘超過百億次數(shù)據(jù)存取服務。

04?微信后臺對高可用的定義

在高可用方面，我們先了解相關定義如下圖所示：

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

微信是一個什么樣的應用場景？微信其實有金融應用，也就是大家常用的微信支付。

那么我們希望達到怎樣的目標呢？有2大點：

1、機器故障是常態(tài)，微信希望提供連續(xù)無間斷的服務能力

業(yè)界數(shù)據(jù)可用性，通常通過Paxos租約、RAFT等來實現(xiàn)數(shù)據(jù)復制。機器故障時，系統(tǒng)會進入等待租約過期并重新選主的狀態(tài)，即會產(chǎn)生30秒級別的服務中斷，這對于我們來講也是不能接收的。

2、相對于傳統(tǒng)的基于故障轉(zhuǎn)移的系統(tǒng)設計，我們需要構(gòu)建一個多主同時服務的系統(tǒng)，系統(tǒng)始終在多個數(shù)據(jù)中心中運行，數(shù)據(jù)中心之間自適應地移動負載，透明地處理不同規(guī)模的中斷。

05?微信系統(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和熱點處理的要求很高。同時它對于追流水/恢復流程有時效性的要求。

目前微信的核心數(shù)據(jù)存儲服務可用性達6個9。整個系統(tǒng)有一個創(chuàng)新的技術點，具體細節(jié)我們發(fā)表在：

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

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

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

06?PaxosStore整體架構(gòu)

PaxosStore整體架構(gòu)，如下圖。中間我們會把PaxosStore共識層和計算層、存儲層分離起來，PaxosStore其實是一整套框架，它可以容納不同的共識算法和存儲。

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

最下面是遷移系統(tǒng)、備份系統(tǒng)、路由中心。PaxosStore支持類SQL的filter，format，limit，groupby等能力，單表可以支持億行記錄。下一步，我們可能會根據(jù)業(yè)務的需求去開展。

07?微信Chubby建設實踐

Chubby是Google一個論文提到的系統(tǒng)，微信技術團隊延伸了這樣一個邏輯，基本上跟它的接口是一樣的。

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

后來，我們基于PaxosStore也實現(xiàn)了分布式文件存儲。

08?微信分布式文件系統(tǒng)

微信分布式文件系統(tǒng)Namenode 基于PaxosStore，DataNode基于Raft協(xié)議。Raft是基于租約機制的完美實現(xiàn)?；赗aft我們可以做到DataNode的強一致寫。另外，它支持文件AppendWrite和隨機讀以及文件回收等功能。

09?微信微服務架構(gòu)框架

微服務包含了服務定義、服務發(fā)現(xiàn)、錯誤重試、監(jiān)控容災、灰度發(fā)布等一系列面向服務的高級特性的統(tǒng)一框架。中間有一個配置管理和下發(fā)的過程，這一塊也是PaxosStore實現(xiàn)的，它可以完全控制代碼的安全性。

下面是一個發(fā)布的過程，因為微信有很多服務器集群，也有一個資源化系統(tǒng)，有可能一個服務會橫跨幾千臺機器，內(nèi)部是一套BT協(xié)議。

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

10?協(xié)程在微信系統(tǒng)中的應用

大家還記得微信2013年的那一次故障， 我們開始整體優(yōu)化微信后臺的過載保護能力，也促使我們?nèi)ヌ嵘麄€微信后臺的高并發(fā)能力。

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

協(xié)程服務，同步編程、異步執(zhí)行，由于不需要自己設計各種狀態(tài)保存數(shù)據(jù)結(jié)構(gòu)，臨時狀態(tài)/變量在一片連續(xù)的棧中分配，性能比手寫異步通常要高，重要的一點是編寫并發(fā)任務很方便。

以上介紹了微信后臺高可用、數(shù)據(jù)一致性、微服務、數(shù)據(jù)存儲等實踐。

總結(jié)

以上是生活随笔為你收集整理的微信10亿日活场景下，后台系统微服务架构实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。