IM系统的简单介绍

作为一个互联网时代的公司无论你的产品是什么，你都需要一个网站还是app亦或是一个pc软件作为自己的网络平台，而在网络平台当中，即时收集用户反馈、与用户进行互动、方便用户之间互动提高产品活跃度只要存在这些需求，那么你的产品都需要IM（即时通信）的能力。
既然大家都需要一个用户之间/用户与客服之间的简单即时通信（IM）能力，那么如何获得一个这样的能力成为不少成长型公司的巨大的问题。如果将这样的能力接入其他公司的成熟系统，当然市场上的产品完全能够满足要求，但是无可避免的需要付出部分代价：IM服务的提供方将会完全掌握你们之间的通信信息，这个无论对方如何承诺安全性和专业性都是无法避免的（后续有机会专门讲述一下安全性问题）。
本篇的核心就在介绍IM通信系统最核心、最简单的功能和架构。
首先简述本文认为的IM通信的最基础的两大功能：
（1）确保发送端能够完成信息发送
（2）确保接收者能够即时准确地接收到信息
也就是消息推送的及时性和可靠性，其次则为设备漫游、多端同步以及安全性问题。（这里吐槽一句在深入了解了某信之后我发现：对于大的业务方有些问题可能都不需要解决）
接下来就是IM系统的实现方式：
这里引入在中国市场中最大的两个即时通信app是某信和某Q，以他们为例进行介绍，虽然两者都是某讯公司的产品，但实际上从设计理念/模型上便有着根本上的差异。
某Q是一种相对较为经典的IM工具，其最为古老的版本是1999年便出现的OICQ。作为一个上一个世纪便产生的互联网行业的老古董，其不可避免经历过多次的大改以修复某些原始设计上的缺陷，确保产品体验和服务性能。但这么多次修改其设计的基本理念并没有大改，用户发送消息实际上是在向中心服务器写入信息，消息写入之后，接收端同样是通过中心服务器来获得消息内容，总体上是一种数据中心化存储+读扩散的模式。
与之相对应的是2011年才面向市场某信，虽然诞生至今不过十年，但已经成为了消息量最大的社交软件。微信的设计理念来自于短信/电子邮箱模式，用户发送消息实际上是在编辑一条短信/邮件，通过某信的服务再将内容投递出去，这中间可能存在多次转发，但最终的投递地点/终端是固定的，这种设计思路在IM中相对少见，总体上是一种分散存储+写扩散的模式。
整体的设计思路：

（1）中心化读扩散的模式

（2）去中心化写扩散的模式
PS：上述只是一个模式差异的简略图，实际的结构复杂度将远远超过这张简图

两种模式区别实际上相当明显：
（1）中心化读扩散的模式，很难实现异地多活的场景，对于远离中心的“域外”支持力有限，超长距离通信非常不方便
（2）去中心化写扩散的模式，难以支持多端同步，写扩散造成的存储成本使得服务端存储变得不太现实，跨区域获取数据场景处理非常麻烦
了解了这些你可能就明白了某些主要用作IM的软件一些奇奇怪怪的规则，比如某些软件为什么只能单端登录。
消息发送成功之后并不是万事大吉了，IM系统仍然需要确保消息触达到用户。
仍然拿上述的某信/某Q为例，简述IM系统推送信息的两种模式，主要的方式是：
（1）当用户在线的时候，服务端主动推送消息，也就是推的模式（push）
（2）当用户不在线的时候，服务器暂存消息，用户断线重连之后，客户端主动拉的模式（pull）
当前的主流IM软件当前都是使用的push/pull相结合的消息获取方式，某信和某Q和不能例外，其中要说差别，我只能说某信的用户在线时间明显高于某Q，也就是一个用推的场景更多一些，而另一个使用拉的场景更多。
再进一步阐述之前，这里要引入一个长连接的概念，而上文所提到的用户在线状态更多的指的并不是用户是否连接上了网络，也不是用户是否打开了特定的软件，而是指的用户是否连接了特定的长链接服务。
先上定义：长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。其好处是显而易见的：节约了多次TCP的握手分手的一系列动作，减少频繁的通信会造成socket错误。
常见的长连接方案包括：comet、WebSocket等。
对于IM系统而言长连接有一些特殊的意义和作用：
（1）建立的长连接通道，方便了服务端主动向下推送消息
（2）建立长连接的过程中可以方便的获得设备的信息和设备的连接状态
IM的客户端和长连接之间的互动流程包括：
（1）客户端登陆，尝试连接长连接服务端
（2）长连接服务响应，双方连接成功
（3）客户端注册客户端相关信息（ip，版本，用户信息等等），长连接校验信息，成功后客户端在长连接中注册完毕
（4）客户端主动获取断线过程中丢失的信息
（5）长连接处理多个客户端之间的通信信息
大体的流程图：