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

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

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

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

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

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

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

目前，最關(guān)注的有兩個(gè)方面：

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

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

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

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

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

1.海量存儲(chǔ)。需要一個(gè)能容錯(cuò)、容災(zāi)的高可用存儲(chǔ)與計(jì)算的框架。

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

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

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

04?微信后臺(tái)對高可用的定義

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

最下面的2個(gè)9，是指一年故障時(shí)間不超過3.65天；最上面5個(gè)9 ，是指金融應(yīng)用，一年故障時(shí)間不超過5分鐘。

微信是一個(gè)什么樣的應(yīng)用場景？微信其實(shí)有金融應(yīng)用，也就是大家常用的微信支付。

那么我們希望達(dá)到怎樣的目標(biāo)呢？有2大點(diǎn)：

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

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

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

05?微信系統(tǒng)高可用的關(guān)鍵設(shè)計(jì)

最初，微信是異步復(fù)制，接著是選主同步復(fù)制，然后是多主可用。

基于故障切換的系統(tǒng)。包括兩個(gè)主要的協(xié)議，Raft協(xié)議和基于租約Paxos Log。來保證數(shù)據(jù)的一致性，但對服務(wù)的可用性有一定影響。

基于多主的系統(tǒng)。是在可用性方面做的最徹底的系統(tǒng)，它是基于非租約Paxos Log，Google MegaStore以及微信PaxosStore。

多主系統(tǒng)有很多的難點(diǎn)，第一， 海量Paxos Log管理，對存儲(chǔ)引擎的要求很高。第二，代碼假設(shè)在一個(gè)cas環(huán)境中運(yùn)行。要做到服務(wù)隨時(shí)可用，對cache和熱點(diǎn)處理的要求很高。同時(shí)它對于追流水/恢復(fù)流程有時(shí)效性的要求。

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

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

論文相關(guān)示例代碼開源：
github.com/tencent/paxosstore。

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

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

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

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

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

07?微信Chubby建設(shè)實(shí)踐

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

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

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

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

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

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

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

下面是一個(gè)發(fā)布的過程，因?yàn)槲⑿庞泻芏喾?wù)器集群，也有一個(gè)資源化系統(tǒng)，有可能一個(gè)服務(wù)會(huì)橫跨幾千臺(tái)機(jī)器，內(nèi)部是一套BT協(xié)議。

然后，我們有一些監(jiān)控處理，最后我們會(huì)有過載保護(hù)保護(hù)，在系統(tǒng)里面過載保護(hù)是很關(guān)鍵的一塊。因?yàn)樵诤笈_(tái)，當(dāng)一個(gè)請求過來的時(shí)候，某些節(jié)點(diǎn)產(chǎn)生了一個(gè)慢延遲和性能差，就會(huì)影響整條鏈路，所以我們會(huì)有一個(gè)整套的過載保護(hù)的實(shí)現(xiàn)。

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

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

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

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

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

總結(jié)

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

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