移動互聯(lián)網(wǎng)時代的來臨促使我們所有的開發(fā)者都要從用戶視角出發(fā)，基于某一特定場景來創(chuàng)建應用，滿足用戶需求。通常，在這些應用中，溝通環(huán)節(jié)都是必不可少的。這就要求創(chuàng)業(yè)者不僅要花時間和精力來琢磨用戶在某一特定場景下有何痛點需求，琢磨如何解決這一需求，并且可能還要花費更多的精力和時間來解決產(chǎn)品中“溝通”這一技術節(jié)點。而要解決溝通問題，就需要一套IM系統(tǒng)，這并不容易。當然，假設你有100個用戶，什么都是容易的，但是假設你有了100萬、1000萬甚至1億的用戶，再簡單的技術節(jié)點解決不好，都會成為災難，何況IM系統(tǒng)還是存在許多技術難點和坑點的。今天，我們就來梳理一下IM開發(fā)中那些可能遇到的難點及坑點。

首先，來看服務端需要考慮的問題。

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

2.中間件的設計：是否采用通訊中間件？通訊中間件的好處有哪些？如果不采用中間件，連接器和邏輯服務器的連接關系如何管理呢？

3.邏輯服務器：邏輯服務器通常簡單一點，主要是根據(jù)業(yè)務邏輯進行最小粒度的劃分即可。但是即便如此，還是有很多的開發(fā)者把看似相關實則不相關的邏輯放在一起，如把鑒權和message服務器放在一起。

4.狀態(tài)服務器：狀態(tài)服務器主要管理用戶在線、離線的相關狀態(tài)，需要采取中心節(jié)點的方案，否則狀態(tài)就會不同步。這里主要需要考慮狀態(tài)服務器所對應的數(shù)據(jù)存儲機制，如何進行寫操作，如何進行讀操作？以便最大的提高狀態(tài)服務器的處理能力和響應速度。

5.數(shù)據(jù)庫的設計：數(shù)據(jù)庫的設計是最難的，也是做大的瓶頸。因為無論對于sql（關系型）數(shù)據(jù)庫還是nosql（非關系型）數(shù)據(jù)庫，都有讀寫處理的極限，那就需要考慮數(shù)據(jù)庫如何分區(qū)（根據(jù)什么原則、什么操作、哪些用戶訪問哪個節(jié)點上的數(shù)據(jù)庫）。同時又需要考慮每個原子操作（如登陸）需要讀哪些庫，寫哪些庫。只有這些指標明確了，你才能在假設有100萬并發(fā)用戶，100萬條并發(fā)消息的情況下，準確評估服務端需要多少臺服務器，如何部署。

6.其他：還有設備推送的處理，何種機制能夠保證不丟消息，離線消息如何處理，等等。這些都是必備而又非常復雜的功能點和技術要求，都需要采取正確的架構和策略才能實現(xiàn)。

?

其次，我們再看一下IM?協(xié)議如何選型。通常IM采取的協(xié)議有xmpp、mqtt和私有協(xié)議，我們來逐一分析他們的優(yōu)缺點。

1.xmpp協(xié)議：

a)優(yōu)點：基于xml協(xié)議，容易理解，使用廣泛，易于擴展。

b)缺點：流量大，在移動終端也耗電。交互過程復雜。多被pc時代的產(chǎn)品使用，不適合移動時代的IM產(chǎn)品，即使我們基于xmpp進行改進，簡化握手過程，改進文件傳輸機制，但是它的基因決定了如何改進，他都不適合移動互聯(lián)網(wǎng)時代的IM產(chǎn)品。就像鳳姐無論怎么整容，也變成不了高圓圓一樣。

2.mqtt協(xié)議：

a)優(yōu)點：適配多平臺。

b)缺點：協(xié)議簡單，但是需要自己擴展好友，群組等功能。

3.??私有協(xié)議：

a)優(yōu)點:隨心所欲，自己定義，流量小。

b)缺點：工作量巨大，擴展性差，需要考慮全面。

4.protbuf協(xié)議：

a)優(yōu)點：非常小，非常快，非常簡單。

b)缺點：不能表示復雜的數(shù)據(jù)結構，但是對于IM來講，已經(jīng)足夠。強烈推薦此協(xié)議。

最后，我們再來了解一下移動端有哪些難點需要解決。

1.流量：采取哪種協(xié)議、圖片縮略圖、附件的壓縮三點決定了流量的大小。

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

3.心跳時長：wifi，2G，3G，4G，移動、電信、聯(lián)通,不同網(wǎng)絡，不同運行商，NAT失效時間不一樣，因此心跳的時間也就不一樣。

4.網(wǎng)絡連接：cmnet和cmwap下連接處理機制。

5.網(wǎng)絡不穩(wěn)定：移動端最大的特點就是網(wǎng)絡不穩(wěn)定，在不穩(wěn)定的網(wǎng)絡狀態(tài)下，如何保證消息以最快的速度到達？如何避免重聯(lián)風暴？這些既需要從整體架構考慮，也需要在移動端采取巧妙的策略加以避免。

這些難點寫下來只不過千把字，耗時三十幾分鐘，但是真正要解決這些難點卻要不知道花費多少日日夜夜，敲下多少行代碼。因此，對于那些在某一場景下需要溝通能力的產(chǎn)品——O2O，互聯(lián)網(wǎng)教育，互聯(lián)網(wǎng)醫(yī)療、游戲…建議這些創(chuàng)業(yè)者把精力和資源都放在自己的核心能力上，而溝通就放心的交給我們?nèi)萋?lián)云通訊IM吧——因為那些難點，我們都已經(jīng)完美的干掉了他們。

還不了解云通訊IM？那就在4月21日，來參加云通訊開發(fā)者俱樂部第二期線上公開課吧，主講人云通訊IM產(chǎn)品線總監(jiān)張靖宇，屆時會為開發(fā)者詳細講解云通訊IM，開發(fā)者也可互相探討自己在開發(fā)過程中遇到的其他問題。

?

轉載于:https://www.cnblogs.com/yuntongxun/p/4422401.html

總結

以上是生活随笔為你收集整理的细数移动IM开发中的那些坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。