在电商业务日活几百万的情况下，IM 系统采用分层架构方式，如下图。

分层架构的 IM 系统，整体上包含了【终端层】、【入口层】、【业务逻辑层】、【路由层】、【数据访问层】和【存储层】，我们在上篇文章（分层架构 IM 系统之架构解读）中进行了介绍。今天讨论局部的架构调整和演进！

随着用户日活量的增多，业务规模也在逐步增大（即后端接口数量越来越大），而且业务逻辑也越来越复杂；为了引流，平台几乎每周都会做运营活动，此时 IM 系统的业务逻辑全部集中在 Logic 中实现，会愈加繁杂；此时系统表现出的最大的问题是：非核心的业务（如各类运营活动）影响核心的业务（如收发消息、联系人）。

怎样解决该问题呢？将非核心的业务和核心的业务进行拆分即可。上图 IM 系统我们称之为分层架构1.0，那么分层架构2.0见下图。

在业务逻辑层中，包含 Logic 和 Extlogic 两个服务：由 Logic 负责处理核心的、实时性较高的、轻量级的业务，比如：用户登录、点对点消息、群消息、消息已读等； 由 Extlogic 负责处理处理非核心的、实时性较低的，重量级的业务，比如：广播系统消息、离线用户召回等；然后由 Logic 通过 RPC 方式远程调用 Extlogic；Extlogic 如果要推送消息到客户端，直接将其推送到 Entry 即可。

业务逻辑层拆分成 Logic 和 Extlogic 之后，各类运营活动的代码直接在 Extlogic 完成，核心的 Logic 逻辑不会受到运营活动代码的侵入；再一个，频繁重启的是 Extlogic 进程，核心的 Logic 进程大大减少了被重启的次数，保证了核心业务的稳定性。

随着业务的不断迭代，仔细分析 Extlogic 的业务，其业务接口的执行逻辑结果如何，并不会影响到 Logic 的执行逻辑，也就是说：Logic 在执行业务逻辑的过程中，并不关注 Extlogic 的执行结果，只是将业务事件通知到 Extlogic 即可。此时，Logic 和 Extlogic 通过 RPC 这样一种高耦合的方式进行通讯就不是太合适。

再一个，自研的内存存储 Router，随着在线用户量的增多，其维护的复杂度也增大，可以通过成熟的组件进行优化。分层架构 IM 系统3.0见下图。

在 3.0 版本的 IM 系统中，引入了 MQ 消息中间件：MQ 一方面解耦了 Logic 和 Extlogic，同时解耦了 “平台业务” 对整个 IM 系统的调用；在整个电商平台中，有非常多的业务（比如订单、支付、物流、客服等）需要借助于 IM 系统，实现定制化消息的推送。

另外，引入缓存（Redis），替换 Router，大大降低了对用户在线状态中央存储维护的复杂度。

最后，总结文中关键：

1、分层架构 IM 1.0，业务逻辑层通过 Logic 实现所有的业务逻辑；

2、分层架构 IM 2.0，业务逻辑层通过 Logic 实现核心的业务逻辑，通过 Extlogic 实现非核心的业务逻辑；

3、分层架构 IM 3.0，引入 MQ，一方面解耦 Logic 和 Extlogic，一方面解耦电商平台和IM系统；引入 Redis，替换 Router，降低对中央存储维护的复杂度。

大家思考一下：

在分层架构 IM 系统中，入口层 Entry 需要处理哪些问题呢？