對(duì)微信、陌陌等進(jìn)行了分析，發(fā)出來(lái)分享一下（時(shí)間有些久了）
電量：對(duì)于移動(dòng)設(shè)備最大的瓶頸就是電量了。因?yàn)橛脩舨豢赡茈S時(shí)攜帶電源，充電寶。所以必須考慮到電量問(wèn)題。那就要檢查我們工程是不是有后臺(tái)運(yùn)行，心跳包發(fā)送時(shí)間是不是合理。
流量：對(duì)于好多國(guó)內(nèi)大部分屌絲用戶來(lái)說(shuō)可能還是包月30M，那么我們必須站在廣大用戶角度來(lái)考慮問(wèn)題了。一個(gè)包可以解決的就一個(gè)包。
網(wǎng)絡(luò)：
這個(gè)也是IM最核心的內(nèi)容了，我們要做到在任何網(wǎng)絡(luò)下等順暢聊天那就不容易了，好多公司都用的xmpp框架，如果在強(qiáng)網(wǎng)絡(luò)環(huán)境下，xmpp完全沒(méi)有問(wèn)題。但是那種弱網(wǎng)絡(luò)環(huán)境下xmpp就束手無(wú)策啦，用戶體驗(yàn)就很垃圾了。
個(gè)人覺(jué)得xmpp 可以玩玩（參考看這個(gè)RFC3920和RFC3921 ）， 但是用來(lái)真正的產(chǎn)品就差遠(yuǎn)了。如果遇到一個(gè)做IM 的朋友張口閉口都說(shuō)xmpp 的話，那么不用溝通了，肯定不是什么好產(chǎn)品。微信、QQ以前也曾用過(guò)xmpp，但是最后也放棄了xmpp，就知道xmpp有很多弊端了，還有就是報(bào)文太大，好臃腫，浪費(fèi)流量。為了保證穩(wěn)定，微信用了長(zhǎng)鏈接和短鏈接相結(jié)合，例如： 1 、兩個(gè)域名
微信劃分了http模式（short鏈接）和 tcp 模式（long 鏈接），分別應(yīng)對(duì)狀態(tài)協(xié)議和數(shù)據(jù)傳輸協(xié)議
2 說(shuō)明
是HTTP協(xié)議擴(kuò)展，運(yùn)行8080 端口，http body為二進(jìn)制（protobuf）。
主要用途（接口）：
用戶登錄驗(yàn)證;
好友關(guān)系（獲取，添加）；
消息sync (newsync)，自有sync機(jī)制；
獲取用戶圖像；
用戶注銷；
行為日志上報(bào)。
朋友圈發(fā)表刷新
tcp 長(zhǎng)連接， 端口為8080，類似微軟activesync的二進(jìn)制協(xié)議。
主要用途（接口）：
接受/發(fā)送文本消息；
接受/發(fā)送語(yǔ)音；
接受/發(fā)送圖片；
接受/發(fā)送視頻文件等。
所有上面請(qǐng)求都是基于tcp長(zhǎng)連接。在發(fā)送圖片和視頻文件等時(shí)，分為兩個(gè)請(qǐng)求；第一個(gè)請(qǐng)求是縮略圖的方式，第二個(gè)請(qǐng)求是全數(shù)據(jù)的方式。
2.2.1 數(shù)據(jù)報(bào)文方面
增量上傳策略：
每次8k左右大小數(shù)據(jù)上傳，服務(wù)器確認(rèn)；在繼續(xù)傳輸。
圖片上傳：
先傳縮略圖，傳文本消息，再傳具體文件
下載：
先下載縮略圖， 在下載原圖
下載的時(shí)候，全部一次推送。
3 附錄
3.1 用戶登錄驗(yàn)證
POST /cgi-bin/micromsg-bin/auth HTTP/1.1
Accept: **
User-Agent: Mozilla/4.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 174
3.3 消息sync (newsync)
POST /cgi-bin/micromsg-bin/newsync HTTP/1.1
User-Agent: Android QQMail HTTP Client
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: application/octet-stream
accept: **
Content-Length: 206
3.5 用戶注銷
POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0
Cotent-Type: application/x-www-form-urlencoded
Content-Length: 271
3.6 行為日志上報(bào)
POST /cgi-bin/stackreport?version=240000a7&filelength=1258&sum=7eda777ee26a76a5c93b233eed504c7d&reporttype=1&username=jolestar HTTP/1.1
Content-Length: 736
Content-Type: binary/octet-stream
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
從現(xiàn)在互聯(lián)網(wǎng)的發(fā)展而言，IM和視頻（包括IM里面視頻通話）是一個(gè)方向，這些都應(yīng)該成為互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施，就像瀏覽器一樣?，F(xiàn)在IM還沒(méi)有一個(gè)很好的解決方案，XMPP并不能很好地做到業(yè)務(wù)邏輯獨(dú)立開(kāi)來(lái)。從IM的本質(zhì)來(lái)看，IM其實(shí)就是將一條消息從一個(gè)地方傳輸?shù)搅硗庖粋€(gè)地方，這個(gè)和TCP很像，為什么不實(shí)現(xiàn)一個(gè)高級(jí)點(diǎn)的TCP協(xié)議了，只是將TCP/IP里面的IP地址換成了一個(gè)類似XMPP的唯一ID而已，其他的很多細(xì)節(jié)都可以照搬TCP協(xié)議。有了這個(gè)協(xié)議之后，將業(yè)務(wù)邏輯在現(xiàn)有HTTP server的基礎(chǔ)上做，例如發(fā)送語(yǔ)音和圖片就相當(dāng)于上傳一個(gè)文件，服務(wù)器在處理完這個(gè)文件后就發(fā)一條特殊的IM消息?？蛻舳耸盏竭@個(gè)IM消息后，按照IM消息里面url去HTTP server取語(yǔ)音文件和圖片文件。將HTTP server和IM server打通之后，可以做很多事情。但將這個(gè)兩個(gè)server合并在一塊并不是一個(gè)好事，不然騰訊也不會(huì)有2005年的戰(zhàn)略轉(zhuǎn)型了。從現(xiàn)在的情況來(lái)看，應(yīng)用除了游戲，都沒(méi)怎么賺錢，現(xiàn)在能夠承載賺錢業(yè)務(wù)的還是以web為主。IM不可以賺錢，但沒(méi)有卻是不行的，就像一個(gè)地方要致富，不修路是不行的道理一樣。
上面說(shuō)到了protobuf ，就簡(jiǎn)單介紹下：
JSON相信大家都知道是什么東西，如果不知道，那可就真的OUT了，GOOGLE一下去。這里就不介紹啥的了。
Protobuffer大家估計(jì)就很少聽(tīng)說(shuō)了，但如果說(shuō)到是GOOGLE搞的，相信大家都會(huì)有興趣去試一下，畢竟GOOGLE出口，多屬精品。
Protobuffer是一個(gè)類似JSON的一個(gè)傳輸協(xié)議，其實(shí)也不能說(shuō)是協(xié)議，只是一個(gè)數(shù)據(jù)傳輸?shù)臇|西罷了。
那它跟JSON有什么區(qū)別呢？
跨語(yǔ)言，這是它的一個(gè)優(yōu)點(diǎn)。它自帶了一個(gè)編譯器，protoc，只需要用它進(jìn)行編譯，可以編譯成JAVA、python、C++代碼，暫時(shí)只有這三個(gè)，其他就暫時(shí)不要想了，然后就可以直接使用，不需要再寫任何其他代碼。連解析的那些都已經(jīng)自帶有的。JSON當(dāng)然也是跨語(yǔ)言的，但這個(gè)跨語(yǔ)言是建立在編寫代碼的基礎(chǔ)上。
陌陌設(shè)計(jì)：
陌陌發(fā)展剛開(kāi)始由于規(guī)模小，30-40W的連接數(shù)（包括Android后臺(tái)長(zhǎng)連接用戶），也使用XMPP；由于XMPP的缺點(diǎn)：流量大（基于XML），不可靠（為傳統(tǒng)固定網(wǎng)絡(luò)設(shè)計(jì)，沒(méi)有考慮WIFI/2G/3G/地鐵/電梯等復(fù)雜網(wǎng)絡(luò)場(chǎng)景），交互復(fù)雜（登陸需5-6次，尤其是TLS握手）；XMPP丟消息的根本原因：服務(wù)端和客戶端處于“半關(guān)閉”狀態(tài)，客戶端假連接狀態(tài)，服務(wù)端有收不到回執(zhí)；Server端連接層和邏輯層代碼沒(méi)有解耦分離，常常重啟導(dǎo)致不可用；
消息中轉(zhuǎn)：
鏈接層：
邏輯層：
通訊協(xié)議設(shè)計(jì)：
高效：弱網(wǎng)絡(luò)快速的收發(fā)
可靠：不會(huì)丟消息
易于擴(kuò)展
協(xié)議格式：
Redis協(xié)議：
是啊發(fā)
阿薩德發(fā)阿發(fā)a
優(yōu)化
連接層（參見(jiàn)通訊服務(wù)器組成）：只做消息轉(zhuǎn)發(fā)，允許隨時(shí)重啟更新，設(shè)計(jì)原則簡(jiǎn)單/異步；單臺(tái)壓測(cè)試連接數(shù)70W；現(xiàn)狀：1.5億用戶，月活5000W+，連接數(shù)1200W+；
邏輯層（參見(jiàn)通訊服務(wù)器組成）：用戶會(huì)話驗(yàn)證即登陸、消息存取、異步隊(duì)列
采用私有通訊協(xié)議，目標(biāo)：高效，弱網(wǎng)絡(luò)快速收發(fā)；可靠：不會(huì)丟消息；易于擴(kuò)展；參考協(xié)議格式：REDIS協(xié)議；參見(jiàn)協(xié)議格式、基于隊(duì)列的消息協(xié)議、基于隊(duì)列的交互、基于版本號(hào)的消息協(xié)議、基于版本號(hào)的交互等；
核心的長(zhǎng)連接只用于傳輸輕量的實(shí)時(shí)數(shù)據(jù)，圖片、語(yǔ)音等都開(kāi)新的TCP或HTTP連接；
一切就緒后，最重要的就是監(jiān)控，寫一個(gè)APP查看所有的運(yùn)營(yíng)狀態(tài)，每天觀察；
如何選擇最優(yōu)路線，即智能路由；
二、智能路由、連接策略：
多端口、雙協(xié)議支持
應(yīng)對(duì)移動(dòng)網(wǎng)關(guān)代理的端口限制
支持TCP、HTTP兩種協(xié)議
根據(jù)備選IP列表進(jìn)行并發(fā)測(cè)速（IP+端口+協(xié)議）
后端根據(jù)終端連接情況，定時(shí)更新終端的備選IP列表
終端在連接空閑時(shí)上報(bào)測(cè)速數(shù)據(jù)，便于后端決策
TCP協(xié)議不通，自動(dòng)切換到http
優(yōu)先使用最近可用IP
并發(fā)測(cè)速，根據(jù)終端所處的位置下發(fā)多組IP、PORT，只用IP，不用域名，手機(jī)上的DNS50%不準(zhǔn)
負(fù)載均衡器(LVS...)的問(wèn)題– 單點(diǎn)失效
單點(diǎn)性能瓶頸
負(fù)載均衡從客戶端開(kāi)始做起· 域名負(fù)載的問(wèn)題
域名系統(tǒng)不可靠– 更新延遲大
WNS（wireless network services）
1解決移動(dòng)互聯(lián)網(wǎng)開(kāi)發(fā)常見(jiàn)問(wèn)題：
通道：數(shù)據(jù)交互、大數(shù)據(jù)上傳、push
網(wǎng)絡(luò)連接：大量長(zhǎng)鏈接管理、鏈接不上、慢、多地分布
運(yùn)營(yíng)支撐：海量監(jiān)控、簡(jiǎn)化問(wèn)題定位
登錄&安全：登錄鑒權(quán)、頻率控制
移動(dòng)互聯(lián)網(wǎng)特點(diǎn)：
1、高延時(shí)： 信道建立耗時(shí)（ 高RTT）
2、低寬帶、高丟包
3、多運(yùn)營(yíng)商（電信，移動(dòng)，聯(lián)通等）
4、復(fù)雜網(wǎng)絡(luò)
－2G，3G，4G，wifi。cmwap，cmnet。。
－網(wǎng)關(guān)限制：協(xié)議，端口
5、用戶流動(dòng)性大，上網(wǎng)環(huán)境復(fù)雜
WNS 性能指標(biāo)：
1、開(kāi)發(fā)時(shí)間：歷史一年半
2、鏈接成功率－99.9%
3、極端網(wǎng)絡(luò)環(huán)境下成功率－由于常見(jiàn)app
4、crash率 －0.02%（crash次數(shù)／登錄用戶數(shù)）
微信后臺(tái)系統(tǒng)架構(gòu)
背景：
A、分布式問(wèn)題收斂
后臺(tái)邏輯模塊專注邏輯，快速開(kāi)發(fā)
可能讀取到過(guò)時(shí)的數(shù)據(jù)是個(gè)痛點(diǎn)
需要看到一致的數(shù)據(jù)
B、內(nèi)部定義
數(shù)據(jù)擁有兩個(gè)以上的副本
如果成功提交了變更，那么不會(huì)再返回舊數(shù)據(jù)
推演：
1增加一個(gè)數(shù)據(jù)
2 序列號(hào)發(fā)生器，偏序
約束：只能有一個(gè)client操作
client有解決沖突的能力
問(wèn)題轉(zhuǎn)移：client如何分布？
3 修改集群中一個(gè)制定的key的value
1）覆蓋他
2）根據(jù)value的內(nèi)容做修改
if value ＝ 1 then value ：＝2
通用解法：
1）paxos算法
工程難度
一切可控
分布式算法設(shè)計(jì)：
2）quorum算法（2011）
再單個(gè)key上面運(yùn)算
真是系統(tǒng)約束
類paxos方案，簡(jiǎn)化
為每次變更選舉（by key）
算法過(guò)程
提議／變更／同步／廣播
系統(tǒng)架構(gòu)
寫流程
Replication & Sharding
權(quán)衡點(diǎn)
自治，負(fù)載均衡，擴(kuò)散控制
replication－>relation
容災(zāi)抵消
同城（上海）多數(shù)派存活
三園區(qū)（獨(dú)立供電，獨(dú)立）
Sharding
一組KV6 為一個(gè)單位
1、人工階段
局部擴(kuò)容，影響收斂9
2均勻分布 制定分段hash32 （string）
翻倍擴(kuò)容
3一致性哈希
具體實(shí)現(xiàn)？
1、業(yè)務(wù)側(cè)快速開(kāi)發(fā)
存儲(chǔ)需要提供強(qiáng)一致性
豐富的數(shù)據(jù)模型支持（結(jié)構(gòu)化、類SQL／KV）
條件讀，條件寫
2 業(yè)務(wù)增長(zhǎng)迅速，系統(tǒng)要能夠方便的橫向擴(kuò)容
3設(shè)備故障／短時(shí)節(jié)點(diǎn)實(shí)效便成為常態(tài)，容災(zāi)自動(dòng)化，主碑可寫無(wú)需人工介入
4小數(shù)據(jù)
存儲(chǔ)模型
純內(nèi)存
Bitcask
小表系統(tǒng)
LSM－tree
小表系統(tǒng)
1、解決放大問(wèn)題
2、數(shù)據(jù)按變更聚集存儲(chǔ)
3、Affected1
ChangeTable
（1＋2+。。。。＋n－1+total）／n
4、分裂與合并
數(shù)據(jù)流動(dòng)
1、自動(dòng)化遷移
2、節(jié)點(diǎn)同時(shí)做代理
3、合并磁盤io
同步流量
1、數(shù)據(jù)vs 操作
2、冪等
3、保底策略
通信包量
1、動(dòng)態(tài)合并
100K qps
200% －10%
3、權(quán)衡與估算
設(shè)計(jì)要點(diǎn)
1、吞吐量
2、異步化
3、復(fù)雜度
4、libco
自動(dòng)修復(fù)系統(tǒng)
1、不要讓錯(cuò)誤累計(jì)
2、全量掃描
bitcask 的一些變化
1、內(nèi)存限制
2、全內(nèi)存
