IM开发快速入门(一)：什么是IM系统？

本文在编写时参考了博客作者“鹿呦呦”和在线课程“即时消息技术剖析与实战”的相关资料，一并表示感谢。

1、系列文章引言

IM系统看似简单（没错，很多土老板认为开发个qq和微信也就是几万块钱的事... ），实责是众多技术的应用合体，包括网络编程、移动开发、后端开发、高并发、高可用、高安全等技术范畴，再加上多端使用不同的编程语言，想要凑齐一个典型的IM产品技术栈那也不是个容易事。

而对于IM开发入门者来说，想要在众多的IM技术术语和概念中找到学习的方向和需要的资料，那也是件很让人抓狂的事。如果看到不该看的技术深水区文章，直接从入门到放弃——被活活吓退，那也是相当悲剧的。

本系列文章将尽量从理论概念入手，通俗易懂的梳理IM中的基础技术概念和热门技术点，希望能帮你理清看似一团乱麻的IM知识体系，助你找到清晰的IM技术学习方向，来日工资翻倍、迎娶白富美也未必不可能！

友情提示：本系列文章侧重于理论概念的讲述，篇幅有限，点到即止，如需系统、深入、具体地学习IM技术的方方面面，请从此文入手：《新手入门一篇就够：从零开发移动端IM》（史诗级文章，适合从入门到放弃）。

学习交流：

- 即时通讯/推送技术开发交流5群：215477170[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

2、系列文章目录

《IM开发快速入门(一)：什么是IM系统？》（* 本文）
《IM开发快速入门(二)：什么是IM系统的实时性？ (稍后发布)》
《IM开发快速入门(三)：什么是IM系统的可靠性？ (稍后发布)》
《IM开发快速入门(四)：什么是IM系统的一致性？ (稍后发布)》
《IM开发快速入门(五)：什么是IM系统的安全性？ (稍后发布)》
《IM开发快速入门(六)：什么是IM系统的的心跳机制？ (稍后发布)》
《IM开发快速入门(七)：如何理解并实现IM系统消息未读数？ (稍后发布)》
《IM开发快速入门(八)：如何理解并实现IM系统的多端消息漫游？ (稍后发布)》

3、本文内容概述

本文将带你快速了解一个主流IM系统的应用场景、典型架构、技术特点和功能组成，帮你快速建立对IM系统的主观认知。

如果你不想从技术的角度理解IM原理，可以尝试阅读此文：《知识科普：IM聊天应用是如何将消息发送给对方的？（非技术篇）》。

本文已收入即时通讯网的入门纲领性文章《新手入门一篇就够：从零开发移动端IM》。

本文已同步发布于“即时通讯技术圈”公众号，欢迎关注：

▲ 本文在公众号上的链接是：https://mp.weixin.qq.com/s/h7L4UGHRl7qI1bi8WyZ5iw，原文链接是：http://www.52im.net/thread-3065-1-1.html

4、IM的应用场景

IM其实并不局限于聊天、社交这类“典型”应用中，实际上它已经广泛运用于我们身边形形色色的软件中。

聊天、直播、在线客服、物联网等所有需要实时互动、高实时性的场景等等，都需要应用到 IM 技术。

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

• 1）微信、qq、钉钉等主流IM应用：这是IM技术的典型应用场景；
• 2）微博、知乎等社区应用：它们利用IM技术实现了用户私信等点对点聊天；
• 3）抖音、快手等直播/短视频应用：它们利用IM技术实现了与主播的实时互动；
• 4）米家等智能家居物联网应用：利用IM技术实现实时控制、远程监控等；
• 5）滴滴、Uber等共享家通类应用：利用IM技术实现位置共享；
• 6）在线教育类应用：利用IM技术实现在线白板。 

5、IM的典型架构

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

（本图引用自《即时消息技术剖析与实战》学习笔记1——IM系统的架构》一文）

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

• 1）客户端：作为与服务端进行消息收发通信的终端；
• 2）接入层：也叫网关层，为客户端收发消息提供入口；
• 3）逻辑层：负责IM系统各功能的核心逻辑实现；
• 4）存储层：负责IM系统相关数据的持久化存储，包括消息内容、账号信息、社交关系链等；
• 5）第三方服务：保证APP在未打开或后台运行时也能收到消息通知（这主要是第第3方消息推送服务）。

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

• 1）保持海量用户连接；
• 2）解析协议，对传输内容进行编解码；
• 3）维护客户端的连接（也叫“Session”）；
• 4）推送消息。

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

• 《浅谈IM系统的架构设计》
• 《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
• 《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》

6、IM技术的特点

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

▶ 1）实时性：

对于IM系统，“实时”二字是精髓，也是这项技术存在关键意义所在。它保证的是消息的实时触达。

举个例子：如果跟你的好友微信或qq聊天，我发的消息他不能即时收到，或者他发的信息你也不知道什么时候能收到，这基本上也就没法聊下去了（干吗不痛快打个电话呢）。

▶ 2）可靠性：

保证消息的不丢失和不重复，是IM系统的另一个关键技术特点。试想，当你在用qq或微信跟女朋友聊天，好不容易鼓起勇气向“她”表白，结果这消息要是丢包了，那肯定得卸载应用了，搞不好砸手机都有可能。当然，好话不说二遍，消息重复也同样恼人。

以下文章对消息的不丢/不重问题进行了深入探讨，有兴趣可以详读：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《IM群聊消息如此复杂，如何保证不丢不重？》

▶ 3）一致性：

对于单聊消息而言，保证同一个设备的时间顺序、不同设备的漫游同步，也是相当重要的一环。

IM系统中的消息交互，就到底就是人跟人在“说话”，前言不搭理后言、或者胡言乱语式的消息展现，那不是人疯了就是程序疯了，总之就是没法再聊下去了。

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

• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《一个低成本确保IM消息时序的方法探讨》

▶ 4）安全性：

保证数据传输安全、数据存储安全、消息内容安全，也是IM系统必不可少的特性。尤其在私聊场景下，如果不能做到安全性，聊天的体验跟被人偷窥的感觉是没有区别的。

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

• 《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
• 《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》
• 《通俗易懂：一篇掌握即时通讯的消息传输安全原理》

7、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系统中聊天消息的同步和存储方案探讨》一文）

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

• 《微信后台基于时间序的海量数据冷热分级架构设计实践》
• 《现代IM系统中聊天消息的同步和存储方案探讨》
• 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》

▶ 6）消息未读数：

消息未读数？看起来也就是那个所有IM应用都有的未读小红点嘛。是的，看起来也好简单！

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

• 1）未读数是客户端实现还是服务端实现？
• 2）会话未读和总未读怎么保持一致？
• 3）多终端情况下，怎么保证未读数的一致性（我在这台设备上读没读，那台设备怎么知道的？）？

是的，看起来就这么简简单单的3件事，但深入思考一下，还真的简单不起来。

8、本文小结

IM系统的应用场景已经不单单是IM聊天应用这一种形态，它已经融入到互联网应用的方方面面，必竟谁都想自已的应用具备“实时”交互这种能力，因为体验太好了。

IM系统典型架构无非就是网络接入层、业务逻辑层、数据存储层，除开网络接入层，其它各层其实跟普通的应用系统看起来差别并不是太大。

IM系统的技术特点来说，就是实时性、可靠性、一致性、安全性，除了实时性对于多数应用来说并不关心，其它的指标也很好理解。

IM系统的功能组成上，联系人列表用于数据模型的建立、聊天界面承载了IM系统的终端展现、消息的收发通道用于实现“实时”这个特性、存储和未读数看似不是必须但用户体验上确必不可少。

附录：更多IM开发资料汇总

[1] 有关IM架构设计的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
>> 更多同类文章 ……
[2] IM开发热门综合文章：
《新手入门一篇就够：从零开发移动端IM》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《IM开发基础知识补课：正确理解前置HTTP SSO单点登录接口的原理》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登录和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《全面掌握移动端主流图片格式的特点、性能、调优等》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》
《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《IM要做手机扫码登录？先看看微信的扫码登录功能技术原理》
《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《IM开发快速入门(一)：什么是IM系统？》
>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-3065-1-1.html）