共计 2830 个字符，预计需要花费 8 分钟才能阅读完成。
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 音视频通信原理
