作为以即时通讯为导向的平台，聊天消息的收发是最基础的功能。消息系统的稳定性、可靠性、安全性尤为重要。消息系统的构建与设计的过程中，本身就面临着较多的难点，而针对toB场景的消息系统，需要支持更为复杂的业务场景。
针对toB场景的特有业务有：
消息鉴权：关系类型有群关系、同组织同事关系、好友关系、多组织关系、上下游关系。收发消息双方需存在至少一种关系才允许发消息；
回执消息：每条消息都需记录已读和未读人员列表，涉及频繁的状态读写操作；
撤回消息：支持一定时间内有效期撤回动作；
消息存储：云端存储时间跨度长，最长可支持数年的消息存储，用户消息需优化，减少机器成本；
小天互连IM系统能够将平台上其他用户发送的消息、系统提醒的消息、集成系统推送的消息等准确、快速的推送给用户登录的终端，让消息找人，实现触达即执行。消息驱动：事务即消息，消息找人，触达即执行
一切皆消息：任何平台和使用者相关的变化，关联的变化，都是以消息形式出现。任何集成到平台业务系统，有和使用者相关的变化，关联的变化，也都以消息形式出现。有待办、有消息通知、有公告、有变化变更等等，消息都会触发。
消息找人：触发的消息，以多种形式，多种渠道推送给关联者。通过客户端内特定的消息通道，私聊群组分享的消息，以及客户端所在系统内的消息渠道进行推送。重要的消息，还可发送短信，拨打语音电话。不是让人去找消息，而是将消息推送到人。
触达即执行：收到消息的人，可在一个界面内，一键式处理消息。消息触达，事情也处理完了。整个过程自然流畅，方便快捷。技术探究
消息引擎
小天互连IM系统建立了自有的消息引擎，用于处理消息操作。消息引擎由接入层、CGI层、逻辑层、存储层组成。
接入层：统一入口，接收客户端的请求，根据类型转发到对应的CGI层。客户端可以通过长连或者短连连接xtproxy。活跃的客户端，优先用长连接发起请求，如果长连失败，则选用短连重试。
CGI层：http服务，接收xtproxy的数据包，校验用户的session状态，并用后台派发的秘钥去解包，如解密失败则拒绝请求。解密成功，则把明文包体转发到后端逻辑层对应的svr。
逻辑层：大量的服务和异步处理服务，使用自研的rpc框架，svr之间使用tcp短连进行通信。进行数据整合和逻辑处理。和外部系统的通信，通过http协议，包括手机厂商的推送平台等。
存储层：消息存储是采用的是自研的msgkv，分表存储。seqsvr是序列号生成器，保证派发的seq单调递增不回退，用于消息的收发协议。消息收发模型
消息收发模型采用了推拉方式，这种方式可靠性高，设计简单。如消息时序图所示，发送方请求后台，把消息写入到接收方的存储，然后push通知接收方。接受方收到push，主动上来后台收消息。
不重、不丢、及时触达，这三个是消息系统的核心指标。
1. 实时触达：客户端通过与后台建立长连接，保证消息push的实时触达；
2. 及时通知：如果客户端长连接不在，进程被kill了，利用手机厂商的推送平台，推送通知，或者直接拉起进程进行收消息；
3. 消息可达：假如遇到消息洪峰，后台的push滞后，客户端有轮询机制进行兜底，保证消息可达；
4. 消息防丢：为了防止消息丢失，只要后台逻辑层接收到请求，保证消息写到接收方的存储，失败则重试。如果请求在CGI层就失败，则返回给客户端出消息红点；
5. 消息排重：客户端在弱网络的场景下，有可能请求已经成功写入存储，回包超时，导致客户端重试发起相同的消息，那么就造成消息重复。为了避免这种情况发生，每条消息都会生成唯一的标识，后台通过建立索引进行排重，相同的消息直接返回成功，保证存储只有一条。消息存储安全机制
小天互连将消息索引和消息内容进行了分离，数据库中保存消息索引信息，消息内容采用文件的方式存储，既利用了快速的数据搜索，同时避免了消息内容保存在数据库中会导致数据库日益庞大而效率低下问题。
小天互连提供了完善的数据清除和备份机制，可以定时的自动清除消息记录。同时只需要拷贝少量的文件夹目录就可以进行数据的备份工作。
系统提供有效的安全保障机制，采用开放的跨平台技术，用户可以根据自身要求和当前状况选择硬件平台和操作系统平台，维护和排错迅速，运行稳定可靠，小天互连的模块化设计保证了重要数据的完整性、一致性和可恢复性。
