本文在編寫時參考了博客做者「鹿呦呦」和在線課程「即時消息技術剖析與實戰」的相關資料，一併表示感謝。html

一、系列文章引言

IM系統看似簡單（沒錯，不少土老闆認爲開發個qq和微信也就是幾萬塊錢的事... ），實責是衆多技術的應用合體，包括網絡編程、移動開發、後端開發、高併發、高可用、高安全等技術範疇，再加上多端使用不一樣的編程語言，想要湊齊一個典型的IM產品技術棧那也不是個容易事。編程

而對於IM開發入門者來講，想要在衆多的IM技術術語和概念中找到學習的方向和須要的資料，那也是件很讓人抓狂的事。若是看到不應看的技術深水區文章，直接從入門到放棄——被活活嚇退，那也是至關悲劇的。後端

本系列文章將盡可能從理論概念入手，通俗易懂的梳理IM中的基礎技術概念和熱門技術點，但願能幫你理清看似一團亂麻的IM知識體系，助你找到清晰的IM技術學習方向，來日工資翻倍、迎娶白富美也未必不可能！緩存

二、本文內容概述

本文將帶你快速瞭解一個主流IM系統的應用場景、典型架構、技術特色和功能組成，幫你快速創建對IM系統的主觀認知。安全

若是你不想從技術的角度理解IM原理，能夠嘗試閱讀此文：《知識科普：IM聊天應用是如何將消息發送給對方的？（非技術篇）》。微信

本文已同步發佈於「即時通信技術圈」公衆號。網絡

三、IM的應用場景

IM其實並不侷限於聊天、社交這類「典型」應用中，實際上它已經普遍運用於咱們身邊形形色色的軟件中。架構

聊天、直播、在線客服、物聯網等全部須要實時互動、高實時性的場景等等，都須要應用到 IM 技術。併發

下面這些場景是咱們你們都熟悉的，都用到了IM技術：socket

1）微信、qq、釘釘等主流IM應用：這是IM技術的典型應用場景；
2）微博、知乎等社區應用：它們利用IM技術實現了用戶私信等點對點聊天；
3）抖音、快手等直播/短視頻應用：它們利用IM技術實現了與主播的實時互動；
4）米家等智能家居物聯網應用：利用IM技術實現實時控制、遠程監控等；
5）滴滴、Uber等共享家通類應用：利用IM技術實現位置共享；
6）在線教育類應用：利用IM技術實如今線白板。

四、IM的典型架構

一個典型的IM架構相似於下圖這樣：

（本圖引用自《即時消息技術剖析與實戰》學習筆記1——IM系統的架構》一文）

如上圖所示，IM架構中的各分層職責以下：

1）客戶端：做爲與服務端進行消息收發通訊的終端；
2）接入層：也叫網關層，爲客戶端收發消息提供入口；
3）邏輯層：負責IM系統各功能的核心邏輯實現；
4）存儲層：負責IM系統相關數據的持久化存儲，包括消息內容、帳號信息、社交關係鏈等；
5）第三方服務：保證APP在未打開或後臺運行時也能收到消息通知（這主要是第第3方消息推送服務）。

尤爲對於「接入層」，它的職責最爲關鍵，具體是：

1）保持海量用戶鏈接；
2）解析協議，對傳輸內容進行編解碼；
3）維護客戶端的鏈接（也叫「Session」）；
4）推送消息。

五、IM技術的特色

IM技術的特色主要就是如下4點：

▶ 1）實時性：

對於IM系統，「實時」二字是精髓，也是這項技術存在關鍵意義所在。它保證的是消息的實時觸達。

舉個例子：若是跟你的好友微信或qq聊天，我發的消息他不能即時收到，或者他發的信息你也不知道何時能收到，這基本上也就無法聊下去了（幹嘛不痛快打個電話呢）。

▶ 2）可靠性：

保證消息的不丟失和不重複，是IM系統的另外一個關鍵技術特色。試想，當你在用qq或微信跟女友聊天，好不容易鼓起勇氣向「她」表白，結果這消息要是丟包了，那確定得卸載應用了，搞很差砸手機都有可能。固然，好話不說二遍，消息重複也一樣惱人。

如下文章對消息的不丟/不重問題進行了深刻探討，有興趣能夠詳讀：

▶ 3）一致性：

對於單聊消息而言，保證同一個設備的時間順序、不一樣設備的漫遊同步，也是至關重要的一環。

IM系統中的消息交互，就到底就是人跟人在「說話」，前言不搭理後言、或者胡言亂語式的消息展示，那不是人瘋了就是程序瘋了，總之就是無法再聊下去了。

如下文章對消息時序問題進行了深刻探討，有興趣能夠詳讀：

▶ 4）安全性：

保證數據傳輸安全、數據存儲安全、消息內容安全，也是IM系統必不可少的特性。尤爲在私聊場景下，若是不能作到安全性，聊天的體驗跟被人偷窺的感受是沒有區別的。

六、IM的功能組成

淺顯的角度講，一個典型的IM功能組成，無非就是如下5樣：

1）聯繫人列表；
2）聊天界面；
3）消息發送通道；
4）消息接收通道；
5）消息存儲；
6）消息未讀數。

咱們同樣同樣來講說各自的用途。

▶ 1）聯繫人列表：

這個很好理解，使用IM系統的第一步，就是要解決「跟誰聊」的問題。從功能表象上來講，聯繫人列表也就是社交關係列表，無非就是個信息列表界面，有什麼特殊的地方？

聯繫人列表看似簡單，實際上它是一系列IM系統的社交關係確立動做的結果體現。

要想創建聯繫人列表，你可能須要實現如下邏輯：

1）怎麼能找到想要聊天的人？（須要實現隨機查找？精確查找？）
2）怎麼決定要不要跟這我的聊？（須要實現對方的我的信息查看）
3）開始發出好友請求；
4）被請求的一方，還能夠決定是「贊成」仍是「拒絕」（「贊成」該怎麼處理？「拒絕」又該怎麼處理？）。

總的來講，聯繫人列表的創建，是一個IM系統聊天關係確立的表現，不可或缺。

▶ 2）聊天界面：

聊天界面看似很日常，實際它就是IM系統客戶端的核心功能所在，全部主要的IM功能都是經過它展示。

它應該具有的能力有：

1）各類聊天功能按鈕：語音留言、圖片、文字、表情、文件、實時電話、實時視頻等；
2）各類聊天消息顯示：各類消息都有不一樣的UI顯示元素和處理邏輯；
3）流暢的使用體驗：大量不一樣類型的消息顯示時，不能卡頓；
4）即時顯示聊天消息：網絡線程收到的消息，要立刻在UI上顯示出來；
5）歷史消息的加載：上次聊過的內容也得顯示出來吧。

以上只是簡單羅列，這看似簡單的聊天界面，能把上面列表的事情作好，工做量也不小吧。

▶ 3）消息發送通道：

下圖是一個典型的IM消息收發通道示意：

如上圖所示，消息發送通道這個比較好懂，最淺顯易懂的理解就是用tcp或udp，創建socket長鏈接，須要發消息的時候，wirte一下就過去了，好簡單！

但，事情每每不是想象的這麼簡單：

1）如何保證這條socket長鏈接時一直處於可用的狀態？
2）當socket長鏈接不可用時，用戶此時發送的消息該怎麼處理？
3）怎麼保證發送的消息不丟？
4）怎麼保證發送的消息不復重？
5）怎麼保證發送的消息亂序？
6）當對方不在線時，發送的消息去哪了？
7）發送的消息，能保證明時送到？

這麼一說，事情還挺多（那不廢話嗎。。。）。

▶ 4）消息接收通道：

正如上節中的消息收發通道示意圖所示，消息接收通道也很好理解，對方經過消息發送通道write的消息，我得收到並顯示啊。

要實現一個可靠的消息接收通道，也並不是易事：

1）如何保證socket長鏈接通道能隨時處於良好的邊接狀態（隨時接收對方write的消息）；
2）當socket長鏈接斷開時，對方發送消息該怎麼實現？
3）當socket恢復鏈接時，怎麼恢復以前的聊天現場？
4）當我收到對方的消息時，對方怎麼知道我已經收到了？
5）當重複收到對方的消息時，該怎麼處理？
6）當收到的消息時序有錯亂，該怎麼處理？

▶ 5）消息存儲：

消息存儲這個功能好理解，聊天的消息若是存儲，下次再聊的時候就不知道以前聊過什麼，作不到這一點，這個IM系統的聊天體驗好不起來。

那麼，哪些狀況下須要進行消息存儲呢：

1）對方不在線時：聊天消息應該存儲（這叫離線消息存儲）；
2）對方在線時：聊天消息也要存到本地存儲（這叫消息緩存）；
3）對方在線或不在線時：聊天消息都要存到服務端（用於實現多設備的消息漫遊和同步）。

具體要存儲的內容和時機也就上面這幾樣。

但技術落到實處，要作的事情一樣少不了：

1）離線消息該怎麼多久？
2）圖片、短視頻、大文件這類的離線消息，多媒體文件該怎麼存（有可能量會很大）？
3）當本地的消息積累太多時，怎麼能保證本地存儲的性能？
4）當應用更新、升級或異常時，怎麼能保證本地存儲的完整性（不被破壞）？
5）怎麼能保證多設備消息能不丟、不重、不亂？

這麼多須要考慮的內容，也挺讓人抓狂。

下圖是一個IM系統的典型存儲架構設計，瞭解一下：

（本圖引用自《現代IM系統中聊天消息的同步和存儲方案探討》一文）

▶ 6）消息未讀數：

消息未讀數？看起來也就是那個全部IM應用都有的未讀小紅點嘛。是的，看起來也好簡單！

然而，消息未讀數功能的實現也同樣不簡單：

1）未讀數是客戶端實現仍是服務端實現？
2）會話未讀和總未讀怎麼保持一致？
3）多終端狀況下，怎麼保證未讀數的一致性（我在這臺設備上讀沒讀，那臺設備怎麼知道的？）？

是的，看起來就這麼簡簡單單的3件事，但深刻思考一下，還真的簡單不起來。

七、本文小結

IM系統的應用場景已經不僅僅是IM聊天應用這一種形態，它已經融入到互聯網應用的方方面面，必竟誰都想自已的應用具有「實時」交互這種能力，由於體驗太好了。

IM系統典型架構無非就是網絡接入層、業務邏輯層、數據存儲層，除開網絡接入層，其它各層其實跟普通的應用系統看起來差異並非太大。

IM系統的技術特色來講，就是實時性、可靠性、一致性、安全性，除了實時性對於多數應用來講並不關心，其它的指標也很好理解。

IM系統的功能組成上，聯繫人列表用於數據模型的創建、聊天界面承載了IM系統的終端展示、消息的收發通道用於實現「實時」這個特性、存儲和未讀數看似不是必須但用戶體驗上確必不可少。（本文同步發佈於：http://www.52im.net/thread-3065-1-1.html）