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