簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端

時間 2019-11-08

原文原文鏈接

一、前言

有過移動端開發經歷的開發者都深有體會：移動端IM的開發，與傳統PC端IM有很大的不一樣，尤爲無線網絡的不可靠性、移動端硬件設備資源的有限性等問題，致使一個完整的移動端IM架構設計和實現都充滿着大量的挑戰。本文將簡述移動端IM最重要的架構設計和通訊協議選擇方面的坑點，但願爲IM開發者同行帶來些許啓發。（本文同步發佈於：http://www.52im.net/thread-289-1-1.html）
php

二、學習交流

- 即時通信開發交流羣： 215891622 [推薦]html

- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》java

三、概述

移動互聯網時代的來臨促使咱們全部的開發者都要從用戶視角出發，基於某一特定場景來建立應用，知足用戶需求。一般，在這些應用中，溝通環節都是必不可少的。這就要求創業者不只要花時間和精力來琢磨用戶在某一特定場景下有何痛點需求，琢磨如何解決這一需求，而且可能還要花費更多的精力和時間來解決產品中「溝通」這一技術節點。

而要解決溝通問題，就須要一套IM系統（並且確定要支持移動端）。作爲IM開發者或即將成爲IM開發者的技術人員，IM的價值和重要性不言自明。但從技術實現來講，這並不容易。固然，假設你有100個用戶，什麼都是容易的，可是假設你有了100萬、1000萬甚至1億的用戶，再簡單的技術節點解決很差，都會成爲災難，況且IM系統（尤爲是移動端的IM系統）仍是存在許多技術難點和坑點的。python

四、有關移動端IM通訊協議的坑

其次，咱們再看一下IM 協議如何選型。一般IM採起的協議有xmpp、mqtt、protobuf等數據通訊私有協議，咱們來逐一分析他們的優缺點。

1. XMPP協議：android

優勢：基於xml協議，容易理解，使用普遍，易於擴展。
缺點：流量大，在移動終端也耗電。交互過程複雜。多被pc時代的產品使用，不適合移動時代的IM產品，即便咱們基於xmpp進行改進，簡化握手過程，改進文件傳輸機制，可是它的基因決定了如何改進，他都不適合移動互聯網時代的IM產品。就像鳳姐不管怎麼整容，也變成不了高圓圓同樣。

2. MQTT協議：c++

優勢：適配多平臺。
缺點：協議簡單，可是須要本身擴展好友，羣組等功能。

3. 私有協議：算法

優勢：爲所欲爲，本身定義，流量小。
缺點：工做量巨大，擴展性差，須要考慮全面。

4. Protobuf協議：sql

優勢：很是小、很是快、很是簡單，一條消息數據用Protobuf序列化後的大小是JSON的1/十、XML格式的1/20、是二進制序列化的1/10。
缺點：不能表示複雜的數據結構，可是對於IM來說，已經足夠。強烈推薦此協議。

補充1：強列建議使用Protobuf，理由以下數據庫

靈活、高效：靈活（方便接口更新）、高效（效率通過google的優化，傳輸效率比普通的XML等高不少）；
易於使用：開發人員經過按照必定的語法定義結構化的消息格式，而後送給命令行工具，工具將自動生成相關的類，能夠支持java、c++、python等語言環境。經過將這些類包含在項目中，能夠很輕鬆的調用相關方法來完成業務消息的序列化與反序列化工做。
語言支持：原生支持c++、java、python等多達10餘種語言。

補充2：Protobuf主要適用於編程

須要和其它系統作消息交換的，對消息大小很敏感的。那麼protobuf適合了，它語言無關，消息空間相對xml和json等節省不少。
小數據的場合。若是你是大數據，用它並不適合。
項目語言是c++、java、python等，由於它們可使用google的源生類庫，序列化和反序列化的效率很是高。其它的語言須要第三方或者本身寫，序列化和反序列化的效率不保證。

整體而言，Protobuf仍是很是好用的，被不少開源系統用於數據通訊的工具，在google也是核心的基礎庫。

（更多文章：《強列建議將Protobuf做爲你的即時通信應用數據傳輸格式》、《如何選擇即時通信應用的數據傳輸格式》、《理論聯繫實際：一套典型的IM通訊協議設計詳解》）

五、移動端IM客戶端的坑

最後，咱們再來了解一下移動端有哪些難點須要解決。

1. 流量：
採起哪一種協議、圖片縮略圖、附件的壓縮三點決定了流量的大小。

2. 耗電：
(1)流量越小，耗電越低。(2)心跳策略，減小心跳次數，耗電量就會下降。

3. 心跳時長：
wifi，2G，3G，4G，移動、電信、聯通,不一樣網絡，不一樣運行商，NAT失效時間不同，所以心跳的時間也就不同。

4. 網絡鏈接：
cmnet和cmwap下鏈接處理機制。

5. 網絡不穩定：
移動端最大的特色就是網絡不穩定，在不穩定的網絡狀態下，如何保證消息以最快的速度到達？如何避免重聯風暴？這些既須要從總體架構考慮，也須要在移動端採起巧妙的策略加以免。

（更多文章：移動端IM開發須要面對的技術問題）

六、移動端IM架構設計的坑

首先，來看移動端IM架構設計須要考慮的問題。

1. 鏈接器的設計：
鏈接器主要用來管理客戶端的長鏈接。目前最好的鏈接器單臺8G8核的服務器能夠作到70萬—100萬的鏈接，而某些開發者只能作到4000左右的鏈接，相差好幾個數量級。這裏的奧妙在哪裏呢？

2. 中間件的設計：
是否採用通信中間件？通信中間件的好處有哪些？若是不採用中間件，鏈接器和邏輯服務器的鏈接關係如何管理呢？

3. 邏輯服務器：
邏輯服務器一般簡單一點，主要是根據業務邏輯進行最小粒度的劃分便可。可是即使如此，仍是有不少的開發者把看似相關實則不相關的邏輯放在一塊兒，如把鑑權和message服務器放在一塊兒。

4. 狀態服務器：
狀態服務器主要管理用戶在線、離線的相關狀態，須要採起中心節點的方案，不然狀態就會不一樣步。這裏主要須要考慮狀態服務器所對應的數據存儲機制，如何進行寫操做，如何進行讀操做？以便最大的提升狀態服務器的處理能力和響應速度。

5. 數據庫的設計：
數據庫的設計是最難的，也是作大的瓶頸。由於不管對於sql（關係型）數據庫仍是nosql（非關係型）數據庫，都有讀寫處理的極限，那就須要考慮數據庫如何分區（根據什麼原則、什麼操做、哪些用戶訪問哪一個節點上的數據庫）。同時又須要考慮每一個原子操做（如登錄）須要讀哪些庫，寫哪些庫。只有這些指標明確了，你才能在假設有100萬併發用戶，100萬條併發消息的狀況下，準確評估服務端須要多少臺服務器，如何部署。

6. 其餘：
還有設備推送的處理，何種機制可以保證不丟消息，離線消息如何處理，等等。這些都是必備而又很是複雜的功能點和技術要求，都須要採起正確的架構和策略才能實現。

（更多文章：http://www.52im.net/forum.php?mod=collection&action=view&ctid=7）