微信、陌陌等著名IM軟件設計架構詳解-低手解讀

原文 ：微信、陌陌等著名IM軟件設計架構詳解
1 什麼是IP直連？
參考：
DNS優化之IP直連
android httpclient 服務器 ip 直連問題
(移動互聯網中，DNS解析的失敗率是聯網失敗中佔比很大的一種。爲了優化這個問題，我們使用了IP直連。即，從服務器拉取一個配置文件，裏面包含域名到IP映射。客戶端每次聯網時根據域名在配置文件中查找到對應IP，直接使用IP進行請求……)
2 protobuf 是什麼協議？
參考：
開源點評：Protocol Buffers介紹
（簡單地說，這個東東干的事兒其實和XML差不多，也就是把某種數據結構的信息，以某種格式保存起來。主要用於數據存儲、傳輸協議格式等 場合。有同學可能心理犯嘀咕了：放着好好的XML不用，幹嘛重新發明輪子啊？！先別急，後面俺自然會有說道。話說到了去年（大約是08年7 月），Google突然大發慈悲，把這個好東西貢獻給了開源社區。這下，像俺這種喜歡撿現成的傢伙可就有福啦！貌似喜歡撿現成的傢伙還蠻多滴，再加上Google的號召力，開源後不到一年，protobuf的人氣就已經很旺了……）
3 如何針對弱網絡優化協議？

4 智能路由、連接策略有哪些？
多端口、雙協議支持
應對移動網關代理的端口限制
支持TCP、HTTP兩種協議
根據備選IP列表進行併發測速（IP+端口+協議）
後端根據終端連接情況，定時更新終端的備選IP列表
終端在連接空閒時上報測速數據，便於後端決策
TCP協議不通，自動切換到http
優先使用最近可用IP
併發測速，根據終端所處的位置下發多組IP、PORT，只用IP，不用域名，手機上的DNS50%不準
負載均衡器(LVS…)的問題– 單點失效
單點性能瓶頸
負載均衡從客戶端開始做起• 域名負載的問題
域名系統不可靠– 更新延遲大
5 客戶端優化
–使用一收一發的消息隊列方式處理
–使用Android service可被系統隨時喚醒
–獨立進程，更輕量與app進程互不影響
–使用native socket精確調優、提高成功率
–多線程連接多個後臺，最快建立連接，連接測速，記錄最優ip（如何測速？？？？記錄響應時間？）
–保持長鏈接，不使用http協議，反域名劫持，IP直連
–添加重試策略