IM——基本系统架构

1.用户角度的聊天系统

如果我们站在一个使用者的角度从直观体验上来看，一个简单的聊天系统大概由以下元素组成：用户账户，账号关系，联系人列表，消息，聊天会话。

这个应该不难理解

1.聊天的参与需要用户，所以需要有一个用户账号，用来给用户提供唯一标识，以及头像，昵称等可供设置的选项。

2.账号和账号之间通过某些方式（比如加好友，互粉等）构成账号间的关系链

3.你的好友列表或者聊天对象的列表，我们称为联系人的列表，其中你可以选择一个联系人进行聊天互动等操作。

4.在聊天互动这个环节产生了消息。

5.同时你和对方之间的聊天消息记录组成了一个聊天会话，在会话里能看到你们之间所有的互动消息

2.开发者眼中的聊天系统

从一个IM系统开发者的角度看，聊天系统大概由这几个部分组成：客户端，接入服务，业务处理服务，存储服务和外部接口服务

1.客户端：客户端一般是用户用于收发消息的终端设备，内置的客户端程序和服务端进行网络通信，用来承载用户的互动请求和消息接收功能。我们可以把客户端想象为邮局业务的前台，它负责把你的信收走，放到传输管道中。

2.接入服务：可以认为是服务端的门户，为客户端提供消息收发的入口。发送的消息先由客户端通过网络给到接入服务，然后再由接入服务递交到业务层进行处理。

我们可以把接入服务想象成一个信件管道，联通了邮局的前台和信件分拨中心。但是实际上，接入服务的作用很大，不仅仅只有保持连接和消息传递功能。

当服务端有消息需要推送给客户端时，也是将经过业务层处理的消息先递交给接入层，再由接入层通过网络发送到客户端。

此外，在很多基于私有通信协议的IM系统实现中，接入服务还提供协议的编解码工作，编解码实际主要是为了节省网络流量，系统会针对传输的内容进行紧凑的编码（比如 protobuf），为了让业务处理时不需要关心这些业务无关的编解码工作，一般由接入层来处理。

另外，还有session维护的工作很多时候也由接入服务来实现，session的作用是标识哪个用户在哪个tcp连接，用户后续的消息推送能够知道，如何找到接收人对应的连接来发送。

另外，接入服务还负责最终消息的推送执行，也就是通过网络连接把最终的消息从服务器传输送达到用户的设备上。

3.业务处理层：是真正的消息业务逻辑处理层，比如消息的存储，未读数变更，更新最近联系人等，这些内容都是业务处理的范畴。是整个IM系统的中枢大脑，负责各种复杂业务逻辑的处理。就好比你的信到达分拨中心后，分拨中心可能需要给接收人发条短信告知一下，或者分拨中心发现接收人告知过要拒绝接收这个发送者的任何信件，因此会在这里直接把信件退回给发信人。

4.存储服务：账号信息，关系链，以及消息本身，都需要进行持久化存储。

5.外部接口服务：第三方平台的离线消息推送

3.IM系统都有哪些特性

1、实时性

2.可靠性：不丢消息，消息不重复

3.一致性

4.安全性

Q:为什么接入服务和业务处理服务要独立拆分呢？

A:1、接入服务作为消息收发的出入口，必须是一个高可用的服务，保持足够的稳定性是一个必要条件。

试想一下，如果连接服务总处于不稳定状态，老是出现连不上或者频繁断连的情况，一定会大大影响聊天的流畅性和用户体验。而业务处理服务由于随着产品需求迭代，变更非常频繁，随时有新业务需要上线重启。如果消息收发接入和业务逻辑处理都在一起，势必会让接入模块随着业务逻辑的变更上线而频繁启停，导致已通过网络接入的客户端经常性地断连，重置，重连。

这种连接层的不稳定性会导致消息下推不及时，消息发送流畅性差，甚至会导致消息发送失败，从而降低用户消息收发的体验。

所以，将“只负责网络通道维持，不参与业务逻辑，不需要频繁变更的接入层”抽离出来，不管业务逻辑如何调整变化，都不需要接入层进行变更，这样能保证连接层的稳定性，从而整体上提升消息收发的用户体验

2.从业务开发人员的角度看，接入服务和业务处理进行拆分有助于提升业务开发效率，降低业务开发门槛。

简而言之就是，业务人员只需要关心业务处理就好。

Q:消息存储的作用：

1.会话一方用户不在线，上线时进行消息推送

2..内容审查，监管，电子证据，法律要求

3.数据分析，舆情分析