在撰写本文的过程中，我借鉴了博客作者“鹿呦呦”的著作以及“即时消息技术剖析与实战”在线课程的相关内容，对此亦表示衷心的感谢。

1、系列文章引言

IM系统表面上看起来操作简便（没错，许多企业主认为开发一个类似QQ和微信的产品只需花费几万元...），但实际上它是由众多技术融合而成，涵盖了网络编程、移动开发、后端开发、高并发处理、高可用性、高安全性等多个技术领域。而且，由于不同平台使用不同的编程语言，要构建一个典型的IM产品技术体系并非易事。

对于初涉IM开发的学人而言，要在繁杂的IM技术术语与理念中探寻学习路径和所需资料，实乃一大挑战。若不幸遭遇了不适宜初学者的深奥文章，很可能会从入门阶段直接转为放弃——被无情地吓退，这无疑是一种极大的遗憾。

本系列文章力求从理论层面出发，用浅显易懂的方式对即时通讯（IM）领域的核心技术及热点问题进行阐述，旨在帮助你理顺那些看似杂乱无章的IM知识脉络，为你指明一条明确的技术学习路径。未来，或许你能够实现薪资翻倍，甚至有可能迎娶理想的伴侣，这一切都并非遥不可及！

友情提醒：本篇文章主要针对理论知识的讲解，篇幅相对较短，仅作简要介绍。若想全面、深入、细致地掌握即时通讯技术，建议从这篇《新手入门一篇就够：从零开始打造移动端IM》（一部史诗级著作，适合初学者至放弃者）开始学习。

2、系列文章目录

《IM开发快速入门(一)：什么是IM系统？》（* 本文）

《IM开发快速入门第二部分：探讨IM系统的实时性特点（敬请期待发布）》

《IM开发入门指南系列（第三部分）：探讨IM系统稳定性的内涵（敬请期待发布）》

《IM开发入门系列第四篇：探讨IM系统的一致性（敬请期待发布）》

《IM开发入门系列之五：探讨IM系统安全性的重要议题（敬请期待后续发布）》

《IM开发入门指南系列之六：揭秘IM系统中的关键心跳机制，敬请期待后续发布》

《IM开发入门指南系列之七：深入解析与构建即时通讯系统中的未读消息计数功能（敬请期待发布）》

《IM开发入门指南（第八部分）：深入解析与实施跨平台即时通讯系统的消息同步功能，敬请期待后续发布》

3、本文内容概述

本文旨在迅速向您展示主流即时通讯系统的应用领域、典型结构、技术亮点以及功能模块，助您迅速形成对该类系统的初步认识。

若您对IM原理的技术层面不感兴趣，不妨阅读以下文章：《深入浅出：IM即时通讯软件如何将信息传递给接收者？（非技术视角）》。

本篇文章已被纳入即时通讯领域的基础教程《新手入门一篇即足：移动端即时通讯从零开始》。

本文已同步发布于“即时通讯技术圈”公众号。

4、IM的应用场景

即时通讯（IM）并非仅限于聊天、社交等所谓的“传统”应用范畴，实际上，它已被广泛应用于我们日常接触到的各式各样软件之中。

各类场景如对话交流、视频直播、网络客服以及物联网等，均需借助即时通讯技术来实现高效的实时互动。

下面这些场景是我们大家都熟悉的，都用到了IM技术：

微信、QQ、钉钉等作为主流的即时通讯工具：它们是即时通讯技术应用的典范场景。

微博、知乎等社交平台，通过即时通讯技术，为用户提供了私信功能，实现了点对点的私密交流。

抖音、快手等直播及短视频平台，通过即时通讯技术，实现了与主播之间的即时交流。

米家等智能家居物联网应用，通过即时通讯技术，实现了对设备的实时操控以及远程的监控功能。

滴滴、Uber等共享出行服务应用：通过即时通讯技术，实现用户间的位置信息共享。

6）在线教育类应用：利用IM技术实现在线白板。

5、IM的典型架构

一个典型的IM架构类似于下图这样：

本图摘自《即时消息技术剖析与实战》学习笔记的第一部分——关于即时通讯系统架构的探讨。

如上图所示，IM架构中的各分层职责如下：

1）客户端：作为与服务端进行消息收发通信的终端；

2）接入层：也叫网关层，为客户端收发消息提供入口；

3）逻辑层：负责IM系统各功能的核心逻辑实现；

存储层承担着IM系统相关数据的长期保存任务，这涵盖了消息的具体内容、用户的账户资料以及社交网络中的关联链条等。

第三方服务确保即便APP处于未开启或后台运行状态，用户依然能够接收到消息提醒（这主要得益于第三方消息推送服务）。

尤其对于“接入层”，它的职责最为关键，具体是：

1）保持海量用户连接；

2）解析协议，对传输内容进行编解码；

3）维护客户端的连接（也叫“”）；

4）推送消息。

以下文章适合IM架构设计入门，有兴趣可以读一读：

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》

《探讨马蜂窝旅游网如何从游击队模式过渡至正规军阶段：一窥其IM系统架构的发展历程》

6、IM技术的特点

M技术的特点主要就是以下4点：

1）实时性：

IM系统之核心在于“实时”二字，这正是其技术价值所在的关键。这一特性确保了信息的即时传递。

举例来说，若是在微信或QQ上与朋友交流，若我发送的信息对方无法立刻获取，亦或对方的信息你无法预知何时能接收到，那么这样的对话基本上就无法继续进行下去（为何不直接拨个电话呢？）。

2）可靠性：

确保信息的完整性与唯一性，成为即时通讯系统的一项核心技术优势。设想一下，当你通过QQ或微信与心爱的人交谈，鼓足勇气向对方表达心意，若是信息出现丢失，恐怕你会选择卸载应用，甚至可能情绪激动到损坏手机。当然，好言无需多提，信息的重复发送同样令人感到不悦。

本篇文章对信息传递中避免遗漏与重复的问题进行了详尽的剖析，若对此感兴趣，不妨仔细阅读。

《探讨即时通讯消息确保投递的有效策略（上篇）：确保网络中实时信息的稳定传递》

《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》

《IM群聊消息如此复杂，如何保证不丢不重？》

3）一致性：

在处理单聊信息时，确保同一设备上的时间顺序准确无误，以及实现不同设备间的漫游数据同步，这一点同样至关重要。

在IM系统中，消息的交流本质上就是人与人之间的对话。若出现前言不接后语或胡言乱语的状况，那么要么是参与者失去了理智，要么是程序出现了故障。总之，这种情况已经使得对话无法继续进行。

以下文章对消息时序问题进行了深入探讨，有兴趣可以详读：

《如何保证IM实时消息的“时序性”与“一致性”？》

《一个低成本确保IM消息时序的方法探讨》

4）安全性：

确保数据传输、存储及消息内容的安全性，对于即时通讯系统而言，乃是其不可或缺的功能。特别是在私密对话的场合，若无法实现安全防护，那么交流的体验将如同暴露在他人监视之下。

以下文章对IM的安全问题进行了深入探讨，有兴趣可以详读：

《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》

《第七篇：即时通讯安全探讨——JWT技术在处理IM系统长时间连接身份验证难题中的应用》

《通俗易懂：一篇掌握即时通讯的消息传输安全原理》

7、IM的功能组成

浅显的角度讲，一个典型的IM功能组成，无非就是以下5样：

1）联系人列表；

2）聊天界面；

3）消息发送通道；

4）消息接收通道；

5）消息存储；

6）消息未读数。

我们一样一样来说说各自的用途。

1）联系人列表：

这道理并不难懂，在使用IM系统时，首要任务便是确定“与何人交流”这一环节。从表面功能来看，联系人清单实质上反映了社交网络结构，它不过是一个展示信息的界面，那么，这其中又有哪些特别之处呢？

联系人名单表面上看颇为朴素，然而实质上，它却是对一系列即时通讯平台中社交联系建立行为的真实反映。

要想建立联系人列表，你可能需要实现以下逻辑：

如何寻找到心仪的交谈对象？（是采用随机匹配的方式，还是追求精确的搜索结果？）

如何判断是否与该人士展开对话？（需实现对其个人资料的查阅功能）

3）开始发出好友请求；

被请求的当事人有权自主选择接受或拒绝，至于接受后的具体操作以及拒绝后的应对措施，则需要根据实际情况另行决定。

总的来说，构建联系人名单，这一行为是即时通讯系统内建立聊天互动的显著标志，其重要性不言而喻。

2）聊天界面：

聊天窗口表面看似普通，实则它是即时通讯系统客户端的核心所在，所有关键的IM功能均由此呈现。

它应该具备的能力有：

多样化的交流工具：包括语音留言、图片分享、文字输入、表情符号、文件传输、实时通话以及实时视频等多种功能。

各类聊天内容表明，不同信息类型均具备独特的用户界面展示方式和处理规则。

3）流畅的使用体验：大量不同类型的消息显示时，不能卡顿；

即时呈现对话内容：一旦网络线程接收到信息，应立即在用户界面中呈现；

5）历史消息的加载：上次聊过的内容也得显示出来吧。

这仅仅是基础性的列举，然而看似简单的对话界面，若要妥善完成上述清单中的任务，所需要投入的劳动量其实颇为可观。

3）消息发送通道：

下图是一个典型的IM消息收发通道示意：

如上图所示，对于消息发送通道这一概念，理解起来相当直观。最直观的解释便是采用TCP或UDP协议，搭建起一个持久的连接，当需要发送信息时，只需轻松一传，操作极为简便！

但，事情往往不是想象的这么简单：

1）如何保证这条长连接时一直处于可用的状态？

2）当长连接不可用时，用户此时发送的消息该怎么处理？

3）怎么保证发送的消息不丢？

4）怎么保证发送的消息不复重？

5）怎么保证发送的消息乱序？

6）当对方不在线时，发送的消息去哪了？

7）发送的消息，能保证实时送到？

这么一说，事情还挺多（那不废话吗。。。）。

4）消息接收通道：

正如前文所展示的消息传递路径图解，我们可以轻松理解消息接收的过程，即对方通过消息发送路径发送的信息，我需要接收并展示出来。

要实现一个可靠的消息接收通道，也并非易事：

如何确保长连接始终维持在良好的连接状态，以便能够随时接收对方的信息。

2）当长连接断开时，对方发送消息该怎么实现？

3）当恢复连接时，怎么恢复之前的聊天现场？

4）当我收到对方的消息时，对方怎么知道我已经收到了？

5）当重复收到对方的消息时，该怎么处理？

6）当收到的消息时序有错乱，该怎么处理？

5）消息存储：

消息存储这一功能易于理解，若聊天记录得以保存，那么在下次对话时便无法追溯之前的交流内容；若无法实现这一功能，那么该即时通讯软件的聊天体验将大打折扣。

那么，哪些情况下需要进行消息存储呢：

1）对方不在线时：聊天消息应该存储（这叫离线消息存储）；

2）对方在线时：聊天消息也要存到本地存储（这叫消息缓存）；

无论对方是否处于在线状态，发送的聊天信息均需保存在服务器上，以确保消息能够在多台设备间实现漫游与同步。

具体要存储的内容和时机也就上面这几样。

但技术落到实处，要做的事情同样少不了：

1）离线消息该怎么多久？

这类离线信息，如图片、短视频以及大文件，我们应如何妥善保存？尤其是当这些文件容量可能相当可观时。

3）当本地的消息积累太多时，怎么能保证本地存储的性能？

在应用进行更新、升级或者出现异常情况时，我们如何确保本地存储数据保持完整，防止其遭到破坏呢？

5）怎么能保证多设备消息能不丢、不重、不乱？

这么多需要考虑的内容，也挺让人抓狂。

下图是一个IM系统的典型存储架构设计，了解一下：

本图内容摘自《现代即时通讯系统中关于聊天信息的同步与保存策略的研究》一文。

存储是IM系统的基石，以下文章可以深入阅读：

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《现代IM系统中聊天消息的同步和存储方案探讨》

《揭秘社交软件红包技术（第六篇）：探讨微信红包系统在存储层架构方面的演变与实际操作》

6）消息未读数：

这未读消息的提示，不外乎是各类即时通讯软件中普遍存在的那个小红点标志。直观上，它似乎非常简单！

然而，消息未读数功能的实现也一样不简单：

1）未读数是客户端实现还是服务端实现？

2）会话未读和总未读怎么保持一致？

在多设备环境下，如何确保未读信息的同步性（例如，我在这台设备上是否已阅读，其他设备又是如何得知这一信息的呢）？

确实，这看似仅仅是三个简单的步骤，然而一旦深入探究，却发现其实并不那么容易。

8、本文小结

IM系统的应用领域早已超越了单纯的即时通讯聊天工具，它已经深入到互联网应用的各个角落。毕竟，每个开发者都希望自己的产品能够拥有“实时互动”这一强大功能，因为这样的体验实在太过出色。

IM系统的典型结构主要包括网络接入部分、业务处理核心以及数据存储区域，除去网络接入部分，其余层次与一般的应用系统在外观上并没有显著的不同。

就IM系统的技术特性而言，主要包括实时性、可靠性、一致性和安全性等方面。其中，实时性虽然对于多数应用并非关键考量，但其他几个指标则相对容易理解。

在IM系统的功能模块中，联系人列表承担着构建数据模型的角色，聊天界面则负责呈现系统的终端界面，消息的收发通道确保了“实时性”的实现，而存储与未读数的功能虽然看似非必需，但在用户体验方面却至关重要。