01
微信發展主要的技術里程碑
微信在2011年1月21日發佈了1.0版本，以即時消息為主；2011年5月上線了語音對講、查看附近的人；2012年4年發佈了里程碑式的朋友圈功能；2013年遊戲中心、表情商店、微信支付等。直到現在有了小程序生態。
02
微信後臺的系統架構
邏輯上講，最前面會有一個終端，後面會有一個長鏈接接入層，在線有幾億的管理連接部分。
底層上，因為數據比較敏感而且數據量比較大，所以我們的存儲並沒有基於開源來搭建，而是自己開發了一整套存儲，這也是迭代比較多的部分。
2011年，用的是第一代存儲。早期的微信與QQ不同，它更像是一個郵箱。
後來逐漸完善，包括內部安全、管理等。
目前，最關注的有兩個方面：
第一是，高可用。微信作為國民級應用，對高可用有著極高的要求，是不可以有服務暫停的。早期的微信迭代速度很快，幾乎每兩週一個版本，還包括大量的變更。
第二是，敏捷開發的一些問題。例如Coredump、內存洩露等等。
03
微信後臺系統主要面臨的挑戰
微信的用戶規模已達10億，每天的微信消息達1000+億，朋友圈每日發表和點贊數達10+億，每日瀏覽數達100+億，開放平臺，微信支付等業務活躍度持續增長。
系統方面主要面臨4大挑戰：
1.海量存儲。需要一個能容錯、容災的高可用存儲與計算的框架。
2.數據強一致性。保障10億用戶數據不會出現問題。
3.突發洪峰流量。春節、元旦、以及突發熱點事件。
4.數據存取壓力大。後臺數據服務節點，每分鐘超過百億次數據存取服務。
04
微信後臺對高可用的定義
在高可用方面，我們先了解相關定義如下圖所示：
最下面的2個9，是指一年故障時間不超過3.65天；最上面5個9 ，是指金融應用，一年故障時間不超過5分鐘。
微信是一個什麼樣的應用場景？微信其實有金融應用，也就是大家常用的微信支付。
那麼我們希望達到怎樣的目標呢？有2大點：
1、機器故障是常態，微信希望提供連續無間斷的服務能力
業界數據可用性，通常通過Paxos租約、RAFT等來實現數據複製。機器故障時，系統會進入等待租約過期並重新選主的狀態，即會產生30秒級別的服務中斷，這對於我們來講也是不能接收的。
2、相對於傳統的基於故障轉移的系統設計，我們需要構建一個多主同時服務的系統，系統始終在多個數據中心中運行，數據中心之間自適應地移動負載，透明地處理不同規模的中斷。
05
微信系統高可用的關鍵設計
最初，微信是異步複製，接著是選主同步複製，然後是多主可用。
基於故障切換的系統。包括兩個主要的協議，Raft協議和基於租約Paxos Log。來保證數據的一致性，但對服務的可用性有一定影響。
基於多主的系統。是在可用性方面做的最徹底的系統，它是基於非租約Paxos Log，Google MegaStore以及微信PaxosStore。
多主系統有很多的難點，第一， 海量Paxos Log管理，對存儲引擎的要求很高。第二，代碼假設在一個cas環境中運行。要做到服務隨時可用，對cache和熱點處理的要求很高。同時它對於追流水/恢復流程有時效性的要求。
目前微信的核心數據存儲服務可用性達6個9。整個系統有一個創新的技術點，具體細節我們發表在：
http://www.vldb.org/pvldb/vol10/p1730-lin.pdf
論文相關示例代碼開源：
github.com/tencent/paxosstore。
早期大家對Paxos算法都是認為很難實現的，近兩年逐漸有一些公司開始對這方面有一些分享。上面提到的這個論文是微信PaxosStore的一點創新，貢獻出了一些簡潔的算法實現流程，大家可以很輕鬆的去理解和實現。
06
PaxosStore整體架構
PaxosStore整體架構，如下圖。中間我們會把PaxosStore共識層和計算層、存儲層分離起來，PaxosStore其實是一整套框架，它可以容納不同的共識算法和存儲。
下面是一個存儲引擎。微信的存儲引擎包括很多種，最早是Bitcask模型，現在廣泛使用的是LSM，它可以支持比較多的業務。
最下面是遷移系統、備份系統、路由中心。PaxosStore支持類SQL的filter，format，limit，groupby等能力，單表可以支持億行記錄。下一步，我們可能會根據業務的需求去開展。
07
微信Chubby建設實踐
Chubby是Google一個論文提到的系統，微信技術團隊延伸了這樣一個邏輯，基本上跟它的接口是一樣的。
不管是Google Chubby論文提到的代碼量，還是zookeeper的實際代碼量都很大，但有了PaxosStore之後，根本不需要那麼多的代碼，所以接下來我們的處理也可能會考慮開源。
後來，我們基於PaxosStore也實現了分佈式文件存儲。
08
微信分佈式文件系統
微信分佈式文件系統Namenode 基於PaxosStore，DataNode基於Raft協議。Raft是基於租約機制的完美實現。基於Raft我們可以做到DataNode的強一致寫。另外，它支持文件AppendWrite和隨機讀以及文件回收等功能。
09
微信微服務架構框架
微服務包含了服務定義、服務發現、錯誤重試、監控容災、灰度發佈等一系列面向服務的高級特性的統一框架。中間有一個配置管理和下發的過程，這一塊也是PaxosStore實現的，它可以完全控制代碼的安全性。
下面是一個發佈的過程，因為微信有很多服務器集群，也有一個資源化系統，有可能一個服務會橫跨幾千臺機器，內部是一套BT協議。
然後，我們有一些監控處理，最後我們會有過載保護保護，在系統裡面過載保護是很關鍵的一塊。因為在後臺，當一個請求過來的時候，某些節點產生了一個慢延遲和性能差，就會影響整條鏈路，所以我們會有一個整套的過載保護的實現。
10
協程在微信系統中的應用
大家還記得微信2013年的那一次故障， 我們開始整體優化微信後臺的過載保護能力，也促使我們去提升整個微信後臺的高併發能力。
協程到底是什麼？可以說它是微線程，也可以說它是用戶態線程。協程切換流程其實不復雜，它主要任務是把上下文保存起來。上下文只有兩個部分，第一部分是內存和寄存器，第二部分是棧的狀態。
協程服務，同步編程、異步執行，由於不需要自己設計各種狀態保存數據結構，臨時狀態/變量在一片連續的棧中分配，性能比手寫異步通常要高，重要的一點是編寫併發任務很方便。
以上介紹了微信後臺高可用、數據一致性、微服務、數據存儲等實踐，
作者：許家滔，微信技術架構部後臺總監，專家工程師，多年來伴隨QQ郵箱和微信後臺成長，歷經系統從0到10億級用戶的過程。目前負責微信後臺工作，包括消息，資料與關係鏈，後臺基礎設施等內容。
