轉自：https://www.jianshu.com/p/38e127cb03ec

By 紫韻： 最近對 IM 系統產生了興趣，就看了些部落格，現希望通過一個系列的文章對其稍作總結與記錄，如有不對，還望指正。

IM 簡介

IM：Instant Messaging，即時通訊，是一個允許兩人或多人通過網路實時傳輸文字、語音、視訊等的終端服務，如現在常用的 QQ、微信、百度 Hi 等。IM 完全基於 TCP/IP 網路協議族實現，而 TCP/IP 協議族則是整個網際網路得以實現的技術基礎。

通訊方式

典型的 IM 通訊方式有如下四種：

• 線上直連通訊：即 P2P（Peer To Peer）對等通訊方式，也就是通訊雙方直接建立通訊連線進行點對點的通訊；
• 線上中轉通訊： 通訊雙方不是通過點對點直連方式進行通訊，而是通過一個服務端作為代理來進行通訊，即訊息傳送方將訊息傳送給伺服器，然後伺服器再將訊息轉發給訊息接收方；
• 離線中轉通訊：以上兩種方式都是基於通訊雙方均線上的前提之下，但是有時訊息接收方並不一定剛好線上。當訊息接收方處於離線狀態時，也需要採用服務端中轉方式進行訊息投遞。訊息傳送方現將訊息傳送到服務端，然後服務端轉儲訊息，待訊息接收方上線時再將訊息轉發給接收方；
• 擴充套件通訊：擴充套件通訊即呼叫其他通訊方式來完成通訊過程，如通過簡訊、Email、傳真等方式將訊息從傳送方投遞到接收方。

P2P && 伺服器中轉

P2P：
P2P 多見於區域網內聊天工具，典型的應用有：飛鴿傳書、天網 Maze 等。這類軟體在啟動後一般做兩件事情：
進行 UDP 廣播：傳送自己資訊和接受同區域網內其他端資訊；
開啟 TCP 監聽：等待其他端進行連線。

限制和不便：
只適合 ** 線上 ** 的 ** 點對點 ** 訊息傳輸，對離線、群組等業務支援不夠；
由於 NAT 的存在，使得不同區域網內機器互聯難度大大上升，在某些網路型別(對稱 NAT)下無法建立連線。

** 伺服器中轉 **
幾乎所有網際網路 IM 產品都採用伺服器中轉這種方式進行訊息傳輸，相比於 P2P 的方式，它的優劣如下：

• 優點：
  能夠支援更多P2P無法支援或支援不好的業務，如離線訊息，群組，聊天室服務；
  方便業務邏輯的拓展和新舊版本的相容。

• 缺點：伺服器架構複雜，併發要求高。

工作方式

** 典型的 IM 工作方式如下：**
客戶端登陸 IM 通訊中心（IM 通訊伺服器），獲取好友列表，獲取離線訊息，將自身標誌為線上狀態，與聊天物件建立聊天通道，進行文字、語音等通訊。

1. 使用者 A 通過使用者名稱和密碼登入 IM 伺服器，伺服器通過讀取資料庫中使用者資訊進行校驗，校驗通過後，登記使用者 A 的 ip 地址、IM 客戶端版本號、使用的 TCP/UDP 埠號等並標記使用者 A 的狀態為線上，返回使用者 A 登入成功標誌；
2. 使用者 A 獲取好有列表資訊（包括：線上狀態、IP 地址、TCP/UDP 埠號等）、離線訊息；
3. 伺服器將使用者 A 的線上相關資訊通知到其線上好友 ，包括：線上狀態、IP 地址、TCP/UDP 埠號等；
4. 接下來使用者 A 就可以通過直連/伺服器中轉方式與其它使用者進行訊息通訊了。

IM 系統選型

一個典型的 IM 系統的選型過程大致包含如下幾個部分：

• 服務方式：P2P or 伺服器中轉；
• 網路通訊協議：TCP or UDP；
• 資料通訊協議：XMPP、SIP、MQTT、Protobuf、私有協議；
• 協議加密：加密流程的設計、加密演算法的選擇；
• 伺服器：開源的 IM 伺服器，如 OpenFire，Tigase，Prosody，Mosquitto，ejabberd等、自己的伺服器。

** IM 系統架構分層：**

• ** 接入層（ENTRY）：** 作為客戶端和服務端的介面子系統，此層直接面對 PC 桌面客戶端、WEB 網頁客戶端、移動 APPS 客戶端的海量長連線請求，負責建立與客戶端通訊的加密通道，整合成內部少量有限的長連線，對通訊資料進行壓縮與解壓，並將相應請求轉發至邏輯層。除此之外，接入層實施初步的攻防策略，用來抵禦非邏輯層面的攻擊，監控某些資料（連線頻率、發包頻率、發包速率等），對 IP/UID 等指標實施封禁，IM 在某些緊急情況下，必須能夠迅速實施封禁，所以需要實時授權 IP/UID 等黑白名單，使得白名單動態生效、黑名單自動解封。
• ** 邏輯層（LOGIC）：** 邏輯子系統主要是負責整個 IM 系統的邏輯處理，包括使用者相關（使用者登入登出、使用者資訊設定查詢）、好友相關（新增好友、獲取好友、刪除好友、修改好友資訊等）、訊息相關（收發好友訊息、收發陌生人訊息、訊息確認、通用訊息處理、離線訊息等）等複雜邏輯處理。
• ** 路由層（ROUTER）：** 路由子系統主要處理和使用者一次登入 session 相關的資料（比如：使用者線上狀態[線上、離開、隱身]，登入IP等），這部分涉及的資料變化非常快，沒必要固化，直接儲存在記憶體中。並記錄使用者登入接入層的路由資訊，支援向指定 UIDS 通訊的功能。
• ** 資料層（DATA ACCESS）：** 統一資料訪問子系統遮蔽了底層的儲存引擎，上層無需關心實際的儲存是 RDBMS 或者 NoSQL 或者其他的 KV 儲存引擎，對上層提供友好、統一的訪問介面，封裝原子邏輯。並通過 CURD 介面的抽象封裝，增加新的資料操作只需要增加配置，不用變動資料層程式碼，較容易完成關鍵資料的儲存。
• ** 資料儲存層（DATA STORAGE）：** 資料儲存層是 IM 的固化儲存系統，根據業務資料特點決定使用何種持久化儲存方式（RDBMS（MySQL）、NoSQL（MongoDB）等），並通過分散式快取（Memcached、Redis等）加速查詢。

一個典型的 IM 系統可能由如下及部分組成：

• 客戶端：用於讓使用者接入系統；
• 註冊伺服器：使用者接入系統時使用，提供鑑權等相應處理；
• 連線伺服器：用於保持與所有使用者的連線，狀態訊息的通知以及客戶會話請求時通訊伺服器相關資訊的返回；
• 通訊伺服器：用於通訊渠道的建立以及離線資訊的儲存。包括離線檔案傳輸。根據實際情況可以考慮增加一臺檔案伺服器，供通訊伺服器使用；
• 資料庫伺服器：提供對於資料庫所有的操作介面。所有關於資料庫的操作均歸必須通過該臺位；
• 鑑權伺服器：可有可無，供註冊伺服器使用，主要用於鑑權。

IM 系統功能點/技術點分析

*** 功能點分析：***

• 註冊登入：註冊方式（手機、郵箱、暱稱）、登入驗證（註冊資訊、三方、手機動態驗證登入）等；
• 聊天：文字、語音、圖片、視訊、表情；單聊、群聊；
• 傳輸服務：文字傳輸、檔案傳輸；
• 好友 / 群組管理：新增、刪除、查詢好友 / 群；
• 多端服務：PC 端、Android 端、IOS 端等；
• 使用者資訊管理。

*** 技術點分析：***

• 登入優化：

  • 登入方式：註冊資訊、三方、手機驗證碼動態登入、無需登入等；
  • LBS 請求：非同步化，不在登入時進行 LBS 請求，而是在網路空閒和發生變化時進行請求並快取，每次登入則直接從本地快取獲取連線地址，以加快登入速度；
  • DNS 優化：移動端 DNS 解析時間長、準確率較低、容易被劫持，特別需要優化；優化策略：
    • 使用 HTTP DNS，如開源的 HttpDNSLib；
    • 儘可能避免 DNS 解析請求：如 LBS 直接返回待連線的伺服器的 IP 地址而非域名；本地快取 LBS IP 地址備用，請求 LBS 時優先使用 IP 而非域名；
  • 登入認證請求的優化；
  • 資料同步策略優化：使用者登入 IM 系統後，需要在主介面呈現使用者的好友列表、群組列表等資訊，主要包括：好友列表、好友詳情資訊、群組列表、群組詳情資訊、群成員列表、群成員詳情資訊等。如果所有資訊均在登入過程中進行同步的話，登入過程會耗時很長，並且流量消耗很大，從而導致使用者體驗很差，大致可以從如下幾個方面進行優化：
    • 按時間戳同步：客戶端只同步比本地快取新的資料；
    • 延遲載入和按需更新：初始頁面並不需要將所有資訊均提供給使用者，而是隻需要保證映入使用者眼簾的頁面資訊完全即可，這些資訊主要有：好友列表、群組列表、離線訊息記錄；而好友詳情資訊、群組詳情資訊、群成員列表和群成員詳情資訊等均可以在使用者進入相應的頁面再按需更新或等到網路空閒時再載入即可；

• 伺服器負載優化：多伺服器專職化，各司其職（專門用於登入、鑑權、狀態管理的伺服器；專門用於訊息通訊的伺服器等）；伺服器叢集；分流（如可考慮訊息直連通訊 P2P）；

• 訊息同步機制

• 訊息可靠性保證

• 訊息時序性和一致性

• 訊息推送機制

• 心跳保活機制

移動端 IM 技術難點

** 移動端 IM 客戶端難點 **

1. ** 流量：**移動端流量費較貴，所以省流量是移動端產品特別需要注意的效能指標。可以從網路通訊協議、資料通訊協議、圖片壓縮技術、附件壓縮技術等方面著手減少流量消耗；
2. ** 耗電量 ：**移動端的電量比較少，充電比較麻煩，需要注意電量消耗。一般來說，流量越小，耗電量越少；心跳次數越少，耗電量越少，不過這需要結合具體的業務場景來制定恰當的心跳策略；
3. ** 心跳時長：**WIFI、2G、3G、4G、移動、電信、聯通等不同網路、不同執行商下 NAT 失效時間是不一樣的，因此心跳的時間也應當區別對待；
4. ** 掉線重連機制** ；
5. ** 網路不穩定：**移動端最大的特點就是網路切換頻繁，從而導致網路不穩定，並且不同的網路環境下需要進行不同的處理（如 WIFI 網路和行動網路需要區別對待）。在不穩定的網路狀態下，如何保證訊息的到達率？如何保證訊息以最快的速度到達？如何避免重聯風暴？這些既需要從整體架構考慮，也需要在移動端採取巧妙的策略加以避免；
6. ** 檔案上傳優化 **。

** 移動端架構設計的難點 **

1. ** 聯結器的設計：**聯結器主要用來管理客戶端的長連線；
2. ** 中介軟體的設計：**是否採用通訊中介軟體？各種通訊中介軟體的優劣分析與選擇？如果不採用中介軟體，如何管理聯結器和邏輯伺服器的連線關係？
3. ** 邏輯伺服器：**邏輯伺服器通常簡單一點，主要是根據業務邏輯進行最小粒度的劃分即可；
4. ** 狀態伺服器：**狀態伺服器主要管理使用者線上、離線的相關狀態。狀態同步機制如何實現？狀態儲存機制，如何進行讀寫操作從而最大限度地提高狀態伺服器的處理能力和響應速度；
5. ** 資料庫的設計：**資料庫設計相對來說比較難，當業務增長時容易成為效能瓶頸。因為無論是 SQL 關係型資料庫，還是 NOSQL 非關係型資料庫均有讀寫處理上限。
6. ** 其他：**如推送機制、訊息的可靠投遞、訊息同步機制、訊息的時序性和一致性如何保證、線上訊息和離線訊息的區別對待等。這些都是必備而又非常複雜的功能技術點，都需要採取正確的架構和策略才能實現。

參考文章

• IM 即時通訊實現原理
• 簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端
• 談談移動端 IM 開發中登入請求的優化
• 移動端IM開發需要面對的技術問題
• 以IM為例看58同城典型技術架構演變

作者：LilacZiyun
連結：https://www.jianshu.com/p/38e127cb03ec
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。