1、内容概述
一套残缺IM零碎中，除开根本的业务设计，音讯模型的设计是其中最为要害的一环，它关系到整个IM零碎的可靠性、高效性、稳定性，因而须要设计一套正当的消息传递收发机制以承载IM的各种需要，OpenIM联合具体的业务场景，提炼出IM后端的重要接口，并通过反复推敲，验证，设计出了本人的一套通信协议OMTP，协定中每个字段尽量的缩小冗余，使其精简高效、最大限度的满足现有的业务需要并可能反对业务的程度拓展，同时为了达到音讯的实时牢靠与高效，音讯模型也通过了精心设计。
（1）音讯的实时性：音讯的实时性是考验IM零碎的重要规范，传统的IM通过http长短轮询的形式来模仿实时音讯，存在“实时性盲区”，所以OpenIM也同样应用了HTML5的Websocket技术，Websocket是真正的全双工双向通信技术，可能实现服务器被动推送音讯到客户端，实现真正的实时双向通信（服务器告诉客户端有信息达到，客户端随时向服务器发送新音讯），一次连贯，随时都能够应用，不必像轮询技术中一直应用http申请，这样升高了服务器的负载，并缩小一些高频无用的申请。
（2）音讯的可靠性：音讯的可靠性，是指音讯的不失落，不反复，因为网络环境的各种简单状况，包含数据在达到客户端后，数据须要进行各种解析与解决，包含写入db，存入cache，UI的各种展示等等，而且还包含客户端的各种异常情况，当我的项目越宏大时候，应用层呈现谬误的可能性会更高，都可能会造成音讯的失落，通常为了使得音讯更为牢靠，业务层通常采取的计划有：1、在应用层减少ACK音讯，这种计划能够了解为模仿TCP的流程去保障音讯的可靠性，server发送数据达到客户端后，客户端处理完毕（通常是保证数据曾经存入db中）会向server发送一条ACK音讯确认本人曾经收到了音讯，当server收到ACK音讯后才确认音讯曾经胜利交付，否则就会应用某种策略进行音讯的重发；这个计划也会呈现如果ACK音讯发送后，server出于网络的起因没有胜利收到，而后server进行了重发消息，客户端会反复的收到了这条音讯，所以客户端须要进行去重解决。2、音讯减少一条序列号，为每条音讯调配一个音讯ID（OpenIM便是应用的这种计划），对于每个用户而言，在本人的音讯收件箱中，音讯的收取队列中seq应该是间断的，如果客户端层面，或者网络起因造成音讯没可能实时的达到，客户端能够在应用层减少逻辑采取某种策略通过seq比照，本地的seq和服务器的seq之间的差值去拉取没能正确交付到客户端的音讯，这种计划相比于ACK音讯来说，不必每一条音讯都须要server断定ACK来确认音讯是否曾经达到客户端，音讯的获取获取逻辑更加简略，然而音讯的拉取依赖于客户端，如果pull拉取频率过于高，其流量的损耗的也是不低的，所以OpenIM在客户端断网重连，音讯拉取策略上做了优化解决以确保音讯拉取频率在一个适合的范畴。
（3）兼具轻量、高效、低成本：OpenIM设计之初，便是以“所有从简”的准则登程，去除了一些不必要、不合理的设计，使得整个音讯通道更加简洁，零碎更加轻量级，零碎设计应用的是微服务架构形式，每个节点都可能反对集群部署，各个节点之间通过注册核心互连，在集群模式下可能主动的进行负载平衡与流量切换，并且音讯通道提供了给应用服务器回调接口，不便应用服务器对于音讯的管制，不便其余利用可能高效的接入OpenIM并拓展本人的业务，因为OpenIM是一个开源零碎，任何企业和集体都能收费获取源码，并自行构建OpenIM服务，疾速搭建公有IM服务器，并迅速让IM性能集成到本人的零碎中，数据自我把握，不必依赖于别人，相比云服务商，极大的升高了获取IM能力所须要的老本。
服务器层面从音讯发送到接管的流程大抵能够分为两个阶段：
- 客户端发送音讯到服务器阶段
- 服务器传输音讯到客户端阶段
2、音讯发送阶段模型图：
OpenIM音讯的发送阶段，也就是音讯服务的上行阶段，流程如下：
（1）次要由客户端被动发送音讯到服务器，目前所反对的应用层协定次要是http和websocket，为了应答不同客户端的需要，咱们在音讯网关接口中别离设置了https和wss的接口来作为OpenIM的网关接入层。
（2）接口层依赖于ETCD集群（用于RPC服务的注册和发现）调用RPC独特调用音讯处理单元，处理单元处理完毕后将音讯放入MQ中，并返回给客户端相应后果，音讯只有胜利落入MQ中，就能够视为发送胜利，音讯发送的可靠性依赖于MQ集群。
（3）值得一提的是，在音讯的处理单元，咱们减少了内部调用接口（由具体的业务服务器实现的http接口），能够实现业务服务器对音讯的管制解决，例如音讯的禁止发送，过滤等具体的业务需要，这种音讯的回调业务服务器的设定不便使用者能够依据本人的业务需要对音讯进行解决，设立在服务器回调这种形式也更加安全可靠，可见在OpenIM的上行音讯发送阶段，咱们通过ACK、集群化部署等形式，来保障音讯的发送中数据传输的可靠性。
3、音讯传输阶段模型图：
OpenIM音讯的传输阶段（包含将音讯交付到接收者客户端或发送者的其余客户端），即是音讯服务的上行阶段，流程如下：
（1）上游将拆分解决后的音讯放入MQ中，传输阶段次要的工作，是从MQ中拿到音讯，并进行长久化存储以及交付push模块。
（2）在音讯的存储方面，咱们所应用的是收件箱模式，即每个用户都带一个信箱，一条音讯发送后，发送者和接收者的信箱都会减少一条信息，这种写扩散的的形式将写进行了放大，它的长处是，对于客户端而言，无论是间接接收数据，还是被动拉取数据逻辑都比较简单，间接获取本人收件箱外面所有的音讯，咱们次要应用Redis存储音讯的seq(每一条音讯对于接收者和发送者都会产生一个惟一的递增的音讯序列号)，应用MongoDB存储历史音讯（用户间接拉取的音讯），MySQL存储全量的历史音讯（漫游音讯）。
（3）音讯异步交付长久层后，通过RPC调用push模块，为了减少音讯的可靠性，咱们应用了RPC+MQ双向保障音讯推送的达到，当RPC间接调用失败后，会通过MQ直达音讯达到push模块。
（4）push模块次要的工作是负责音讯的传递（包含接收者多端收到音讯，以及发送者多端的音讯同步等），次要是通过将从RPC接口中或MQ中获取的音讯通过接入网关应用websocket进行音讯的在线推送，当用户不在线时，调用三方的离线推送确保音讯可能达到客户端。
在本文中次要论述了OpenIM的特点和在服务器层面上的音讯模型架构设计，不便开发者对后端音讯的整个流程有一个清晰的意识，在后续的文章中，咱们会持续解说OpenIM客户端层面的音讯的架构设计。
源链接:
OpenIM官网
OpenIM官方论坛
更多技术文章：开源OpenIM：高性能、可伸缩、易扩大的即时通讯架构
【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理