各種書技術(shù)大本營(yíng)archsummit

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

2、時(shí)加上對(duì)于未來(lái)大會(huì)籌備的進(jìn)展通報(bào)和講師采訪。希望以這種形式，讓我們?nèi)褐杏懻摰胤浅崃遥蠹曳謩e從商業(yè)模式、的讀者對(duì)大會(huì)有一種持續(xù)和全面的了解，增強(qiáng)技術(shù)選型、流量變現(xiàn)等角度給出了的觀參與感。我們和參會(huì)者的關(guān)系，不再是一年兩點(diǎn)，相信讀者會(huì)從本期會(huì)刊中找到值得借鑒的次的短暫交流，而是像朋友一樣，定期的經(jīng)驗(yàn)。從 0 到 100 知乎架構(gòu)變遷史612從無(wú)到有：系統(tǒng)的演進(jìn)25淘寶構(gòu)架演化實(shí)踐32紅包，是怎么扛住一百億次請(qǐng)求的42百花齊放，鋤其九九 的技術(shù)坎坷目錄從 0 到 100知乎架構(gòu)變遷史作者也許很多人還不知道，知乎在規(guī)模上是僅次于貼吧和豆瓣的中文互聯(lián)網(wǎng)最大的 UGC（用戶生成內(nèi)容）社區(qū)。知乎創(chuàng)業(yè)三年

3、來(lái)，從 0 開始，到現(xiàn)在已經(jīng)有了 100 多臺(tái)服務(wù)器。目前知乎的用戶超過(guò)了 1100 萬(wàn)，每有超過(guò) 8000 萬(wàn)人使用；每的 PV 超過(guò) 2.2 億，差不多每秒鐘的動(dòng)態(tài)請(qǐng)求超過(guò) 2500。在 ArchSummit 全球架構(gòu)師峰會(huì)上，知乎創(chuàng)始人兼 CTO申帶來(lái)了知乎創(chuàng)業(yè)三年多來(lái)的首次全面技術(shù)（）。本文系根據(jù)內(nèi)容整理而成。初期架構(gòu)選型高，而且社區(qū)活躍，團(tuán)隊(duì)成員也比較喜歡。知乎使用的是 Tornado 框架。因?yàn)樗С衷?2010 年 10 月真正開始動(dòng)手做知乎這個(gè)異步，很適合做實(shí)時(shí) Comet 應(yīng)用，而且簡(jiǎn)單輕時(shí)，包含申在內(nèi)，最初只有兩位工程量，學(xué)習(xí)成本低，再就是有 FriendFeed 的成熟師

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

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

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

7、掃除。日的需求提上日程。這個(gè)日必須支持分布式收集、集中、實(shí)時(shí)、可訂閱和簡(jiǎn)單等特性。當(dāng)時(shí)調(diào)研了一些開源系統(tǒng)，比如 Scribe 總體不錯(cuò)，但是這是當(dāng)時(shí)那個(gè)階段的架構(gòu)圖，Web 和數(shù)據(jù)不支持訂閱。Kafka 是 Scala 開發(fā)的，但是團(tuán)隊(duì)庫(kù)都做了主從。當(dāng)時(shí)的圖片服務(wù)托管在又拍云在 Scala 方面積累較少，F(xiàn)lume 也是類似，而且上。除了主從，為了性能更好還做了讀寫分離。比較重。所以開發(fā)團(tuán)隊(duì)選擇了開發(fā)一個(gè)日ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊7從 0 到 100知乎架構(gòu)變遷史Kids（Kids Is Data Stream）。顧名思具體細(xì)節(jié)如下圖所示：義，Kids 是用來(lái)匯集各種數(shù)據(jù)流的。

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

9、引、更新計(jì)數(shù)、內(nèi)容等操作，后續(xù)操作五花八門。如果按照傳統(tǒng)方式，維護(hù)邏輯會(huì)越來(lái)越龐大，維護(hù)性也會(huì)非常差。這種場(chǎng)景很適合驅(qū)動(dòng)方式，所以開發(fā)團(tuán)隊(duì)對(duì)整個(gè)架構(gòu)做了調(diào)整，做了驅(qū)動(dòng)的架構(gòu)。這時(shí)首先需要的是一個(gè)消息隊(duì)列，它應(yīng)該可以獲取到各種各樣的，而且對(duì)一致性有8ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊從 0 到 100知乎架構(gòu)變遷史很高的要求。這個(gè)需求，知乎開發(fā)了一個(gè)頁(yè)面渲染優(yōu)化叫 Sink 的小工具。它拿到消息后，先做本地的知乎在 2013 年時(shí)每天有上百萬(wàn)的 PV，頁(yè)保存、持久化，然后再把消息分發(fā)出去。如果面渲染其實(shí)是計(jì)算密集型的，另外因?yàn)橐@取那臺(tái)掛掉了，重啟時(shí)可以完整恢復(fù)，確保數(shù)據(jù)，所以也有 IO

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

11、面向服務(wù)的架構(gòu)（SOA）隨著知乎的功能越來(lái)越龐雜，整個(gè)系統(tǒng)也舉例而言，如果現(xiàn)在有用戶回答了問(wèn)題，越來(lái)越大。知乎是怎么做的服務(wù)化呢？首先系統(tǒng)會(huì)把問(wèn)題寫到 MySQL 里面，把消息首先需要一個(gè)最基本的 RPC 框架，RPC 框塞到 Sink，然后把問(wèn)題返回給用戶。Sink 通過(guò)架也經(jīng)歷了好幾版演進(jìn)。Miller 把任務(wù)發(fā)給 Beanstalkd，Worker可第一版是 Wish，它是一個(gè)嚴(yán)格定義序列以找到任務(wù)并處理?；哪Ｐ?。傳輸層用到了 STP，這是寫的最開始上線時(shí)，每秒鐘有 10 個(gè)消息，然后很簡(jiǎn)單的傳輸協(xié)議，跑在 TCP 上。一開始用有 70 個(gè)任務(wù)產(chǎn)生。現(xiàn)在每秒鐘有 100 個(gè)，的還不錯(cuò)，

12、因?yàn)橐婚_始只寫了一兩個(gè)服務(wù)。但有 1500 個(gè)任務(wù)產(chǎn)生，就是通過(guò)現(xiàn)在的驅(qū)動(dòng)是隨著服務(wù)增多，一些問(wèn)題開始出現(xiàn)，首先是架構(gòu)支撐的。ProtocolBuffer 會(huì)些描述代碼，很冗長(zhǎng)，ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊9從 0 到 100知乎架構(gòu)變遷史放到整個(gè)顯得很。另外嚴(yán)格的定義使單的定義服務(wù)的名字就可以找到服務(wù)在哪臺(tái)機(jī)其不便使用。這時(shí)有位工程師開發(fā)了新的 RPC器上。同時(shí)，知乎也有相應(yīng)的調(diào)優(yōu)的工具，基框架Snow。它使用簡(jiǎn)單的 JSON 做數(shù)據(jù)序于 Zipkin 開發(fā)了的 Tracing 系統(tǒng)。按照調(diào)用關(guān)系，知乎的服務(wù)分成了 3 層：列化。但是松散的數(shù)據(jù)定義面對(duì)的問(wèn)題是，比如說(shuō)服務(wù)要去升級(jí)

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

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

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

16、；為使接收者能更快接收做的最重要的事情是什么？到消息，會(huì)推送消息通知給接收者；最后客戶應(yīng)該是以下三件事：端主動(dòng)到服務(wù)器收取消息。1. 確定了的消息模型2. 制定了數(shù)據(jù)同步協(xié)議起初是一個(gè)通訊工具，作為通訊由于用戶的帳戶、人和消息等數(shù)據(jù)都工具最的功能是收發(fā)消息。團(tuán)隊(duì)源于在服務(wù)器，如何將數(shù)據(jù)同步到客戶端就成廣團(tuán)隊(duì)，消息模型跟郵箱的郵件模型也很有了很關(guān)鍵的問(wèn)題。為簡(jiǎn)化協(xié)議，我們決定通過(guò)淵源，都是轉(zhuǎn)發(fā)。一個(gè)統(tǒng)一的數(shù)據(jù)同步協(xié)議來(lái)同步用戶所有的基12ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊從無(wú)到有：系統(tǒng)的演進(jìn)3. 定型了礎(chǔ)數(shù)據(jù)。架構(gòu)最初的方案是客戶端一個(gè)本地?cái)?shù)據(jù)的快照 (Snapshot)，需要同步數(shù)據(jù)時(shí)，

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

18、短連接入服務(wù)。長(zhǎng)連接入服務(wù)同時(shí)同時(shí)，Snapshot 被設(shè)計(jì)得非常精簡(jiǎn)， 是若干個(gè)支持客戶端主動(dòng)發(fā)起請(qǐng)求和服務(wù)器主動(dòng)Key-Value 的組合，Key 代表數(shù)據(jù)的類型，Value發(fā)起推送；短連接入服務(wù)則只支持客戶代表給到客戶端的數(shù)據(jù)的最新版本號(hào)。Key 有三端主動(dòng)發(fā)起請(qǐng)求。個(gè)，分別代表：帳戶數(shù)據(jù)、人和消息。這個(gè)邏輯層包括業(yè)務(wù)邏輯服務(wù)和基礎(chǔ)邏輯服同步協(xié)議的一個(gè)額外好處是客戶端同步完數(shù)據(jù)務(wù)。業(yè)務(wù)邏輯服務(wù)封裝了業(yè)務(wù)邏輯，是后，不需要額外的 ACK 協(xié)議來(lái)確認(rèn)數(shù)據(jù)收取成提供給客戶端調(diào)用的 API。基功，同樣可以保證丟數(shù)據(jù)：只要客戶端拿最礎(chǔ)邏輯服務(wù)則抽象了更底層和通用的業(yè)新的 Snapshot 到服務(wù)器

19、做數(shù)據(jù)同步，服務(wù)器即務(wù)邏輯，提供給業(yè)務(wù)邏輯服務(wù)。可確認(rèn)上次數(shù)據(jù)已經(jīng)同步完成，可以執(zhí)行后層包括數(shù)據(jù)服務(wù)和數(shù)據(jù)服續(xù)操作，例如清除暫存在服務(wù)的消息等等。服務(wù)通過(guò) MySQL 和 SDB務(wù)。數(shù)據(jù)此后，精簡(jiǎn)方案、減少流量開銷、盡量由中廣泛使用的 Key-Table（早期服務(wù)器完成較復(fù)雜的業(yè)務(wù)邏輯、降低客戶端實(shí)數(shù)據(jù)系統(tǒng)）等底層系統(tǒng)來(lái)持久現(xiàn)的復(fù)雜度就作為重要的指導(dǎo)原則，持續(xù)影響化用戶數(shù)據(jù)。數(shù)據(jù)服務(wù)適配并路由著后續(xù)的設(shè)計(jì)開發(fā)。記得有個(gè)比較經(jīng)典的數(shù)據(jù)請(qǐng)求到不同的底層數(shù)據(jù)服案例是：我們?cè)?.2 版實(shí)現(xiàn)了群聊功能，但務(wù)，面向邏輯層提供結(jié)構(gòu)化的數(shù)據(jù)服務(wù)。為了保證新舊版客戶端間的群聊體驗(yàn)，我們通比較特別的是，每一種不同

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

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

22、作，消息發(fā)到群后，可以通過(guò)異步隊(duì)十萬(wàn)億次。列來(lái)異步完成消息的擴(kuò)散寫等等。這三件事影響深遠(yuǎn)，乃至于 5 年后的今天，我們?nèi)岳^續(xù)沿用最初的架構(gòu)和協(xié)議，甚至還可以支持當(dāng)初 1.0 版的客戶端。這里有一個(gè)經(jīng)驗(yàn)教訓(xùn)運(yùn)營(yíng)支撐系統(tǒng)真的很重要。第一個(gè)版本的是倉(cāng)促完成的，當(dāng)時(shí)只是完成了基礎(chǔ)業(yè)務(wù)功能，并沒有配圖 4 單聊和群聊消息過(guò)程套的業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)等等。我們?cè)陂_放后，一時(shí)間竟沒有業(yè)務(wù)頁(yè)面和數(shù)據(jù)曲線可以看，圖 4 是異步隊(duì)列在群聊中的應(yīng)用。的14ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊從無(wú)到有：系統(tǒng)的演進(jìn)群聊是寫擴(kuò)散的，也就是說(shuō)發(fā)到群里的一條消有個(gè)廣為流傳的關(guān)于 開發(fā)的傳 歷經(jīng) 4，前后做了 30 多個(gè)版息會(huì)給群

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

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

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

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

27、一時(shí)間發(fā)現(xiàn)，造成故障影響面被放大。2) 所有 CGI 放在一起，每次大版本發(fā)布上的一方面是因?yàn)樵诳焖俚^(guò)程線，從測(cè)試到灰度再到全面部署完畢，中，重視功能開發(fā)，輕視了業(yè)務(wù)的重要性，個(gè)很漫長(zhǎng)的過(guò)程，幾乎所有開發(fā)都會(huì)有故障一直是兵來(lái)將擋水來(lái)土掩；另一方面是被同時(shí)卡在這個(gè)環(huán)節(jié)，非常影響效率；基礎(chǔ)設(shè)施對(duì)業(yè)務(wù)邏輯的支持度較弱?；A(chǔ)3) 新增的不太重要的CGI 有時(shí)穩(wěn)定性不好，和 Svrkit 服務(wù)運(yùn)行狀某些異常分支下會(huì) crash，導(dǎo)致 CGIHost 進(jìn)程無(wú)設(shè)施提供了態(tài)的。這個(gè)是每臺(tái)、每個(gè)服務(wù)標(biāo)配的，法服務(wù)，發(fā)消息這些重要 CGI 受影響沒法運(yùn)行。于是我們開始嘗試使用一種新的 CGI 架無(wú)需額外開發(fā)，

28、但是業(yè)務(wù)邏輯的就要麻煩得多了。當(dāng)時(shí)的業(yè)務(wù)邏輯是通過(guò)業(yè)務(wù)邏輯構(gòu)Logicsvr。需要 4 步：Logicsvr 基于Svrkit 框架。將Svrkit 框架和統(tǒng)計(jì)功能來(lái)做的，實(shí)現(xiàn)一個(gè)1) 申請(qǐng)日志上報(bào)；CGI 邏輯通過(guò)靜態(tài)編譯生成可直接使用 HTTP2) 在業(yè)務(wù)邏輯中加入日志上報(bào)點(diǎn)，日志會(huì)的 Logicsvr。mmweb 模塊拆分為 8被每臺(tái)上的 agent 收集并上傳到統(tǒng)計(jì)中心；個(gè)不同服務(wù)模塊。拆分原則是：實(shí)現(xiàn)不同業(yè)務(wù)3) 開發(fā)統(tǒng)計(jì)代碼；功能的 CGI 被拆到不同 Logicsvr，同能但4) 實(shí)現(xiàn)統(tǒng)計(jì)頁(yè)面。是重要程度不一樣的也進(jìn)行拆分。例如，作為功能的消息收發(fā)邏輯，就被拆為 3 個(gè)服務(wù)可以想

29、象，這種費(fèi)時(shí)費(fèi)力的模式會(huì)反過(guò)來(lái)降低開發(fā)對(duì)加入業(yè)務(wù)的積極性。于模塊：消息同步、本和語(yǔ)音消息、發(fā)圖片是有一天，我們?nèi)ス緝?nèi)的標(biāo)桿即通和消息。個(gè)的二進(jìn)制程序， （）取經(jīng)了，發(fā)現(xiàn)解決方案出乎意料地每個(gè) Logicsvr簡(jiǎn)單且強(qiáng)大：可以部署、上線。時(shí)至今日，后1) 故障報(bào)告臺(tái)有數(shù)十個(gè) Logicsvr，提供了數(shù)百個(gè) CGI 服務(wù)，之前每次故障后，是由 QA 牽頭出一份故部署在數(shù)千臺(tái)服務(wù)器上，客戶端量幾16ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊從無(wú)到有：系統(tǒng)的演進(jìn)4. KVSvr障報(bào)告，著重點(diǎn)是對(duì)故障影響的評(píng)估和故障定級(jí)。新的做法是每個(gè)故障不分大小，開發(fā)每個(gè)服務(wù)的存需要徹底復(fù)盤故障過(guò)程，然后商定解決方案

30、，儲(chǔ)模塊，是相互的。每個(gè)服務(wù)一補(bǔ)充出一份詳細(xì)的技術(shù)報(bào)告。這份報(bào)告?zhèn)戎赜冢簜€(gè)業(yè)務(wù)模塊和一個(gè)底層模塊組成。業(yè)如何避免同類型故障再次發(fā)生、提高故障主動(dòng)務(wù)層業(yè)務(wù)邏輯層和底層， 提供發(fā)現(xiàn)能力、縮短故障響應(yīng)和處理過(guò)程?；?RPC 的數(shù)據(jù)接口；底層有兩類：2) 基于 ID-Value 的業(yè)務(wù)無(wú)關(guān)的告警SDB 和 MySQL。體系SDB 適用于以用戶 UIN(uint32_t) 為 Key 的數(shù)據(jù)，比方說(shuō)消息索引和人。優(yōu)點(diǎn)是性能高，在可靠性上，提供基于異步流水同步的 Master-Slave 模式，Master 故障時(shí)，Slave 可以提供讀數(shù)據(jù)服務(wù)，無(wú)法寫入新數(shù)據(jù)。由于賬號(hào)為字母 + 數(shù)字組合，無(wú)法直接作

31、為 SDB 的 Key，所以帳號(hào)數(shù)據(jù)并非使圖 5 基于 ID-Value 的告警體系用 SDB，而是用 MySQL的。MySQL 也使體系實(shí)現(xiàn)思路非常簡(jiǎn)單，提供了 2 個(gè)用基于異步流水的 Master-Slave 模式。API，業(yè)務(wù)代碼在共享內(nèi)存中對(duì)某個(gè)第 1 版的帳號(hào)服務(wù)使用 Master-SlaveID 進(jìn)行設(shè)置 Value 或累加 Value 的功能。每臺(tái)各 1 臺(tái)。Master 提供讀寫功能，Slave 不提供上的 Agent 會(huì)定時(shí)將所有 ID-Value 上報(bào)到服務(wù)，僅用于備份。當(dāng) Master 有故障時(shí)，人中心，中心對(duì)數(shù)據(jù)匯總?cè)霂?kù)后就可以工切讀服務(wù)到 Slave，無(wú)法提供寫服務(wù)。

32、為提通過(guò)統(tǒng)一的頁(yè)面輸出曲線，并通過(guò)預(yù)升效率，我們還在業(yè)務(wù)模塊中加入了先配置的規(guī)則產(chǎn)生。memcached 提供 Cache 服務(wù)，減少對(duì)底層對(duì)于業(yè)務(wù)代碼來(lái)說(shuō)，只需在要被的業(yè)。調(diào)用一下API，并配置好告警條務(wù)流第 2 版的帳號(hào)服務(wù)還是 Master-Slave件即可。這就極大地降低了開發(fā)的成各 1 臺(tái)，區(qū)別是 Slave 可以提供讀服務(wù)，但有本，我們補(bǔ)全了各種項(xiàng)，讓我們能主動(dòng)及可能讀到臟數(shù)據(jù)，因此對(duì)一致性要求高的業(yè)務(wù)時(shí)地發(fā)現(xiàn)問(wèn)題。新開發(fā)的功能也會(huì)預(yù)先加入相Master。邏輯，例如和登錄邏輯只關(guān)項(xiàng)，以便在少量灰度階段就能直接通過(guò)當(dāng) Master 有故障時(shí)，同樣只能提供讀服務(wù)，無(wú)曲線了解業(yè)務(wù)是否符合

33、預(yù)期。法提供寫服務(wù)。第 3 版的帳號(hào)服務(wù)采用 1 個(gè) Master 和ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊17從無(wú)到有：系統(tǒng)的演進(jìn)多個(gè) Slave，解決了讀服務(wù)的水平擴(kuò)展能力。平臺(tái)化第 4 版的帳號(hào)服務(wù)底層采用多個(gè)2011.8舉行大運(yùn)會(huì)。推出“微Master-Slave 組， 每 組 由 1 個(gè) Master 和 多 個(gè) 信大運(yùn)志愿者服務(wù)中心” 服務(wù)號(hào)，Slave 組成，解決了寫服務(wù)能力不足時(shí)的水平擴(kuò)用戶可以搜索“szdy”將這個(gè)服務(wù)號(hào)加為好展能力。友，獲取大會(huì)相關(guān)的資訊。當(dāng)時(shí)對(duì)“szdy”最后還有個(gè)未解決的問(wèn)題：?jiǎn)蝹€(gè) Master-做了特殊處理， 用戶搜索時(shí)， 會(huì)隨機(jī)返回Slave 分組

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

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

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

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

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

39、心的數(shù)據(jù)一* 用戶的數(shù)據(jù)致性，另外 Master-Master 架構(gòu)是個(gè)必選項(xiàng)，也用戶可以滿世界跑，那是否用戶就近即兩個(gè)數(shù)據(jù)中心都需要可寫。接入數(shù)據(jù)中心就對(duì)業(yè)務(wù)處理流程有很大影響。2) Master-Master架構(gòu)ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊19從無(wú)到有：系統(tǒng)的演進(jìn)如果就近接入，同時(shí)還要保證數(shù)據(jù)一致性供了全局唯一的號(hào)申請(qǐng)服務(wù)來(lái)解決這一問(wèn)不影響業(yè)務(wù)，就意味著要么用戶數(shù)據(jù)的 Master題，所有數(shù)據(jù)中心通過(guò)這個(gè)服務(wù)申請(qǐng)?zhí)?。需要可以?dòng)態(tài)的改變；要么需要對(duì)所有業(yè)務(wù)邏這種需要特殊處置的場(chǎng)景極少，帶來(lái)太大輯進(jìn)行仔細(xì)梳理，嚴(yán)格區(qū)分本數(shù)據(jù)中心和跨數(shù)問(wèn)題。4) 可靠的數(shù)據(jù)同步據(jù)中心用戶的請(qǐng)求，將請(qǐng)

40、求路由到正確的數(shù)據(jù)中心處理。數(shù)據(jù)中心之間有大量的數(shù)據(jù)同步，數(shù)據(jù)是考慮到上述問(wèn)題會(huì)帶來(lái)很高昂的實(shí)現(xiàn)和維否能夠達(dá)到最終一致，取決于數(shù)據(jù)同步是否可護(hù)的復(fù)雜度，我們限制了每個(gè)用戶只能接入其靠。為保證數(shù)據(jù)同步的可靠性，提升同步的可用性，我們又開發(fā)一個(gè)基于 Quorum 算法的隊(duì)歸屬數(shù)據(jù)中心進(jìn)行操作。如果用戶發(fā)生漫游，列組件，這個(gè)組件的每一組由 3 機(jī)其漫游到的數(shù)據(jù)中心會(huì)自動(dòng)引導(dǎo)用戶重新連回服務(wù)組歸屬數(shù)據(jù)中心。成。與一般隊(duì)列的不同之處在于，這個(gè)組件對(duì)隊(duì)列寫入操作進(jìn)行了大幅簡(jiǎn)化，3 機(jī)這樣用戶數(shù)據(jù)的一致性問(wèn)題就迎服務(wù)不刃而解了，因?yàn)樗胁僮鞅幌拗圃跉w屬數(shù)據(jù)中需要相互通訊，每個(gè)上的數(shù)據(jù)都是順序?qū)?，?zhí)行寫操作時(shí)

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

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

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

44、了有史以來(lái)最大規(guī)模的為解決類似問(wèn)題，三園區(qū)容災(zāi)應(yīng)運(yùn)而生，等服務(wù)出現(xiàn)長(zhǎng)達(dá) 5 個(gè)故障，消息收發(fā)和目標(biāo)是將上海數(shù)據(jù)中心的服務(wù)均勻部署到 3 個(gè)小時(shí)的故障，故障期間消息量跌了一半。故障物理上的數(shù)據(jù)園區(qū)，在任意單一園區(qū)整體的起因是上海數(shù)據(jù)中心一個(gè)園區(qū)的主光纖被挖故障時(shí)，仍能提供無(wú)損服務(wù)。斷，近 2 千臺(tái)服務(wù)器不可用，整個(gè)上海數(shù)1) 同時(shí)服務(wù)據(jù)中心（當(dāng)時(shí)國(guó)內(nèi)只有這一個(gè)數(shù)據(jù)中心）的服傳統(tǒng)的數(shù)據(jù)中心級(jí)災(zāi)備方案是“兩地三中務(wù)癱瘓。心”，即同城有兩個(gè)互備的數(shù)據(jù)中心，異地再建故障時(shí)，我們?cè)鴩L試把接入到故障園區(qū)的設(shè)一個(gè)災(zāi)備中心，這三個(gè)數(shù)據(jù)中心很可能用戶切走，但收效甚微。雖然數(shù)百個(gè)模塊只有一個(gè)在提供服務(wù)，故障時(shí)再將業(yè)

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

46、可控的狀況。過(guò)來(lái)說(shuō)，只需讓每個(gè)園區(qū)的服務(wù)器跑在容其實(shí)在這個(gè)故障發(fā)生之前 3，我們已量上限的 2/3，保留 1/3 的容量即可提供無(wú)損經(jīng)在著手解決這個(gè)問(wèn)題。當(dāng)時(shí)上海數(shù)據(jù)中心內(nèi)的容災(zāi)能力，而傳統(tǒng)“兩地”則有多得網(wǎng)交換機(jī)異常，導(dǎo)致出現(xiàn)一個(gè)出乎意料的多的服務(wù)器被閑置。此外，在三個(gè)園ArchSummit 全球架構(gòu)師峰會(huì)會(huì)刊21從無(wú)到有：系統(tǒng)的演進(jìn)區(qū)同時(shí)對(duì)外服務(wù)，因此我們?cè)诠收蠒r(shí)，需要解實(shí)戰(zhàn)演習(xí)，單一園區(qū)上千臺(tái)服務(wù)，檢驗(yàn)容決的問(wèn)題是“怎樣把業(yè)務(wù)流量切到其他數(shù)據(jù)園災(zāi)效果是否符合預(yù)期。特別地，為了避免隨著區(qū)？”，而不是“能不能把業(yè)務(wù)流量切到其他時(shí)間的推移某個(gè)服務(wù)模塊因?yàn)槟炒胃戮蛿?shù)據(jù)園區(qū)？”，前者顯然是更容易

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

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

49、況使用到極致，那肯定是事半功倍的。下，能自行決策迅速掉有問(wèn)題的服務(wù)實(shí)例，結(jié)果還真的可以，我們?cè)诨A(chǔ)設(shè)施里加入自動(dòng)把業(yè)務(wù)流量分散切到其他服務(wù)實(shí)例上。另了對(duì)協(xié)程的支持，重點(diǎn)是這個(gè)協(xié)程組件可以不外，我們還建設(shè)了一套手工操作的全局系破壞原來(lái)的業(yè)務(wù)邏輯代碼結(jié)構(gòu)，讓我們?cè)写y(tǒng)，可以在大型網(wǎng)絡(luò)故障時(shí)，由人工介入碼中使用同步 RPC 調(diào)用的代碼不做任何修改，掉某個(gè)園區(qū)所有的，迅速將業(yè)務(wù)流量分散就可以直接通過(guò)協(xié)程異步化。Svrkit 框架直接到其他兩個(gè)數(shù)據(jù)園區(qū)。集成了這個(gè)協(xié)程組件，然后美好的事情發(fā)生了，4) 容災(zāi)效果檢驗(yàn)原來(lái)單實(shí)例最多提供上百并發(fā)請(qǐng)求處理能力的三園區(qū)容災(zāi)是否能正常發(fā)揮作用還需要進(jìn)服務(wù)，在重編上

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