简单聊聊对于IM架构的一些思考

什么是IM架构

简单来说就是通过定制一套特殊的基础框架，从而实现后台主动给客户端推送消息的效果。最常见的场景：用户聊天，消息主动通知。

下边的这些关于IM架构的思想，更多是我个人结合实际开发经验所总结的，可能会有所欠缺，希望对各位有所帮助。

如何实现主动通知

最常见的消息主动通知机制，就是采用webSocket服务器去建立连接，这一块可以采用Netty来实现WebSocket的服务端，客户端可以采用一些sock.js去访问Netty服务器。好了，那假设A用户要给B用户发送一条消息的话，请问该如何实现呢？来看下边这张图：

如上图所示，整体的发送消息流程为：

1. 客户端A给WebSocket-A服务器发送消息。
2. WebSocket-A服务器给RocketMQ的Broker发送A-topic消息
3. 业务系统订阅该消息，然后发送一个B-topic给Broker
4. WebSocket-B服务器订阅Broker的B-topic消息
5. WebSocket-B主动给客户端B发送消息

这种实现方式对于消费者而言，需要采用push模式，这种方式的实现原理是伪推方式，本质还是客户端在本地进行实时拉取。

通常我们的Netty服务器都会部署一个集群，保证其高可用状态。

如何增加业务操作

来看下边几种业务类型场景：

假设是付费聊天功能， 每次发送一条消息，都需要进行一些金额扣费的处理。

所以这种时候，我们可以通过在业务系统层订阅MQ的方式进行处理。

业务系统层订阅MQ后，当拿到了消息就可以开始做自己想做的业务操作了。但是在执行业务操作的过程中不宜做过重的处理，例如一些同步执行的查询数据库的操作就建议不要做了，这样子很容易搞垮DB。

冷热消息写库操作

和上边的场景相似，当消息抵达到Broker节点之后，如果对方用户此时不在线，则需要将消息记录为到离线记录状态，当对方用户在线状态才将离线消息更新为在线消息。

用户聊天内容监控检测

在实际业务场景中，针对用户的聊天数据做监管也是一件非常重要的事情，例如发送的文本是否有黑词信息，当然这类场景通常不建议在做消息发送的整个链路中去加入。比较常用设计思路可以是：加入一个额外的消息消费者，订阅每条消息发送时候的特定mq，对每个发送的文案进行安全判断，如果发现用户发送的文案有问题，则存放到一个缓存集合中，另外开启一个定时任务定期清理这批缓存数据信息。

用户在线判断逻辑

用户在线这种状态的判断其实还是需要结合应用软件自身的定位出发去思考。例如一些对于用户在线状态要求并不是那么高的产品而言，它对于在线的定义可能就是：用户今天有登录过app，或者说用户登录app时间距离现在小于30min之类的，有些更为精准的策略则是要求计算出用户当天实时在线的状态。下边我们一同来看看这几类场景该如何去实现。

用户最近30分钟内活跃

通常这类型的判断都是通过客户端主动上报活跃信息来实现的，例如在es中建立一个文档，用于记录用户最近活跃时间点。每当用户触发某个页面的时候就会自动上报一下活跃信息。这类型的设计整体开发起来会比较简单，而且也并不复杂。

用户实时在线状态

这类功能得要依靠心跳包机制来进行判断，当用户首次登录app应用的时候，就要和后台的IM服务器建立连接，建立好了连接之后需要通过心跳包的机制去保持存活。

不过这类设计的开发成本通常都会比较高，所以在选用这种方案的时候需要考虑下成本因素。