移動互聯網時代的來臨促使我們所有的開發者都要從用戶視角出發，基于某一特定場景來創建應用，滿足用戶需求。通常，在這些應用中，溝通環節都是必不可少的。這就要求創業者不僅要花時間和精力來琢磨用戶在某一特定場景下有何痛點需求，琢磨如何解決這一需求，并且可能還要花費更多的精力和時間來解決產品中“溝通”這一技術節點。而要解決溝通問題，就需要一套IM系統，這并不容易。當然，假設你有100個用戶，什么都是容易的，但是假設你有了100萬、1000萬甚至1億的用戶，再簡單的技術節點解決不好，都會成為災難，何況IM系統還是存在許多技術難點和坑點的。今天，我們就來梳理一下IM開發中那些可能遇到的難點及坑點。
首先，來看服務端需要考慮的問題。
1.連接器的設計：連接器主要用來管理客戶端的長連接。目前最好的連接器單臺8G8核的服務器可以做到70萬—100萬的連接，而某些開發者只能做到4000左右的連接，相差好幾個數量級。這里的奧妙在哪里呢？
2.中間件的設計：是否采用通訊中間件？通訊中間件的好處有哪些？如果不采用中間件，連接器和邏輯服務器的連接關系如何管理呢？
3.邏輯服務器：邏輯服務器通常簡單一點，主要是根據業務邏輯進行最小粒度的劃分即可。但是即便如此，還是有很多的開發者把看似相關實則不相關的邏輯放在一起，如把鑒權和message服務器放在一起。
4.狀態服務器：狀態服務器主要管理用戶在線、離線的相關狀態，需要采取中心節點的方案，否則狀態就會不同步。這里主要需要考慮狀態服務器所對應的數據存儲機制，如何進行寫操作，如何進行讀操作？以便最大的提高狀態服務器的處理能力和響應速度。
5.數據庫的設計：數據庫的設計是最難的，也是做大的瓶頸。因為無論對于sql（關系型）數據庫還是nosql（非關系型）數據庫，都有讀寫處理的極限，那就需要考慮數據庫如何分區（根據什么原則、什么操作、哪些用戶訪問哪個節點上的數據庫）。同時又需要考慮每個原子操作（如登陸）需要讀哪些庫，寫哪些庫。只有這些指標明確了，你才能在假設有100萬并發用戶，100萬條并發消息的情況下，準確評估服務端需要多少臺服務器，如何部署。
6.其他：還有設備推送的處理，何種機制能夠保證不丟消息，離線消息如何處理，等等。這些都是必備而又非常復雜的功能點和技術要求，都需要采取正確的架構和策略才能實現。
其次，我們再看一下IM 協議如何選型。通常IM采取的協議有xmpp、mqtt和私有協議，我們來逐一分析他們的優缺點。
1.xmpp協議：
a)優點：基于xml協議，容易理解，使用廣泛，易于擴展。
b)缺點：流量大，在移動終端也耗電。交互過程復雜。多被pc時代的產品使用，不適合移動時代的IM產品，即使我們基于xmpp進行改進，簡化握手過程，改進文件傳輸機制，但是它的基因決定了如何改進，他都不適合移動互聯網時代的IM產品。就像鳳姐無論怎么整容，也變成不了高圓圓一樣。
2.mqtt協議：
a)優點：適配多平臺。
b)缺點：協議簡單，但是需要自己擴展好友，群組等功能。
3. 私有協議：
a) 優點:隨心所欲，自己定義，流量小。
b) 缺點：工作量巨大，擴展性差，需要考慮全面。
4.protbuf協議：
a)優點：非常小，非?？?，非常簡單。
b)缺點：不能表示復雜的數據結構，但是對于IM來講，已經足夠。強烈推薦此協議。
最后，我們再來了解一下移動端有哪些難點需要解決。
1.流量：采取哪種協議、圖片縮略圖、附件的壓縮三點決定了流量的大小。
2.耗電：(1)流量越小，耗電越低。(2)心跳策略，減少心跳次數，耗電量就會降低。
3.心跳時長：wifi，2G，3G，4G，移動、電信、聯通,不同網絡，不同運行商，NAT失效時間不一樣，因此心跳的時間也就不一樣。
4.網絡連接：cmnet和cmwap下連接處理機制。
5.網絡不穩定：移動端最大的特點就是網絡不穩定，在不穩定的網絡狀態下，如何保證消息以最快的速度到達？如何避免重聯風暴？這些既需要從整體架構考慮，也需要在移動端采取巧妙的策略加以避免。
這些難點寫下來只不過千把字，耗時三十幾分鐘，但是真正要解決這些難點卻要不知道花費多少日日夜夜，敲下多少行代碼。因此，對于那些在某一場景下需要溝通能力的產品——O2O，互聯網教育，互聯網醫療、游戲…建議這些創業者把精力和資源都放在自己的核心能力上，而溝通就放心的交給我們容聯云通訊IM吧——因為那些難點，我們都已經完美的干掉了他們。
還不了解云通訊IM？那就在4月21日，來參加云通訊開發者俱樂部第二期線上公開課吧，主講人云通訊IM產品線總監張靖宇，屆時會為開發者詳細講解云通訊IM，開發者也可互相探討自己在開發過程中遇到的其他問題。
京公網安備 11010502049343號