微信、陌陌等著名IM軟件設計架構詳解【轉】

原貼http://blog.csdn.net/justinjing0612/article/details/38322353

對微信、陌陌等進行了分析，發出來分享一下（時間有些久了）

電量：對於移動設備最大的瓶頸就是電量了。由於用戶不可能隨時攜帶電源，充電寶。因此必須考慮到電量問題。那就要檢查咱們工程是否是有後臺運行，心跳包發送時間是否是合理。

流量：對於好多國內大部分屌絲用戶來講可能仍是包月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協議：

 

 

 

 

 

 

 

 

 

是啊發

 

 

 

 

 

 

 

 

 

阿薩德發阿發a

 

 

 

 

優化

   鏈接層（參見通信服務器組成）：只作消息轉發，容許隨時重啓更新，設計原則簡單/異步；單臺壓測試鏈接數70W；現狀：1.5億用戶，月活5000W+，鏈接數1200W+；
   邏輯層（參見通信服務器組成）：用戶會話驗證即登錄、消息存取、異步隊列
   採用私有通信協議，目標：高效，弱網絡快速收發；可靠：不會丟消息；易於擴展；參考協議格式：REDIS協議；參見協議格式、基於隊列的消息協議、基於隊列的交互、基於版本號的消息協議、基於版本號的交互等；
   核心的長鏈接只用於傳輸輕量的實時數據，圖片、語音等都開新的TCP或HTTP鏈接；
            一切就緒後，最重要的就是監控，寫一個APP查看全部的運營狀態，天天觀察；
   如何選擇最優路線，即智能路由；
2、智能路由、鏈接策略：
多端口、雙協議支持
應對移動網關代理的端口限制
         支持TCP、HTTP兩種協議
         根據備選IP列表進行併發測速（IP+端口+協議）
         後端根據終端鏈接狀況，定時更新終端的備選IP列表
         終端在鏈接空閒時上報測速數據，便於後端決策
         TCP協議不通，自動切換到http
         優先使用最近可用IP
        併發測速，根據終端所處的位置下發多組IP、PORT，只用IP，不用域名，手機上的DNS50%不許

負載均衡器(LVS...)的問題– 單點失效

      單點性能瓶頸
      負載均衡從客戶端開始作起• 域名負載的問題

      域名系統不可靠– 更新延遲大  

WNS（wireless network services）

1解決移動互聯網開發常見問題：

通道：數據交互、大數據上傳、push

網絡鏈接：大量長連接管理、連接不上、慢、多地分佈

運營支撐：海量監控、簡化問題定位

登陸&安全：登陸鑑權、頻率控制

 

移動互聯網特色：

一、高延時：  信道創建耗時（ 高RTT）

二、低寬帶、高丟包

三、多運營商（電信，移動，聯通等）

四、複雜網絡  

    －2G，3G，4G，wifi。cmwap，cmnet。。

    －網關限制：協議，端口

五、用戶流動性大，上網環境複雜

 

WNS 性能指標：

 

一、開發時間：歷史一年半

二、連接成功率－99.9%

三、極端網絡環境下成功率－因爲常見app

四、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 爲一個單位

 

一、人工階段

 局部擴容，影響收斂9

2均勻分佈 制定分段hash32 （string）

 翻倍擴容

 

3一致性哈希

具體實現？

一、業務側快速開發

 存儲須要提供強一致性

豐富的數據模型支持（結構化、類SQL／KV）

條件讀，條件寫

 

2 業務增加迅速，系統要可以方便的橫向擴容

3設備故障／短時節點實效便成爲常態，容災自動化，主碑可寫無需人工介入

4小數據

存儲模型

 純內存

Bitcask

小表系統

LSM－tree

 

 

小表系統

一、解決放大問題

二、數據按變動彙集存儲

三、Affected1

   ChangeTable

（1＋2+。。。。＋n－1+total）／n

四、分裂與合併

數據流動

一、自動化遷移

二、節點同時作代理

三、合併磁盤io

 

同步流量

一、數據vs 操做

二、冪等

三、保底策略

 

通訊包量

 一、動態合併

    100K qps

    200% －10%

三、權衡與估算

設計要點

一、吞吐量

二、異步化

三、複雜度

四、libco

自動修復系統

一、不要讓錯誤累計

二、全量掃描

bitcask 的一些變化

一、內存限制

二、全內存