1、前言
有過移動端開發經歷的開發者都深有體會：移動端IM的開發，與傳統PC端IM有很大的不同，尤其無線網絡的不可靠性、移動端硬件設備資源的有限性等問題，導致一個完整的移動端IM架構設計和實現都充滿著大量的挑戰。本文將簡述移動端IM最重要的架構設計和通信協議選擇方面的坑點，希望為IM開發者同行帶來些許啟發。（本文同步發佈於：http://www.52im.net/thread-289-1-1.html）
2、學習交流
- 即時通訊開發交流群：215891622 [推薦]
- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》
3、概述
移動互聯網時代的來臨促使我們所有的開發者都要從用戶視角出發，基於某一特定場景來創建應用，滿足用戶需求。通常，在這些應用中，溝通環節都是必不可少的。這就要求創業者不僅要花時間和精力來琢磨用戶在某一特定場景下有何痛點需求，琢磨如何解決這一需求，並且可能還要花費更多的精力和時間來解決產品中“溝通”這一技術節點。
而要解決溝通問題，就需要一套IM系統（而且肯定要支持移動端）。做為IM開發者或即將成為IM開發者的技術人員，IM的價值和重要性不言自明。但從技術實現來說，這並不容易。當然，假設你有100個用戶，什麼都是容易的，但是假設你有了100萬、1000萬甚至1億的用戶，再簡單的技術節點解決不好，都會成為災難，何況IM系統（尤其是移動端的IM系統）還是存在許多技術難點和坑點的。
4、有關移動端IM通信協議的坑
其次，我們再看一下IM 協議如何選型。通常IM採取的協議有xmpp、mqtt、protobuf等數據通信私有協議，我們來逐一分析他們的優缺點。
4.1. XMPP協議：
優點：基於xml協議，容易理解，使用廣泛，易於擴展。
缺點：流量大，在移動終端也耗電。交互過程複雜。多被pc時代的產品使用，不適合移動時代的IM產品，即使我們基於xmpp進行改進，簡化握手過程，改進文件傳輸機制，但是它的基因決定了如何改進，他都不適合移動互聯網時代的IM產品。就像鳳姐無論怎麼整容，也變成不了高圓圓一樣。
4.2. MQTT協議：
優點：適配多平臺。
缺點：協議簡單，但是需要自己擴展好友，群組等功能。
4.3. 私有協議：
優點：隨心所欲，自己定義，流量小。
缺點：工作量巨大，擴展性差，需要考慮全面。
4.4. Protobuf協議：
優點：非常小、非常快、非常簡單，一條消息數據用Protobuf序列化後的大小是JSON的1/10、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通信協議設計詳解》）
5、移動端IM客戶端的坑
最後，我們再來了解一下移動端有哪些難點需要解決。
5.1. 流量：
採取哪種協議、圖片縮略圖、附件的壓縮三點決定了流量的大小。
5.2. 耗電：
(1)流量越小，耗電越低。(2)心跳策略，減少心跳次數，耗電量就會降低。
5.3. 心跳時長：
wifi，2G，3G，4G，移動、電信、聯通,不同網絡，不同運行商，NAT失效時間不一樣，因此心跳的時間也就不一樣。
5.4. 網絡連接：
cmnet和cmwap下連接處理機制。
5.5. 網絡不穩定：
移動端最大的特點就是網絡不穩定，在不穩定的網絡狀態下，如何保證消息以最快的速度到達？如何避免重聯風暴？這些既需要從整體架構考慮，也需要在移動端採取巧妙的策略加以避免。
（更多文章：移動端IM開發需要面對的技術問題）
6、移動端IM架構設計的坑
首先，來看移動端IM架構設計需要考慮的問題。
6.1. 連接器的設計：
連接器主要用來管理客戶端的長連接。目前最好的連接器單臺8G8核的服務器可以做到70萬—100萬的連接，而某些開發者只能做到4000左右的連接，相差好幾個數量級。這裡的奧妙在哪裡呢？
6.2. 中間件的設計：
是否採用通訊中間件？通訊中間件的好處有哪些？如果不採用中間件，連接器和邏輯服務器的連接關係如何管理呢？
6.3. 邏輯服務器：
邏輯服務器通常簡單一點，主要是根據業務邏輯進行最小粒度的劃分即可。但是即便如此，還是有很多的開發者把看似相關實則不相關的邏輯放在一起，如把鑑權和message服務器放在一起。
6.4. 狀態服務器：
狀態服務器主要管理用戶在線、離線的相關狀態，需要採取中心節點的方案，否則狀態就會不同步。這裡主要需要考慮狀態服務器所對應的數據存儲機制，如何進行寫操作，如何進行讀操作？以便最大的提高狀態服務器的處理能力和響應速度。
6.5. 數據庫的設計：
數據庫的設計是最難的，也是做大的瓶頸。因為無論對於sql（關係型）數據庫還是nosql（非關係型）數據庫，都有讀寫處理的極限，那就需要考慮數據庫如何分區（根據什麼原則、什麼操作、哪些用戶訪問哪個節點上的數據庫）。同時又需要考慮每個原子操作（如登陸）需要讀哪些庫，寫哪些庫。只有這些指標明確了，你才能在假設有100萬併發用戶，100萬條併發消息的情況下，準確評估服務端需要多少臺服務器，如何部署。
6.6. 其他：
還有設備推送的處理，何種機制能夠保證不丟消息，離線消息如何處理，等等。這些都是必備而又非常複雜的功能點和技術要求，都需要採取正確的架構和策略才能實現。
（更多文章：http://www.52im.net/forum.php?mod=collection&action=view&ctid=7）
7、結語
以上難點和坑點草草記錄下來也不過千把字，但是真正要解決這些問題並達到生產應用標準，卻要不知道花費多少日日夜夜、敲下多少行代碼，恐怕也只有真正做過IM的開發者才有比較深刻的體會。（本文同步發佈於：http://www.52im.net/thread-289-1-1.html）
閱讀更多 移動端IM技術分享 的文章
