做了一段时间的即时通讯IM应用，有些心得，特来分享分享。
IM，又称为即时通讯。既然是即时，那就需要和客户端建立一个长连接。
对于长连接需要有连接保活心跳机制而长连服务器的IP地址又需要进行下发等。
总体划分如下:
- 服务器地址下发
- 网关层
- API层
- 服务层
- 队列机层
用户客户端打开应用之后，将会向服务器发起一个HTTPS请求，服务端根据长连服务器负载情况将要下发的地址进行排序，客户端根据获取到的长连服务器地址顺序尝试连接，成功建立连接之后开始进行通信。
每一条上行及下行的消息都需要与网关层进行交互，在连接期间，需要与网关层进行心跳检测链路问题，消息经过encode处理之后发送到网关层，网关层直接调用API层的RPC透传到API层去处理。
API层收到来自网关层的RPC请求之后，先进行decode,然后解析出相应的header、body，根据header中定义的tag和type去调用相应的方法。这些方法除了业务逻辑外，另外就是通过RPC或者HTTP去调用各种所需的服务，如：用户服务、私信服务、群聊服务。
服务层收到API层的请求之后，生成消息版本号，将消息入库，并将消息异步写入队列之中，返回处理结果给API层。
队列机这一层负责接收、处理及转发多种服务写入的消息，然后将处理后的消息pub到Redis中，包括离线缓存队列，由长连服务器去sub，然后下推给客户端。
需要解决的问题- 消息乱序问题
- 消息可靠性问题