1、 騰訊微信技術(shù)總監(jiān)周顥：一億用戶增長背后的架構(gòu) 2012-05-15 07:56 來源：CSDN 專稿 作者：付江 CSDN.NET 專稿 付江/文 微信騰訊戰(zhàn)略級產(chǎn)品，創(chuàng)造移動互聯(lián)網(wǎng)增速記錄， 10 個月 5000 萬手機用戶，433 天之內(nèi)完成用戶數(shù)從零到一億的增長過程，千萬級用戶同時在線，搖一 搖每天次數(shù)過億.在技術(shù)架構(gòu)上，微信是如何做到的？日前，在騰訊大講堂在中山大學(xué)校園宣講活動上，騰訊廣研助理總經(jīng)理、微信技術(shù)總監(jiān)周顥在兩小時的演 講中揭開了微信背后的。 周顥，2001 年畢業(yè)于華南理工大學(xué)，計算機專業(yè)碩士。2005 年加入騰訊廣州研發(fā)部，歷任 QQ 郵箱架構(gòu)師，廣研技術(shù)總監(jiān)，T4 技

2、術(shù)專家，微信中心助理總經(jīng)理。 (騰訊廣研助理總經(jīng)理、微信技術(shù)總監(jiān) 周顥 CSDN 配圖)周顥把微信的成功歸結(jié)于騰訊式的“三位一體”策略：即產(chǎn)品精準(zhǔn)、項目敏捷、 技術(shù)支撐。微信的成功是在三個方面的結(jié)合比較好，能夠超出絕大多數(shù)同行或?qū)?手，使得微信走到比較前的位置。所謂產(chǎn)品精準(zhǔn)，通俗的講就是在恰當(dāng)?shù)臅r機做了恰當(dāng)?shù)氖?，推出了重量級功能，在合適的時間以最符合大家需求的方式推出去。他認為在整個微信的成功中，產(chǎn)品精準(zhǔn)占了很大一部分權(quán)重。 敏捷是一種態(tài)度 敏捷就是試錯微信研發(fā)團隊里鼓勵一種試錯的：他們堅信，在互聯(lián)網(wǎng)開發(fā)里，如果能夠有一個團隊在更短的時間內(nèi)嘗試了更多機會(并能改進過來)，就能有(更多的)機會

3、勝出。敏捷是一種態(tài)度，在軟件開發(fā)過程中，項目管理者都會非常忌諱“變更” 這個詞，但是在微信的項目運作中是不可以的。因為微信必須要容忍說哪怕在發(fā)布前的十分鐘，也要允許他變更。這是非常大的挑戰(zhàn)，因為打破了所有傳統(tǒng)項目 開發(fā)的常識。所有人都說不可能做到的，但微信做到了。研發(fā)團隊所做的一切都 是要給產(chǎn)品決策者有最大的自由度，而這個決策正是微信能夠勝出的關(guān)鍵。 海量系統(tǒng)上的敏捷 無異于懸崖邊的跳舞敏捷有很多困境，如果做一個單機版程序，是可以做到很敏捷的，但是騰訊正在運作的是一個海量系統(tǒng)，有千萬級用戶同時在線，在一個單 獨的功能上每天有百億級的訪問，同時還要保證 99.95%的可用性。在海量系統(tǒng)上應(yīng)對項目

4、開發(fā)會有很嚴(yán)謹(jǐn)?shù)囊?guī)范，都說要盡可能少的變化，因為 90%-95%的錯誤都是在變更中產(chǎn)生的， 如果系統(tǒng)一直不變更會獲得非常高的穩(wěn)定度，但是微信就是要在懸崖邊跳舞。微信的研發(fā)團隊要做一些事情，讓敏捷開發(fā)變得更簡單。 如何做到這一切？周顥認為，首先，必須建立起一種狂熱的技術(shù)信念，就是一定是可以做到的。然后，需要用一些穩(wěn)固的技術(shù)(理念)來支撐，例如大系統(tǒng)小做、 讓一切可擴展、必須有基礎(chǔ)組件、輕松上線(灰度、灰度、再灰度；精細監(jiān)控；迅速響應(yīng)).等等來支撐。 四大法器：大系統(tǒng)小做、讓一切可擴展、要有基礎(chǔ)組件、輕松上線大系統(tǒng)小做：當(dāng)設(shè)計龐大系統(tǒng)的時候，應(yīng)該盡量分割成更小的顆粒， 使得項目之間的影響是最小的。

5、 一切可擴展：在高穩(wěn)定度、高性能的系統(tǒng)中間，為了穩(wěn)定性能把它設(shè)計成不變化的系統(tǒng)，但為了支持敏捷需要讓一切的東西都要變得可以擴展。 必須建立基礎(chǔ)組件：要解決復(fù)雜問題的時候，需要將已有的經(jīng)驗固化下來，固化下來的東西會成為系統(tǒng)中的一部分。 輕松上線：當(dāng)做了變化并把它從開發(fā)環(huán)境中部署到現(xiàn)有的運營環(huán)境中去，在這個過程中，“灰度”這個詞非常關(guān)鍵，就是在黑和白之間的選擇，必須要變成一種小規(guī)模嘗試，再逐步擴展到海量過程中的一個問題。 大系統(tǒng)小做僅僅把模塊變得更為清晰，這在海量系統(tǒng)設(shè)計開發(fā)中是不夠的， 還需要在物理環(huán)境上進行分離部署，出現(xiàn)問題的時候可以快速發(fā)現(xiàn)，并且在最快 的情況下解決掉。 大系統(tǒng)小做 混搭模式

6、 將不同的應(yīng)用邏輯物理分割獨立出來，用戶注冊登錄、LBS 邏輯、搖一搖邏輯、漂流瓶邏輯、消息邏輯獨立開來。把關(guān)鍵的邏輯混搭在一起，當(dāng)所有的邏輯部署在同一個服務(wù)器上，確實也會帶來很大敏捷上的好處，因為不需要額外的考慮部署和監(jiān)控的問題。在整個微信的邏輯中，可能現(xiàn)在已經(jīng)有上百種不同的邏輯，因為 會在邏輯的分割上拆分成 8-10 種做分離部署。 一切可擴展網(wǎng)絡(luò)協(xié)議可擴展、數(shù)據(jù)存儲可擴展擴展的關(guān)鍵點有兩塊。一個是網(wǎng)絡(luò)協(xié)議需要擴展，當(dāng)要升級一個新功能的時候， 會有一些比較大的困難，所以所有協(xié)議設(shè)計都比較向前兼容，但是向前兼容還 是不夠的，因為網(wǎng)絡(luò)協(xié)議設(shè)計本身有非常多的功能也會有比較大的字段，相關(guān)的代碼可能

7、會有數(shù)千行，這一塊不能通過手寫方式完成。可以通過 XML 描述，再通過 工具自動生成所有的代碼，這是微信獲得快速開發(fā)的一個重要的點。 另外一塊就是在數(shù)據(jù)存儲方面是必須可擴展的。在 2005 年絕大多數(shù)海量系統(tǒng)的設(shè)計都是采用固定字段的存儲，但是在現(xiàn)代系統(tǒng)中會意識到這個問題，會采用 KV 或者 TLV 的方式，微信也做了不同的設(shè)計。 把復(fù)雜邏輯都固化下來，成為基礎(chǔ)軟件。在微信 大致包括： 會有幾種不同的基礎(chǔ)組件。SvrkitClient/Server 自動代碼生成框架:10 分鐘搭建內(nèi)部服務(wù)器 LogicServer邏輯容器：隨時添加新邏輯OssAgent監(jiān)控/統(tǒng)計框架：所見即所得的監(jiān)控報表存儲組

8、件屏蔽容災(zāi)/擴容等復(fù)雜問題 灰度、灰度、再灰度在變更后的部署方式上，微信在一些規(guī)則會限定不能一次把所有的邏輯變更上去， 每一次變更一小點觀察到每一個環(huán)節(jié)沒有問題的時候，才能布局到全網(wǎng)上去。微信每一天可以支撐超過 20 個變更，在業(yè)界來說，通常做到 5 個已經(jīng)是比 較快了，但是微信可以做到快 4 倍。 騰訊內(nèi)部的上線系統(tǒng)而所謂灰度發(fā)布，是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。AB test 就是一種灰度發(fā)布方式，讓一部用戶繼續(xù)用 A，一部分用戶開始用 B，如果用戶對 B 沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到 B 上面 來。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就

9、可以發(fā)現(xiàn)、調(diào)整問題，以保證其影響度。(在騰訊，灰度發(fā)布是最常采用的發(fā)布方式之一) 孫子兵法：古之所謂善戰(zhàn)者，勝于易勝者也常識上，解決一個復(fù)雜問題的時候，會用高明的技巧解決復(fù)雜的問題，這個不是微信團隊的目標(biāo)，他們追求的要做到讓所有問題很自然和簡單的方式解決掉。在周顥看來，微信架構(gòu)的技術(shù)復(fù)雜點在四個要點：協(xié)議、容災(zāi)、輕重、監(jiān)控。 微信架構(gòu)協(xié)議。手機終端跟服務(wù)器之間的交互協(xié)議，這個協(xié)議的設(shè)計是整個系統(tǒng)的骨架，在這一點做好設(shè)計可以使得系統(tǒng)的復(fù)雜度大大降低。容災(zāi)。當(dāng)系統(tǒng)出現(xiàn)了若干服務(wù)器或若干支架(宕機的時候)，仍然需要讓系統(tǒng)盡可能的提供正常的服務(wù)。 輕重。如何在系統(tǒng)架構(gòu)中分布功能，在哪一個點實現(xiàn)哪一個功

10、能，代表系統(tǒng)中間的功能配置。 監(jiān)控。為系統(tǒng)提供一個智能儀表盤。 在協(xié)議設(shè)計上，移動互聯(lián)網(wǎng)和常規(guī)互聯(lián)網(wǎng)有很大的區(qū)別。首先有 CMWAP 和 CMNET 的不同，在中國現(xiàn)在有相當(dāng)多的手機用戶使用 WMWAP 連接，還有 就是在線和離線的概念，當(dāng) QQ 下線的時候叫離線，當(dāng)你登錄的時候叫在線。但是在移動互聯(lián)網(wǎng)這兩個概念比較模糊。從微信的設(shè)計中，不管在線還是離線系統(tǒng)表現(xiàn) 都應(yīng)該是一致的。還有一個是連接不穩(wěn)定的問題，由于手機信號強弱的變化，當(dāng)時信號很好，5 秒鐘走到信號不好的地區(qū)，連接就必須斷掉。這個中間帶來不穩(wěn)定的 因素為協(xié)議設(shè)計帶來較大困難。此外就是資費敏感的問題，因為移動互聯(lián)網(wǎng)是按照流量計費的，這

11、個計費會使得在協(xié)議設(shè)計中如何最小化傳輸?shù)膯栴}。最后就是高延 遲的問題。 對 此 ， 業(yè) 界 標(biāo) 準(zhǔn) 的 解 決 方 案 ：Messaging And Presence Protocol： 1)XMPP;2)SIP/SIMPLE。它的優(yōu)點是簡單，大量開源實現(xiàn)。而缺點同樣明顯：1)流量大：狀態(tài)初始化；2)消息不可靠。 微信在系統(tǒng)中做了特殊設(shè)計，叫 SYNC 協(xié)議，是參考 Activesyec 來實現(xiàn)的。特點首先是基于狀態(tài)同步的協(xié) 議，假定說收發(fā)消息本身是狀態(tài)同步的過程，假定終端和服務(wù)器狀態(tài)已經(jīng)被遲了，在服務(wù)器端收到最新的消息，當(dāng)客戶端、終端向服務(wù)器對接的時候，收取消息的過 程實際上可以簡單的歸納為

12、狀態(tài)同步的過程，收消息以及收取你好友狀態(tài)更新都是相同的。在這樣的模式之下，我們會也許會把交互的模式統(tǒng)一化，只需要推送一個 消息到達就可以了，終端收到這個就來做消息的同步。在這樣的簡化模式之下，安卓和塞班都可以得到統(tǒng)一。這樣的系統(tǒng)本身的實現(xiàn)是更為復(fù)雜的，但是 獲得很多額外的好處。 讓剩下系統(tǒng)實現(xiàn)的部分更加簡單，簡化了交互模式，狀態(tài)同步可以通過狀態(tài)同步的差值獲得最小的數(shù)據(jù)變更，通過增量的傳輸?shù)玫阶钚〉臄?shù)據(jù)傳輸量。通過這 樣的協(xié)議設(shè)計，微信可以確保消息是穩(wěn)定到達的，而且是按序到達。引用一句俗話： 比它炫的沒它簡單，比它簡單的沒它快，沒誰比他更快，哪怕在 GPRS 下，微 信也能把進度條輕易推到底。

13、追求完美設(shè)計的團隊不能勝任海量服務(wù)在容災(zāi)之前面向最壞的思考，如果系統(tǒng)真的掛了，需要做一些事情，首先是防止雪崩，避免蝴蝶效應(yīng)。如果關(guān)注春節(jié)訂火車票就知道了，用 戶的請求量會因為系統(tǒng)服務(wù)不了而不斷的重試，意味著發(fā)生雪崩的時候，系統(tǒng)可能會承載原先 3-10 倍的流量，使得所有的事情更加惡化。所以微信有很多“放 雪”功能的設(shè)計。第二個詞是柔性可用，在任何的系統(tǒng)中不要追求完美設(shè)計，追求完美設(shè)計的是團隊是不 能勝任海量服務(wù)的。如果在一個系統(tǒng)出現(xiàn)問題的時候，這個 系統(tǒng)就掛了，那么這是一個不好的設(shè)計，最好的做法是提供 0-1 中間的選擇。舉一個例子，當(dāng)一個用戶向另外一個用戶發(fā)消息的時候，可能會 通過一個垃圾信

14、息過濾的檢測，如果垃圾信息過濾這個模塊突然掛掉了，這個消息難道就不能達到了嗎？在這樣的情況下，要忽略掉這個錯誤，使得消息正常達到對 方。要精確定位出哪一個環(huán)節(jié)是最為重要的，把不是重要的錯誤盡可能的忽略掉。當(dāng)不能做到完美的時候，盡可能為用戶提供服務(wù)。另外一個重要方面叫做“保護點 前置”，最前的一個點就是終端，在手機終端上蘊埋更多的保護點，這樣會為用戶系統(tǒng)贏得更大的處理空間。如果終端具備這樣的能力，會獲得更大的反應(yīng)空間。 周顥介紹了在微信上具體容災(zāi)設(shè)計的做法。在所有的容災(zāi)中存儲層的容災(zāi)是最難 的，一個系統(tǒng)的設(shè)計分為三層：接入層、邏輯層、存儲層。接入層和邏輯層的 容災(zāi)都有比較成熟的方案。邏輯層的容災(zāi)

15、相對來說比較簡單，盡量不要有狀態(tài)的設(shè) 計，比如說當(dāng)你做上一個請求的時候，會保持一些狀態(tài)，要使得下一個請求發(fā)到下一個服務(wù)器。如果任何一個請求之間互相不關(guān)聯(lián)的話，這個就是無狀態(tài)的設(shè)計， 只要做到這一點邏輯層的容災(zāi)可以隨意的切換。在回到存儲層本身的容災(zāi)設(shè)計上， 相 對來說困難一些，但是微信研發(fā)團隊采用了一些技巧，叫分而治之，分離業(yè)務(wù)場景，尋求簡單的設(shè)計，并不會尋求大而同一的解決方案，因為這樣會使得系統(tǒng)的復(fù)雜度大幅度上升，而微信會盡可能把產(chǎn)品拆細，尋求簡化的設(shè)計。 首先是主備容災(zāi)，這是最常見的方案。在有一些業(yè)務(wù)場景中是可以容忍最終一致性的，比如賬號系統(tǒng)的設(shè)計，每天寫入賬號系統(tǒng)的請求是非常少的，但是訪問

16、 的請求非常多，這個差異可能會達到數(shù)萬倍的規(guī)模，在這樣的場景下，微信會在賬號系統(tǒng)中采用簡化的方案，也可以獲得比較大的穩(wěn)定度。 SET 模型雙寫第二種容災(zāi)的模式叫雙寫，兩臺 Master 的機器，當(dāng)一臺機故障的時候，另外一臺機還是可以接收到寫請求，當(dāng)兩臺機交錯啟動的時候，會得到數(shù)據(jù)的丟 失。但是有一些場景是可以容忍輕度數(shù)據(jù)丟失的，比如說會有一個存儲專門記錄用戶終端的類型，比如說安卓還是塞班以及他們使用終端的微信版本是什么，這樣的 數(shù)據(jù)是可以容忍輕度數(shù)據(jù)丟失的，因為偶爾有一些丟失的話，下一次訪問會把這些數(shù)據(jù)帶上來，會盡快的修復(fù)所有的數(shù)據(jù)。雙寫也是非常簡單的模式。 微信的研發(fā)團隊做了一個叫 Simp

17、le Quorum 的機制，在微信的中，同步協(xié)議有一個很重要的基石叫序列發(fā)生器，這樣的一個序列發(fā)生器需要有極高的穩(wěn)定度。首先可以看到序列號有一個特點 永遠是遞增的，用遞增方式往前推進的時候，最大的序列號就是最新的系列號。有一個畢業(yè)才加入廣研的畢業(yè)生想到一個絕佳的方案， 按 SET 分布，從 2G 減到 200K。 前輕后重 功能點后移周顥還談到了輕重的概念。這個概念的提出主要是從終端本身的一些困境所帶來的。首先在終端上需要表現(xiàn)最多的一個產(chǎn)品的邏輯，邏輯非常復(fù)雜，變更的成 本也非常高，當(dāng)需要修復(fù)的時候必須發(fā)布一個新版本，這個新版必須由自己下載才能完成，下載的成本非常高。在這樣的前提下，如果手機終

18、端產(chǎn)生了任何變化的時 候，如果這個變化有非常大的問題就會有極大的困境，所以需要在每一個發(fā)布之前做一些充分的數(shù)據(jù)，確保不會發(fā)生致命問題。如果一旦出現(xiàn)致命問題難以修復(fù)，需 要把關(guān)鍵的點從終端移到變更的能力。 實現(xiàn)，把功能點后移，來充分發(fā)揮快速 接入優(yōu)化：從 GSLB 到 IP 重定向在接入層的優(yōu)化，速度很重要的因素，是不是能夠就近接入一個最優(yōu)的節(jié)點，比如說移動用戶最好接入移動的節(jié)點，海外的用戶可能需要尋找更佳的路由，有 的時候可能無法自動做到這一點，一點是在終端上做測速，微信會通過在 IP 逆向的能力，通過指揮微信終端聯(lián)網(wǎng)的能力，尋找最優(yōu)的接入點。上圖就是每 分鐘收到同一項指令曲線的報表。 如何解

19、決“偷流量”的問題當(dāng)國內(nèi)類微信類產(chǎn)品發(fā)布的時候出現(xiàn)一個大的問題就是“偷流量”，當(dāng)用戶在某一些邏 輯下進行一個死循環(huán)，不斷訪問某一些數(shù)據(jù)，這樣的死循環(huán)是非常可怕的，如果在用戶不知覺的情況之下，可能會在一個小時之內(nèi)偷到數(shù) 10 兆甚至數(shù)百兆的流量。 有非常多業(yè)內(nèi)的同行都需要花大量的精力解決這個問題，微信研發(fā)團隊用了非常強大的方式解決它。通過在 建立起嚴(yán)厲的監(jiān)控系統(tǒng)，對每一個用戶的行為做一個 監(jiān)控，當(dāng)發(fā)現(xiàn)異常的時候，會給終端發(fā)出指令，使得微信終端在一段時間無法聯(lián)網(wǎng)，但是可以保證用戶流量不會白白的使用掉。 功能適配的例子第一期微信版本發(fā)布的時候，當(dāng)時沒有群聊的功能，第二版發(fā)布的時候做了這個功能。當(dāng)時有

20、兩個 選擇，對于早期版本的用戶，因為不支持群聊，就無法享用到這個功能，但是微信希望提供更好的選擇，想讓早期不支持群聊的版本，也可以被拉到一個群里面收消 息、發(fā)消息，通過能做到這個事情。 功能的適配也分而治之 把監(jiān)控嵌入基礎(chǔ)框架對于一個海量系統(tǒng)來說，一個精密的儀表盤非常重要。監(jiān)控是非常痛苦的，對于這樣一個系統(tǒng)來說，每小時會產(chǎn)生數(shù)百 G 的監(jiān)控日志。微信希望在 1 分鐘之內(nèi)監(jiān)控的數(shù)據(jù)就能夠顯示在報表上，因為只有這樣的精準(zhǔn)和實時度才能夠贏得處理故障的時間。微信會做關(guān)聯(lián)統(tǒng)計，通過搖一搖加了好友，他們活躍度如何，過了一段時 間他們的活躍度變化情況又是如何。這種需求是需要通過大量日志的關(guān)聯(lián)統(tǒng)計來獲 得的。

21、研發(fā)團隊也花了一段時間來理解這個問題，發(fā)現(xiàn)了中間一個重要的經(jīng)驗叫 做“魚和熊掌不能兼得”。 為了讓監(jiān)控數(shù)值更敏感，需要把監(jiān)控細化再細化，上面數(shù)據(jù)表示每一欄子系統(tǒng)的數(shù)據(jù)，下面這個是按微信版本號來劃分的，這里的數(shù)據(jù)項是非常多。 微信還需要采集一些異常的點，如果有異常的話會發(fā)布緊急的版本，盡可能快的替換它。對收發(fā)消息延時做的監(jiān)控，比如說 01 秒端到端的速度，會對不同 的區(qū)段做一些統(tǒng)計，當(dāng)某一個環(huán)節(jié)出現(xiàn)異常的時候，通常會在中間的延時上體現(xiàn)出 來。有一個很重要的點叫自動報警，現(xiàn)在有數(shù)千項的數(shù)據(jù)，不可能每一項都靠人工去看的，必須要跟自動報警相關(guān)聯(lián)，微信有一些智能的算法，是不是在正常的范圍內(nèi)，跟歷史的數(shù)值

22、進行對比，如果有異常的話，會通過短信、郵件還有微信 本身來發(fā)出報警信息。把監(jiān)控嵌入基礎(chǔ)框架微信會把監(jiān)控嵌入到基礎(chǔ)框架里面去，因為并不是每一個人都會意識到在需要的地方嵌入一個監(jiān)控點，所以在基礎(chǔ)框架本身內(nèi)置很重要的監(jiān)控點，比如說這個 表上的欄目，非常多的欄目大概會有數(shù)百項的欄目，都不需要程序員自己去寫，當(dāng)用基礎(chǔ)組件搭建一個系統(tǒng)的時候，就可以直接觀測系統(tǒng)數(shù)據(jù)。 在談到微信未來的技術(shù)挑戰(zhàn)時，周顥首先希望能夠讓微信成為可用性 99.99%的系統(tǒng)；設(shè)計出面向現(xiàn)在 10 倍容量的系統(tǒng)以及完全的 IDC 容災(zāi)。 網(wǎng)上盛傳的凌晨兩點，騰訊大廈那多層大片大片的燈光和樓下那長長的出租車隊伍說明了一切。引用一句話做結(jié)

23、尾，可怕的不是微信，真正可怕的是，比你領(lǐng)先比你更有天賦的團隊比你更努力。 特別鳴謝：騰訊大講堂（）對本篇報道的內(nèi)容支持附錄：騰訊微信技術(shù)總監(jiān)周顥演講 PPT 微信之道至簡廣州研發(fā)部harveyzhou騰訊大講堂 關(guān)于我周顥（harveyzhou） 2001年畢業(yè)于華南理工大學(xué)，計算機專業(yè)碩士 2005年加入騰訊廣州研發(fā)部 歷任QQ郵箱架構(gòu)師，廣研技術(shù)總監(jiān)，T4技術(shù)專家，微信中心助 理總經(jīng)理 騰訊大講堂 關(guān)于微信移動互聯(lián)網(wǎng)的探索者 10個月5000萬手機用戶 創(chuàng)造移動互聯(lián)網(wǎng)用戶增速的記錄千萬級在線 蘋果中國區(qū)

24、AppStore月下載量第一搖一搖每天次數(shù)過億 騰訊戰(zhàn)略級產(chǎn)品 騰訊大講堂 騰訊大講堂 微信的歷程 微信的三位一體產(chǎn)品的精準(zhǔn) 項目的敏捷技術(shù)的支撐 騰訊大講堂 產(chǎn)品的精準(zhǔn)用簡單規(guī)則構(gòu)造復(fù)雜世界張小龍，騰訊副總裁，廣研靈魂人物 從第二代程序員旗手，到領(lǐng)軍者，到產(chǎn)品從Foxmail，到QQ郵箱，到微信 人物騰訊大講堂 微信的三位一體產(chǎn)品的精準(zhǔn) 項目的敏捷技術(shù)的支撐 騰訊大講堂 什么是敏捷項目管理的技巧？Scrum？礦工？ 騰訊大講堂

25、 項目的敏捷敏捷就是試錯法敏捷是一種態(tài)度 產(chǎn)品決策是成功的第一因素允許發(fā)布前十分鐘的變更 給予產(chǎn)品決策以最大自由度騰訊大講堂 敏捷的困境海量系統(tǒng)的復(fù)雜度 千萬級同時在線億級搖一搖 單集群百億級服務(wù)請求99.95%的可用性 海量系統(tǒng)上的敏捷，無異于懸崖邊的跳舞騰訊大講堂 讓敏捷變得簡單狂熱的信念，You can do it !穩(wěn)固的技術(shù)支撐 大系統(tǒng)小做 讓一切可擴展要有基礎(chǔ)組件輕松的上線 灰度，灰度，再灰度精細的監(jiān)控 迅速的響應(yīng) 騰訊大講堂 大系統(tǒng)小做從代碼分模

26、塊，到分離部署 靈活的折衷：混搭模式（重要/復(fù)雜邏輯分離，其它混合部署）騰訊大講堂 讓一切可擴展網(wǎng)絡(luò)協(xié)議可擴展 XML描述向前兼容 代碼自動生成（ProtocolBuffer & TLV）數(shù)據(jù)存儲可擴展 KV or TLV字段配置表類SQL處理 騰訊大講堂 要有基礎(chǔ)組件Svrkit：Client/Server自動代碼生成框架10分鐘搭建內(nèi)部服務(wù)器 LogicServer：邏輯容器隨時添加新邏輯 OssAgent：監(jiān)控/統(tǒng)計框架 所見即所得的監(jiān)控報表存儲組件 屏蔽容災(zāi)/擴容等復(fù)雜問題騰訊大講堂

27、灰度，灰度，再灰度騰訊大講堂 You can do it !20個變更/天騰訊大講堂 微信的三位一體產(chǎn)品的精準(zhǔn) 項目的敏捷技術(shù)的支撐 騰訊大講堂 技術(shù)的支撐剝離復(fù)雜，讓剩下的更簡單孫子兵法：古之所謂善戰(zhàn)者，勝于易勝者也騰訊大講堂 騰訊大講堂 http:/djt.q 微信架構(gòu) 關(guān)注復(fù)雜點協(xié)議容災(zāi)輕重監(jiān)控騰訊大講堂 移動互聯(lián)網(wǎng)的復(fù)雜性CMWAP vs. CMNET在線 vs. 離線連接不穩(wěn)定資費敏感 高延遲 騰訊大講堂 h

28、ttp:/ 業(yè)界標(biāo)準(zhǔn)方案Messaging And Presence Protocol XMPPSIP/SIMPLE優(yōu)點： 簡單，大量開源實現(xiàn)缺點流量大：狀態(tài)初始化消息不可靠 把簡單留給自己，把復(fù)雜留給別人？騰訊大講堂 SYNC協(xié)議參考ActiveSync狀態(tài)同步：Sync by SyncKey模式簡化：Notify & Client Pull實現(xiàn)更復(fù)雜，但 騰訊大講堂 讓剩下的更簡單簡化交互模式 最小增量傳輸最優(yōu)重傳控制 More important：消息可靠傳輸 & 按序到達和菜頭 2011/11/26

29、比它炫的沒它簡單， 比它簡單的沒它快， 沒有誰比它更快，哪怕在GPRS下， 微信也能把進度條輕易推到底。騰訊大講堂 關(guān)注復(fù)雜點協(xié)議容災(zāi)輕重監(jiān)控騰訊大講堂 在容災(zāi)之前面向最壞的思考如果真的掛了 防止雪崩，避免蝴蝶效應(yīng)把防雪崩內(nèi)置到組件 柔性可用，追求不完美 只求完美的團隊， 不能勝任海量服務(wù)。0/1完美 = 60分 保護點前置，贏得處理空間終端配合的容災(zāi) 騰訊大講堂 存儲層容災(zāi)分而治之與接入層/邏輯層對比 接入層：GSLB, LVS, IP redirect, Client Retry邏輯層：無

30、狀態(tài)設(shè)計 存儲層容災(zāi)是海量系統(tǒng)最復(fù)雜的設(shè)計分而治之 分離業(yè)務(wù)場景，尋求簡單設(shè)計騰訊大講堂 主備實現(xiàn)簡單 局限 容忍最終一致性故障時不可寫 Example帳號系統(tǒng)騰訊大講堂 雙寫實現(xiàn)簡單 故障時可寫局限 容忍輕度數(shù)據(jù)丟失Example用戶終端類型記錄騰訊大講堂 SET模型雙寫實現(xiàn)簡單（注：SET1寫入不成功時，切換到SET2寫入）完全一致的備份副本局限 只支持追加寫需要外部索引 簡化版Google FSExample語音/圖片存儲騰訊大講堂 Quorum分布式理

31、論 CAP理論PaxosLeslie Lamport Chubby，ZooKeeperQuorum：Amazon DynamoR+WNVector Clock：解決沖突Merkle Tree：節(jié)點恢復(fù) 騰訊大講堂 騰訊大講堂 http:/djt.qq.co Simple Quorum實現(xiàn)SYNC協(xié)議的序列發(fā)生器極高穩(wěn)定度要求 避免Vector Clock：遞增的序列號 避免Merkle Tree：全量加載 一位畢業(yè)生的創(chuàng)意：按SET分布，全量數(shù)據(jù)從2G減到200Km 關(guān)注復(fù)雜點協(xié)議容災(zāi)輕重監(jiān)控騰訊大講堂 終端的迷思復(fù)雜的邏輯 高昂的變更致命的風(fēng)險 前輕后重 功能點后移，發(fā)揮快速變更的優(yōu)勢騰訊大講堂 接入優(yōu)