1、崔康InfoQ 中國總編輯卷首語對于這本小冊子，大家可能覺得有些意交流，會刊只是一種形式，目前啟動的還包括外。之前 InfoQ 發布的迷你書主要是架構師，現在這本ArchSummit 全球架構架構周報、ArchSummit 互動等，我們將第一時間把有關大會的內容呈現給讀者師峰會會刊又是做什么的？朋友。這是我們今年在運營大會品牌方面的思會刊的基本原則是：“干貨、案例、實用”，本期內容精選了歷屆大會講師有 0到 1 構建互聯網技術架構的案例，這個話題在最近一次 ArchSummit 全球架構師峰會的討論路轉變的嘗試。保持平均每月一期的發布頻率，內容都是精選歷屆 ArchSummit 大會的講師，同

2、時加上對于未來大會籌備的進展通報和講師采訪。希望以這種形式，讓我們群中討論地非常熱烈，大家分別從商業模式、的讀者對大會有一種持續和全面的了解，增強技術選型、流量變現等角度給出了的觀參與感。我們和參會者的關系，不再是一年兩點，相信讀者會從本期會刊中找到值得借鑒的次的短暫交流，而是像朋友一樣，定期的經驗。從 0 到 100 知乎架構變遷史612從無到有：系統的演進25淘寶構架演化實踐32紅包，是怎么扛住一百億次請求的42百花齊放，鋤其九九 的技術坎坷目錄從 0 到 100知乎架構變遷史作者也許很多人還不知道，知乎在規模上是僅次于貼吧和豆瓣的中文互聯網最大的 UGC（用戶生成內容）社區。知乎創業三年

3、來，從 0 開始，到現在已經有了 100 多臺服務器。目前知乎的用戶超過了 1100 萬，每有超過 8000 萬人使用；每的 PV 超過 2.2 億，差不多每秒鐘的動態請求超過 2500。在 ArchSummit 全球架構師峰會上，知乎創始人兼 CTO申帶來了知乎創業三年多來的首次全面技術（）。本文系根據內容整理而成。初期架構選型高，而且社區活躍，團隊成員也比較喜歡。知乎使用的是 Tornado 框架。因為它支持在 2010 年 10 月真正開始動手做知乎這個異步，很適合做實時 Comet 應用，而且簡單輕時，包含申在內，最初只有兩位工程量，學習成本低，再就是有 FriendFeed 的成熟師

4、；到 2010 年 12 月份上線時，工程師是四個。案例，的社區支持。知乎的有個知乎的主力開發語言是 Python。因為 特性，就是希望跟瀏覽器端建立一個長連接，Python 簡單且強大，能夠快速上手，開發效率6ArchSummit 全球架構師峰會會刊從 0 到 100知乎架構變遷史便于實時推送 Feed 和通知，所以 Tornado 比較為解決同步問題，又添加了一個服務器來跑離合適。線，避免對線上服務造成響應延遲。另外，最初整個團隊的精力全部放在功能的為改進內網的吞吐量延遲，還更換了設備，使整個內網的吞吐量翻了 20 倍。開發上，而其他方面，基本上能節約時間、能在 2011 年上半年時，知乎

5、對 Redis 已經很省的最簡單的方法來解決，當然這在后期也帶來了一些問題。依賴。除了最開始的隊列、搜索在用，后來像Cache 也開始使用，單機最初的想法是用云主機，節省成本。知乎成為瓶頸，所以引的第一臺服務器是 512MB 內存的 Linode 主機。入了分片，同時做了一致性。但是上線后，內測受歡迎程度超出預期，知乎團隊是一個很相信工具的團隊，相信很多用戶反饋很慢。網絡延遲比想象工具可以提升效率。工具其實是一個過程，工的要大，特別是國內的網絡不均衡，各地具并沒有所謂的最好的工具，只有最適合的工用戶的情況都不太一樣。這個問題，再加具。而且它是在整個過，隨著整個狀態的上當時要做備案，知乎又回到了

6、買機變化、環境的變化在不斷發生變化的。知乎自己開發或使用過的工具包括 Proling（函數級器找機房的老路上。追蹤請求，分析調優）、Werkzeug（方便調試的買了、找了機房之后又遇到了新的問工具）、Puppet（配置管理）和 Shipit（一鍵上題，服務經常宕掉。當時服務商的內存總是出問題，動不動就重啟。終于有一次宕線或回滾）等。掉起不來了，這時知乎就做了 Web 和數據庫的高可用。創業就是這樣一個情況，永遠不知道日明早醒來的時候會什么樣的問題。知乎最初是邀請制的，2011 年下半年，知乎上線了申請，沒有的用戶也可以通過填寫一些資料申請知乎。用戶量又上了一個臺階，這時就有了一些發的賬戶，需要

7、掃除。日的需求提上日程。這個日必須支持分布式收集、集中、實時、可訂閱和簡單等特性。當時調研了一些開源系統，比如 Scribe 總體不錯，但是這是當時那個階段的架構圖，Web 和數據不支持訂閱。Kafka 是 Scala 開發的，但是團隊庫都做了主從。當時的圖片服務托管在又拍云在 Scala 方面積累較少，Flume 也是類似，而且上。除了主從，為了性能更好還做了讀寫分離。比較重。所以開發團隊選擇了開發一個日ArchSummit 全球架構師峰會會刊7從 0 到 100知乎架構變遷史Kids（Kids Is Data Stream）。顧名思具體細節如下圖所示：義，Kids 是用來匯集各種數據流的。

8、知乎還基于 Kids 做了一個 Web 小工具 Kids 參考了 Scribe 的思路。Kdis 在每臺服（Kids Explorer），支持實時看線上日志，現在已務器上可以配置成 Agent 或 Server。Agent 直經成為調試線上問題最主要的工具。Kids 已經開源，放到了接接受來自應用的消息，把消息匯集之后，可上。以打給下一個 Agent 或者直接打給中心 Server。訂閱日志時，可以從 Server 上獲取，也可以從驅動的架構中心節點的一些 Agent 上獲取。知乎這個有一個特點，最早在添加一個后，后續的操作其實只有更新通知、更新動態。但是隨著整個功能的增加，又多出了一些更新索

9、引、更新計數、內容等操作，后續操作五花八門。如果按照傳統方式，維護邏輯會越來越龐大，維護性也會非常差。這種場景很適合驅動方式，所以開發團隊對整個架構做了調整，做了驅動的架構。這時首先需要的是一個消息隊列，它應該可以獲取到各種各樣的，而且對一致性有8ArchSummit 全球架構師峰會會刊從 0 到 100知乎架構變遷史很高的要求。這個需求，知乎開發了一個頁面渲染優化叫 Sink 的小工具。它拿到消息后，先做本地的知乎在 2013 年時每天有上百萬的 PV，頁保存、持久化，然后再把消息分發出去。如果面渲染其實是計算密集型的，另外因為要獲取那臺掛掉了，重啟時可以完整恢復，確保數據，所以也有 IO

10、密集型的特點。這時開發團丟失。然后它通過 Miller 開發框架，消息隊就對頁面進行了組件化，還升級了數據獲取把消息放到任務隊列。Sink 更像是串行消息訂機制。知乎按照整個頁面組件樹的結構，自上閱服務，但任務需要并行化處理，Beanstalkd 就而下分層地獲取數據，當上層的數據已經獲取派上了用場，由其對任務進行全周期管理。架了，下層的數據就不需要再下去了，有幾層基構如下圖所示：本上就有幾次數據獲取。結合這個思路，知乎做了一套模板渲染開發框架ZhihuNode。經歷了一系列改進之后，頁面的性能大幅度提升。問題頁面從 500ms 減少到 150ms，Feed 頁面從 1s 減少到 600ms。

11、面向服務的架構（SOA）隨著知乎的功能越來越龐雜，整個系統也舉例而言，如果現在有用戶回答了問題，越來越大。知乎是怎么做的服務化呢？首先系統會把問題寫到 MySQL 里面，把消息首先需要一個最基本的 RPC 框架，RPC 框塞到 Sink，然后把問題返回給用戶。Sink 通過架也經歷了好幾版演進。Miller 把任務發給 Beanstalkd，Worker可第一版是 Wish，它是一個嚴格定義序列以找到任務并處理。化的模型。傳輸層用到了 STP，這是寫的最開始上線時，每秒鐘有 10 個消息，然后很簡單的傳輸協議，跑在 TCP 上。一開始用有 70 個任務產生。現在每秒鐘有 100 個，的還不錯，

12、因為一開始只寫了一兩個服務。但有 1500 個任務產生，就是通過現在的驅動是隨著服務增多，一些問題開始出現，首先是架構支撐的。ProtocolBuffer 會些描述代碼，很冗長，ArchSummit 全球架構師峰會會刊9從 0 到 100知乎架構變遷史放到整個顯得很。另外嚴格的定義使單的定義服務的名字就可以找到服務在哪臺機其不便使用。這時有位工程師開發了新的 RPC器上。同時，知乎也有相應的調優的工具，基框架Snow。它使用簡單的 JSON 做數據序于 Zipkin 開發了的 Tracing 系統。按照調用關系，知乎的服務分成了 3 層：列化。但是松散的數據定義面對的問題是，比如說服務要去升級

13、，要改寫數據結構，很難知聚合層、內容層和基礎層。按屬性又可以分成3 類：數據服務、邏輯服務和通道服務。數據道有哪幾個服務在使用，也很難通知它們，往往錯誤就發生了。于是又出了第三個RPC 框架，服務主要是一些要做特殊數據類型的，比寫 RPC 框架的工程師， 希望結合前面兩個框如圖片服務。邏輯服務的是 CPU 密集、計架的特點，首先保持 Snow 簡單，其次需要相算密集的操作，比如格式的定析等。對嚴格的序列化協議。這一版本引入了 Apache通道服務的特點是沒有，是做一個轉Avro。同時加入了特別的機制，在傳輸層和發，比如說 Sink。序列化協議這一層都做成了可插拔的方式，既這是引入服務化之后整體

14、的架構。可以用 JSON，也可以用 Avro，傳輸層可以用中還介紹了基于AngularJS 開發知乎專STP，也可以用二進制協議。欄的新實踐，感的讀者可以。再就是搭了一個服務發現，只需要簡10ArchSummit 全球架構師峰會會刊從 0 到 100知乎架構變遷史“ArchSummit 會員群”是一個基于運營的高端技術社區。群內定期舉行線上線下專家講座、話題討論，專注于“、交流、成長”。添加群主 cuikang10，申請入群。講師介紹：申 , 現任知乎創始人兼 CTO。職業經歷中大部分時間在創業，在創辦知乎和上一家公司 Meta 搜索之間，曾在愛奇藝短期擔任高級工程師；在 Meta 搜索創業期

15、間擔任技術總監；這之前擔任過 Icebreaker 高級工程師。申最早專業為汽車設計制造，時期轉入計算機科學與技術專業。從多年的創業經歷中磨練出全棧工程師的綜合實踐經驗，從設計到前后端開發，再到服務器部署運維。ArchSummit 全球架構師峰會會刊11從無到有：系統的演進作者作者介紹：，高級工程師，接入系統，一直從事系統設計開發，早期涉足傳統行業軟件，后投身互聯網。作為最早的開發之一，了從零開始到逐漸發展壯大的過程從無到有2011.1.21正式發布。這一天距離圖 1項目啟動日約為 2。就在這 2消息模型里，微圖 1 展示了這一消息模型，消息被發出后，信從無到有，大家可能會好奇這期間會先在臨時

16、；為使接收者能更快接收做的最重要的事情是什么？到消息，會推送消息通知給接收者；最后客戶應該是以下三件事：端主動到服務器收取消息。1. 確定了的消息模型2. 制定了數據同步協議起初是一個通訊工具，作為通訊由于用戶的帳戶、人和消息等數據都工具最的功能是收發消息。團隊源于在服務器，如何將數據同步到客戶端就成廣團隊，消息模型跟郵箱的郵件模型也很有了很關鍵的問題。為簡化協議，我們決定通過淵源，都是轉發。一個統一的數據同步協議來同步用戶所有的基12ArchSummit 全球架構師峰會會刊從無到有：系統的演進3. 定型了礎數據。架構最初的方案是客戶端一個本地數據的快照 (Snapshot)，需要同步數據時，

17、將 Snapshot帶到服務器，服務器通過計算 Snapshot 與服務器數據的差異，將差異數據發給客戶端，客戶端再保存差異數據完成同步。不過這個方案有兩個問題：一是 Snapshot 會隨著客戶端數據的增多變得越來越大，同步時流量開銷大；二是客戶端每次同步都要計算 Snapshot，會帶來額圖 2外的性能開銷和實現復雜度。系統架構幾 經 討 論 后， 方 案 改 為 由 服 務 計 算 使用三層架構：接入層、邏輯層Snapshot，在客戶端同步數據時跟隨數據一起和層。下發給客戶端，客戶端無需理解 Snapshot，只接入層提供接入服務，包括長連接入服需起來，在下次數據同步數據時帶上即可。務和

18、短連接入服務。長連接入服務同時同時，Snapshot 被設計得非常精簡， 是若干個支持客戶端主動發起請求和服務器主動Key-Value 的組合，Key 代表數據的類型，Value發起推送；短連接入服務則只支持客戶代表給到客戶端的數據的最新版本號。Key 有三端主動發起請求。個，分別代表：帳戶數據、人和消息。這個邏輯層包括業務邏輯服務和基礎邏輯服同步協議的一個額外好處是客戶端同步完數據務。業務邏輯服務封裝了業務邏輯，是后，不需要額外的 ACK 協議來確認數據收取成提供給客戶端調用的 API。基功，同樣可以保證丟數據：只要客戶端拿最礎邏輯服務則抽象了更底層和通用的業新的 Snapshot 到服務器

19、做數據同步，服務器即務邏輯，提供給業務邏輯服務。可確認上次數據已經同步完成，可以執行后層包括數據服務和數據服續操作，例如清除暫存在服務的消息等等。服務通過 MySQL 和 SDB務。數據此后，精簡方案、減少流量開銷、盡量由中廣泛使用的 Key-Table（早期服務器完成較復雜的業務邏輯、降低客戶端實數據系統）等底層系統來持久現的復雜度就作為重要的指導原則，持續影響化用戶數據。數據服務適配并路由著后續的設計開發。記得有個比較經典的數據請求到不同的底層數據服案例是：我們在1.2 版實現了群聊功能，但務，面向邏輯層提供結構化的數據服務。為了保證新舊版客戶端間的群聊體驗，我們通比較特別的是，每一種不同

20、類過服務器適配，讓 1.0 版客戶端也能參與群聊。ArchSummit 全球架構師峰會會刊13從無到有：系統的演進型的數據都使用單獨的數據服務和用戶數是臨時從數據庫統計的，數是數據服務，例如帳戶、消息和從日志里提取出來的，這些數據通過每個小時人等等都是的。運行一次的（這個也是當天臨時加的）主要使用 C+。服務使用統計出來，然后自動發郵件到郵件組。還有其Svrkit 框架搭建，服務之間通過同步 RPC 進行他各種業務數據也通過郵件進行發布，可以說通訊。郵件是初期最重要的數據門戶。2011.1.21 當天最高并發數是 491，而今天這個數字是 4 億。小步慢跑在發布后的 4 個多月里，我們經歷了發

21、布后火爆的驚喜，也經歷了隨后一直不溫不火的困惑。圖 3 Svrkit 框架這一時期，做了很多旨在增加用戶好友量，讓用戶聊得起來的功能。打通騰訊Svrkit 是另一個廣就已經存在的高性私信、群聊、工作郵箱、/ 郵箱好友推薦等能 RPC 框架，當時尚未廣泛使用，但在后等。對于而言，比較重要的變化就是這些臺卻大放異彩。作為基礎設施中最重功能催生了對異步隊列的需求。例如，私要的一部分，Svrkit 這幾年一直不斷在進化。我信需要跟外部門對接，不同系統間的處理耗時們使用 Svrkit 構建了數以千計的服務模塊，提和速度不一樣，可以通過隊列進行緩沖；群聊供數萬個服務接口，每天 RPC 調用次數達幾是耗時操

22、作，消息發到群后，可以通過異步隊十萬億次。列來異步完成消息的擴散寫等等。這三件事影響深遠，乃至于 5 年后的今天，我們仍繼續沿用最初的架構和協議，甚至還可以支持當初 1.0 版的客戶端。這里有一個經驗教訓運營支撐系統真的很重要。第一個版本的是倉促完成的，當時只是完成了基礎業務功能，并沒有配圖 4 單聊和群聊消息過程套的業務數據統計等等。我們在開放后，一時間竟沒有業務頁面和數據曲線可以看，圖 4 是異步隊列在群聊中的應用。的14ArchSummit 全球架構師峰會會刊從無到有：系統的演進群聊是寫擴散的，也就是說發到群里的一條消有個廣為流傳的關于 開發的傳 歷經 4，前后做了 30 多個版息會給群

23、里的每個人都存一份（消息索引）。為奇什么不是讀擴散呢？有兩個：本迭代才最終成型。其實還有一個鮮為人知的群的人數不多，群人數上限是 10（后來故事那時候因為比較短缺，后逐步加到 20、40、100，目前是 500），臺長時間只有 1 位開發。擴散的成本不是太大，不像，有成穩定性的要求千上萬的粉絲，后，每粉絲用戶多了，功能也多了，模塊數和機都存一份的話，一個是效率太低，另一器量在不斷翻番，緊跟著的還有各種故障。個量也會大很多；幫助我們順利度過這個階段的，是以下幾消息擴散寫到每個人的消息（消息個舉措：收件箱）后，接收者到同步數據時，1. 極簡設計只需要檢查收件箱即可，同步邏輯雖然各種需求撲面而來，但

24、我們每個實現跟單聊消息是一致的，這樣可以統一數方案絲不茍完成的。實現需求最大的困據同步流程，實現起來也會很輕量。難不是設計出一個方案并實現出來，而是需要異步隊列作為數據交互的一種重要模在若干個可能的方案中，甄選出最簡單實用的式，成為了同步RPC 服務調用之外的補充，那個。在被大量使用。這中間往往需要經過幾輪思考討 論的迭代過程，謀定而后動有不少好快速成長處，一方面可以避免做出華而不實的過度設計，的飛速發展是從 2.0 版開始的，這個版提升效率；另一方面，通過詳盡的討論出來的看似簡單的方案，細節考究，往往是可靠性最本發布了語音聊天功能。之后用戶量急速增長，2011.5 用戶量破 100 萬、20

25、11.7 用戶量好的方案。破 1000 萬、2012.3用戶數1 億。2.小做伴隨著喜人成績而來的，還有一堆幸福的邏輯層的業務邏輯服務最早只有一個服務煩惱。模塊（我們稱之為 mmweb），囊括了所有提供 業務快速迭代的給客戶端的 API，甚至還有一個完整的微發布時功能很簡單，主要功能就是發信官網。這個模塊架構類似 Apache，由一個消息。不過在發語音之后的幾個版本里迅速推CGI 容器（CGIHost）和若干 CGI 組成（每個出了離線消息、查看附近的人、CGI 即為一個 API），不同之處在于每個 CGI 都搖一搖、漂流瓶和等等功能。ArchSummit 全球架構師峰會會刊15從無到有：系統

26、的演進是一個動態庫 so，由 CGIHost 動態加載。千億次。在 mmweb 的 CGI 數量相對較少的時候，除了 API 服務外，其他服務模塊也遵這個模塊的架構完全能滿足要求，但當功能迭循“小做”這一實踐準則，服代加快，CGI 量不斷增多之后，開始出現問題：務模塊數從發布時的約 10 個模塊，迅速上1) 每個 CGI 都是動態庫，在某些 CGI 的漲到數百個模塊。共用邏輯的接口定義發生變化時，不同時期更3. 業務新上線的 CGI 可能使用了不同版本的邏輯接口這一時期，故障很多。比故障更麻煩定義，會導致在運行時出現詭異結果或者進程crash，而且非常難以的是，因為的，經常有些故障我們沒；法第

27、一時間發現，造成故障影響面被放大。2) 所有 CGI 放在一起，每次大版本發布上的一方面是因為在快速迭代過程線，從測試到灰度再到全面部署完畢，中，重視功能開發，輕視了業務的重要性，個很漫長的過程，幾乎所有開發都會有故障一直是兵來將擋水來土掩；另一方面是被同時卡在這個環節，非常影響效率；基礎設施對業務邏輯的支持度較弱。基礎3) 新增的不太重要的CGI 有時穩定性不好，和 Svrkit 服務運行狀某些異常分支下會 crash，導致 CGIHost 進程無設施提供了態的。這個是每臺、每個服務標配的，法服務，發消息這些重要 CGI 受影響沒法運行。于是我們開始嘗試使用一種新的 CGI 架無需額外開發，

28、但是業務邏輯的就要麻煩得多了。當時的業務邏輯是通過業務邏輯構Logicsvr。需要 4 步：Logicsvr 基于Svrkit 框架。將Svrkit 框架和統計功能來做的，實現一個1) 申請日志上報；CGI 邏輯通過靜態編譯生成可直接使用 HTTP2) 在業務邏輯中加入日志上報點，日志會的 Logicsvr。mmweb 模塊拆分為 8被每臺上的 agent 收集并上傳到統計中心；個不同服務模塊。拆分原則是：實現不同業務3) 開發統計代碼；功能的 CGI 被拆到不同 Logicsvr，同能但4) 實現統計頁面。是重要程度不一樣的也進行拆分。例如，作為功能的消息收發邏輯，就被拆為 3 個服務可以想

29、象，這種費時費力的模式會反過來降低開發對加入業務的積極性。于模塊：消息同步、本和語音消息、發圖片是有一天，我們去公司內的標桿即通和消息。個的二進制程序， （）取經了，發現解決方案出乎意料地每個 Logicsvr簡單且強大：可以部署、上線。時至今日，后1) 故障報告臺有數十個 Logicsvr，提供了數百個 CGI 服務，之前每次故障后，是由 QA 牽頭出一份故部署在數千臺服務器上，客戶端量幾16ArchSummit 全球架構師峰會會刊從無到有：系統的演進4. KVSvr障報告，著重點是對故障影響的評估和故障定級。新的做法是每個故障不分大小，開發每個服務的存需要徹底復盤故障過程，然后商定解決方案

30、，儲模塊，是相互的。每個服務一補充出一份詳細的技術報告。這份報告側重于：個業務模塊和一個底層模塊組成。業如何避免同類型故障再次發生、提高故障主動務層業務邏輯層和底層， 提供發現能力、縮短故障響應和處理過程。基于 RPC 的數據接口；底層有兩類：2) 基于 ID-Value 的業務無關的告警SDB 和 MySQL。體系SDB 適用于以用戶 UIN(uint32_t) 為 Key 的數據，比方說消息索引和人。優點是性能高，在可靠性上，提供基于異步流水同步的 Master-Slave 模式，Master 故障時，Slave 可以提供讀數據服務，無法寫入新數據。由于賬號為字母 + 數字組合，無法直接作

31、為 SDB 的 Key，所以帳號數據并非使圖 5 基于 ID-Value 的告警體系用 SDB，而是用 MySQL的。MySQL 也使體系實現思路非常簡單，提供了 2 個用基于異步流水的 Master-Slave 模式。API，業務代碼在共享內存中對某個第 1 版的帳號服務使用 Master-SlaveID 進行設置 Value 或累加 Value 的功能。每臺各 1 臺。Master 提供讀寫功能，Slave 不提供上的 Agent 會定時將所有 ID-Value 上報到服務，僅用于備份。當 Master 有故障時，人中心，中心對數據匯總入庫后就可以工切讀服務到 Slave，無法提供寫服務。

32、為提通過統一的頁面輸出曲線，并通過預升效率，我們還在業務模塊中加入了先配置的規則產生。memcached 提供 Cache 服務，減少對底層對于業務代碼來說，只需在要被的業。調用一下API，并配置好告警條務流第 2 版的帳號服務還是 Master-Slave件即可。這就極大地降低了開發的成各 1 臺，區別是 Slave 可以提供讀服務，但有本，我們補全了各種項，讓我們能主動及可能讀到臟數據，因此對一致性要求高的業務時地發現問題。新開發的功能也會預先加入相Master。邏輯，例如和登錄邏輯只關項，以便在少量灰度階段就能直接通過當 Master 有故障時，同樣只能提供讀服務，無曲線了解業務是否符合

33、預期。法提供寫服務。第 3 版的帳號服務采用 1 個 Master 和ArchSummit 全球架構師峰會會刊17從無到有：系統的演進多個 Slave，解決了讀服務的水平擴展能力。平臺化第 4 版的帳號服務底層采用多個2011.8舉行大運會。推出“微Master-Slave 組， 每 組 由 1 個 Master 和 多 個 信大運志愿者服務中心” 服務號，Slave 組成，解決了寫服務能力不足時的水平擴用戶可以搜索“szdy”將這個服務號加為好展能力。友，獲取大會相關的資訊。當時對“szdy”最后還有個未解決的問題：單個 Master-做了特殊處理， 用戶搜索時， 會隨機返回Slave 分組

34、中，Master 還是單點，無法提供實時“szdy01”，“szdy02”，“szdy10”這 10 個微的寫容災，也就意味著無法消除單點故障。另信號中的 1 個，每個號背后一個志愿外 Master-Slave 的流水同步延時對讀服務有很者在服務。大影響，流水出現較大延時會導致業務故障。2011.9“微成都”落戶平臺，用戶于是我們尋求一個可以提供高性能、具備讀寫可以搜索“wechengdu”加好友，成都市民還可水平擴展、沒有單點故障、可同時具備讀寫容以在“附近的人”看到這個號，我們在給災能力、能提供強一致性保證的底層解決這個帳號做了一些特殊邏輯，可以支持自方案，最終 KVSvr 應運而生。動回

35、復用戶發的消息。KVSvr 使用基于 Quorum 的分布式數據強這種需求越來越多，我們就開始做一個媒一致性算法，提供 Key-Value/Key-Table 模型 體平臺，這個平臺后來從分出，演變的服務。傳統 Quorum 算法的性能不高，成了公眾平立發展壯大，開始了微KVSvr 創造性地將數據的版本和數據本身做了信的平臺化。除公眾平臺外，后區分，將 Quorum 算法應用到數據的版本的協臺的還陸續出現了支付平臺、硬件平商，再通過基于流水同步的異步數據提供臺等等一系列平臺。了數據強一致性保證和極高的數據寫入性能，另外 KVSvr 天然具備數據的 Cache 能力，可以提供高效的性能。KVSv

36、r 一舉解決了我們當時迫切需要的無單點故障的容災能力。除了第 5 版的帳號服務外，很快所有 SDB 底層模塊和大部分MySQL 底層模塊都切換到 KVSvr。隨著業圖 6平臺務的發展，KVSvr 也不斷在進化著，還配合業務需要衍生出了各種定制版本。現在的 KVSvr仍然作為，發揮著舉足輕重的作用。18ArchSummit 全球架構師峰會會刊從無到有：系統的演進Master-Master 架構下數據的一致性是個很走出國門大的問題。兩個數據中心之間是個高延時的網走出國門的嘗試開始于 3.0 版本。從這絡，意味著在數據中心之間直接使用 Paxos 算個版本開始，逐步支持繁體、英文等多種法、或直接部署

37、基于 Quorum 的 KVSvr 等看似語言文字。不過，真正標志性的事情是第一個一勞永逸的方案不適用。海外數據中心的投入使用。最終我們選擇了跟 Yahoo! 的 PNUTS 系統1. 海外數據中心類似的解決方案，需要對用戶集合進行切分，國內用戶以國內上海數據中心為 Master，所有海外數據中心的是一個自治的系統，數據寫操作必須回到國內數據中心完成；海外也就是說具備完整的功能，能夠不依賴于國內用戶以海外數據中心為 Master，寫操作只能在數據中心。海外數據中心進行。從整體上看，這是一1) 多數據中心架構個 Master-Master 的架構，但細到一個具體用戶的數據，則是 Master-S

38、lave 模式，每條數據只能在用戶歸屬的數據中心可寫，再異步到其他數據中心。圖 7 多數據中心架構系統自治對于無狀態的接入層和邏輯層來圖 8 多數據中心的數據 Master-Master 架構說很簡單，所有服務模塊在海外數據中心部署一套就行了。3) 數據中心間的數據一致性但是層就有很煩了我們需要這個 Master-Master 架構可以在不同數據中確保國內數據中心和海外數據中心能，心間實現數據最終一致性。如何保證業務邏輯但不是兩套的系統各自部署，各玩各的，在這種數據弱一致性保證下出現問題？而是一套業務功能可以完全互通的系統。因此這個問題可以被分解為 2 個子問題：我們的任務是需要保證兩個數據中

39、心的數據一* 用戶的數據致性，另外 Master-Master 架構是個必選項，也用戶可以滿世界跑，那是否用戶就近即兩個數據中心都需要可寫。接入數據中心就對業務處理流程有很大影響。2) Master-Master架構ArchSummit 全球架構師峰會會刊19從無到有：系統的演進如果就近接入，同時還要保證數據一致性供了全局唯一的號申請服務來解決這一問不影響業務，就意味著要么用戶數據的 Master題，所有數據中心通過這個服務申請號。需要可以動態的改變；要么需要對所有業務邏這種需要特殊處置的場景極少，帶來太大輯進行仔細梳理，嚴格區分本數據中心和跨數問題。4) 可靠的數據同步據中心用戶的請求，將請

40、求路由到正確的數據中心處理。數據中心之間有大量的數據同步，數據是考慮到上述問題會帶來很高昂的實現和維否能夠達到最終一致，取決于數據同步是否可護的復雜度，我們限制了每個用戶只能接入其靠。為保證數據同步的可靠性，提升同步的可用性，我們又開發一個基于 Quorum 算法的隊歸屬數據中心進行操作。如果用戶發生漫游，列組件，這個組件的每一組由 3 機其漫游到的數據中心會自動引導用戶重新連回服務組歸屬數據中心。成。與一般隊列的不同之處在于，這個組件對隊列寫入操作進行了大幅簡化，3 機這樣用戶數據的一致性問題就迎服務不刃而解了，因為所有操作被限制在歸屬數據中需要相互通訊，每個上的數據都是順序寫，執行寫操作時

41、在 3 機能寫入2 份即為寫入心內，其數據是有強一致性保證的。此外，還有額外的好處：用戶的數據（如：消息和；若失敗，則換另外一組再試。因此這個人等）不需要在數據中心間同步，這就大隊列可以達到極高的可用性和寫入性能。每個大降低了對數據同步的帶寬需求。數據中心將需要同步的數據寫入本數據中心的 用戶其他用戶的數據同步隊列后，由其他數據中心的數據重放服務由于不同數據中心之間業務需要互通，用將數據拉走并進行重放，達到數據同步的目的。戶會使用到其他數據中心用戶創建的數據。例2. 網絡如，參與其他數據中心用戶創建的群聊，查看海外數據中心建設周期長，投入大，其他數據中心用戶的等。只在和有兩個海外數據中心。但世

42、仔細分析后可以發現，大部分場景下對數界那，即便是這兩個數據中心，也還是沒據一致性要求其實并不高。用戶稍遲些才見到法輻射全球，讓各個角落的用戶都能享受到暢被加入某個其他數據中心用戶建的群、稍快的服務體驗。遲些才見到某個好友的動態更新其實并通過在海外實際對比測試發現，客戶帶來什么問題。在這些場景下，業務邏輯端在發消息等一些主要使用場景與主要競品有直接本數據中心的數據。不小的差距。為此，我們跟公司的架構平臺部、當然，還是有些場景對數據一致性要求很網絡平臺部和國際業務部等兄弟部門一起合作，高。比方說給設置號，而號是需海外數據中心，在世界各地精心選址建設要在整個帳號體系里保證唯一的。我們提20ArchS

43、ummit 全球架構師峰會會刊從無到有：系統的演進了數十個 POP 點（包括信令點和圖片 CDN故障，在 13 分鐘的時間里，消息收發幾乎網絡）。另外，通過對移動網絡的深入分析和研完全不可用。在對故障進行分析時，我們發現究，我們還對的通訊協議做了大幅優化。一個消息系統里一個模塊三個互備的服務最終在對比測試中趕上并超過了主要的實例署在同一機房。該機房的交換機故障競品。導致這個服務整體不可用，進而消息跌零。這個服務模塊是最早期（那個時候規模小，大部分服務署在一個數據園區里）的模塊，服務基于 3 機冗余設計，年復一年可靠地運行著，以至于大家都完全忽視了這1. 三園區容災個問題。2013.7.22發生

44、了有史以來最大規模的為解決類似問題，三園區容災應運而生，等服務出現長達 5 個故障，消息收發和目標是將上海數據中心的服務均勻部署到 3 個小時的故障，故障期間消息量跌了一半。故障物理上的數據園區，在任意單一園區整體的起因是上海數據中心一個園區的主光纖被挖故障時，仍能提供無損服務。斷，近 2 千臺服務器不可用，整個上海數1) 同時服務據中心（當時國內只有這一個數據中心）的服傳統的數據中心級災備方案是“兩地三中務癱瘓。心”，即同城有兩個互備的數據中心，異地再建故障時，我們曾嘗試把接入到故障園區的設一個災備中心，這三個數據中心很可能用戶切走，但收效甚微。雖然數百個模塊只有一個在提供服務，故障時再將業

45、務流都做了容災和冗余設計，單個服務模塊看起來量切換到其他數據中心。這里的主要問題是災沒有單點故障問題；但整體上看，無數個服務備數據中心無實際業務流量，在主數據中心故實例散布在數據中心各個機房的 8 千多臺服務障時未必能正常切換到災備中心，并且在器內，各服務 RPC 調用復雜，呈網狀結構，再大量的備份不提供服務，也會造成大量的加上缺乏系統級的和容災驗證，最終導致浪費。故障無法主動恢復。在此之前，我們知道單個三園區容災的是三個數據園區同時提，但沒人知道 2服務出現單機故障不供服務，因此即便某個園區整體故障，那另外千臺服務器同時不可用時，整個系統會出現什兩個園區的業務流量也只會各增加 50%。反么不

46、可控的狀況。過來說，只需讓每個園區的服務器跑在容其實在這個故障發生之前 3，我們已量上限的 2/3，保留 1/3 的容量即可提供無損經在著手解決這個問題。當時上海數據中心內的容災能力，而傳統“兩地”則有多得網交換機異常，導致出現一個出乎意料的多的服務器被閑置。此外，在三個園ArchSummit 全球架構師峰會會刊21從無到有：系統的演進區同時對外服務，因此我們在故障時，需要解實戰演習，單一園區上千臺服務，檢驗容決的問題是“怎樣把業務流量切到其他數據園災效果是否符合預期。特別地，為了避免隨著區？”，而不是“能不能把業務流量切到其他時間的推移某個服務模塊因為某次更新就數據園區？”，前者顯然是更容易

47、解決的一個不再支持三園區容災了，我們還搭建了一套容問題。災撥測系統，每天對所有服務模塊選取某個園2) 數據強一致區的服務主動掉，自動檢查服務整體失敗三園區容災的關鍵是模塊需要把數量是否發生變化，實現對三園區容災效果的持據均勻分布在 3 個數據園區，同一份數據要在續檢驗。不同園區有 2 個以上的一致的副本，這樣才能2. 性能優化保證任意單一園區出災后，可以不中斷地提供之前我們在業務迅速發展之時，優先支撐無損服務。由于大部分模塊都使用業務功能快速迭代，性能問題無暇兼顧，比較KVSvr，這樣解決方案也相對簡單高效將KVSvr 的每 1 組都均勻部署在 3 個園區里。粗放的“先扛住再優化”的海量之道。

48、2014 年開始大幅縮減運營成本，性能優化就被3) 故障時自動切換提上了日程。三園區容災的另一個難點是對故障服務的我們基本上對大部分服務模塊的設計和實自動和自動切換。即要讓業務邏輯服務模現都進行了重新 review，并進行了有性的塊能準確識別出某些下游服務實例已經無法訪優化，這還是可以節約出不少的。但問，然后迅速自動切到其他服務實例，避免被更有效的優化措施是對基礎設施的優化，具體拖死。我們希望每個業務邏輯服務可以在不借的說是對 Svrkit 框架的優化。Svrkit 框架被廣泛助外部輔助信息（如建設中心節點，由中心節應用到幾乎所有服務模塊，如果框架層面能把點下發各個業務邏輯服務的健康狀態）的情

49、況使用到極致，那肯定是事半功倍的。下，能自行決策迅速掉有問題的服務實例，結果還真的可以，我們在基礎設施里加入自動把業務流量分散切到其他服務實例上。另了對協程的支持，重點是這個協程組件可以不外，我們還建設了一套手工操作的全局系破壞原來的業務邏輯代碼結構，讓我們原有代統，可以在大型網絡故障時，由人工介入碼中使用同步 RPC 調用的代碼不做任何修改，掉某個園區所有的，迅速將業務流量分散就可以直接通過協程異步化。Svrkit 框架直接到其他兩個數據園區。集成了這個協程組件，然后美好的事情發生了，4) 容災效果檢驗原來單實例最多提供上百并發請求處理能力的三園區容災是否能正常發揮作用還需要進服務，在重編上

50、線后，轉眼間就能提供上千并行實際的檢驗，我們在上海數據中心和海外的發請求處理能力。Svrkit 框架的底層實現在這一數據中心完成三園區建設后，進行了數次22ArchSummit 全球架構師峰會會刊從無到有：系統的演進時期也做了全新的實現，服務的處理能力大幅方案是，用戶登錄后，會下發一個票提高。據給客戶端，客戶端每次請求帶上票據，請求在服務的整個處理鏈條中，所有對數3. 防雪崩據服務的，都會被校驗票據是否合法，非以來都不太擔心某個服務實例出法請求會被拒絕，從而保障用戶隱私數據只能現故障，導致這個實例完全無法提供服務的問用戶通過的客戶端發起操作來。題，這個在服務的容災體系里可以被處理得很好。最擔心的是雪崩：某個服務因為某些新的出現過載，導致請求處理時間被大大拉長。于是服務吞吐量下降，大量請求積壓在服務的1.調度系統請求隊列太長時間了，導致這個服務的上游服務出現超時。更倒霉的是上游服務還經常有成千的服務模塊，部署在全球會重試，然后這個過載的服務僅有的一點處理數以萬計的服務器上，一直依靠人工管理。此能力都在做無用功（即處理完畢返回結果時，外，主要是提供實時服務，每天調用端都已超時放棄），終于這個過載的服務徹的服務器占用在業務和低谷時相差很底。最糟糕的情況是上游服務每個請求大，在業務低谷時計算被白白浪費；另一著 RPC 調用鏈一級級往都耗時那么久，方面，很多離線的大