即时通讯的架构选择
既然大家都需要一个用户之间/用户与客服之间的简单即时通信（IM）能力，那么如何获得一个这样的能力成为不少成长型公司的巨大的问题。如果将这样的能力接入其他公司的成熟系统，当然市场上的产品完全能够满足要求，但是无可避免的需要付出部分代价：IM服务的提供方将会完全掌握你们之间的通信信息，这个无论对方如何承诺安全性和专业性都是无法避免的（后续有机会专门讲述一下安全性问题）。
本篇的核心就在介绍IM通信系统最核心、最简单的功能和架构。
首先简述本文认为的IM通信的最基础的两大功能：
（1）确保发送端能够完成信息发送
（2）确保接收者能够即时准确地接收到信息
接下来就是IM系统的实现方式：
整体的设计思路：
（1）中心化读扩散的模式
（2）去中心化写扩散的模式
两种模式区别实际上相当明显：
（1）中心化读扩散的模式，很难实现异地多活的场景，对于远离中心的“域外”支持力有限，超长距离通信非常不方便
（2）去中心化写扩散的模式，难以支持多端同步，写扩散造成的存储成本使得服务端存储变得不太现实，跨区域获取数据场景处理非常麻烦
了解了这些你可能就明白了某些主要用作IM的软件一些奇奇怪怪的规则，比如某些软件为什么只能单端登录。
消息发送成功之后并不是万事大吉了，IM系统仍然需要确保消息触达到用户。
仍然拿上述的某信/某Q为例，简述IM系统推送信息的两种模式，主要的方式是：
（1）当用户在线的时候，服务端主动推送消息，也就是推的模式（push）
（2）当用户不在线的时候，服务器暂存消息，用户断线重连之后，客户端主动拉的模式（pull）
当前的主流IM软件当前都是使用的push/pull相结合的消息获取方式，某信和某Q和不能例外，其中要说差别，我只能说某信的用户在线时间明显高于某Q，也就是一个用推的场景更多一些，而另一个使用拉的场景更多。
再进一步阐述之前，这里要引入一个长连接的概念，而上文所提到的用户在线状态更多的指的并不是用户是否连接上了网络，也不是用户是否打开了特定的软件，而是指的用户是否连接了特定的长链接服务。
先上定义：长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。其好处是显而易见的：节约了多次TCP的握手分手的一系列动作，减少频繁的通信会造成socket错误。
对于IM系统而言长连接有一些特殊的意义和作用：
（1）建立的长连接通道，方便了服务端主动向下推送消息
（2）建立长连接的过程中可以方便的获得设备的信息和设备的连接状态
IM的客户端和长连接之间的互动流程包括：
（1）客户端登陆，尝试连接长连接服务端
（2）长连接服务响应，双方连接成功
（3）客户端注册客户端相关信息（ip，版本，用户信息等等），长连接校验信息，成功后客户端在长连接中注册完毕
（4）客户端主动获取断线过程中丢失的信息
（5）长连接处理多个客户端之间的通信信息
至此，消息发送/接收这两个IM最核心的流程，以及客户端、长连接、服务端这三个IM最重要的三个部分之间关系全部介绍完毕，这个IM的大框架也就基本介绍完成，后续的细节就不在本篇中赘述了。