开源OpenIM：高性能、可伸缩、易扩展的即时通讯架构

本文属于OpenIM技术团队原创，转载请注明出处，谢谢

网上有很多关于IM的教程和技术博文，有亿级用户的IM架构，有各种浅谈原创自研IM架构，也有微信技术团队分享的技术文章，有些开发者想根据这些资料自研IM。理想很丰满，现实很骨感，最后做出来的产品很难达到商用标准。事实上，很多架构没有经过海量用户的考验，当然我们也不会评判某种架构的好坏，如果开发者企图根据网上教程做出一个商用的IM，可能有点过于乐观了。本文主要从我个人角度深度剖析100%开源的OpenIM架构。当然，世界上没有最完美的架构，只有最合适的架构，也没有所谓的通用方案，不同的解决方案都有其优缺点，只有最满足业务的系统才是一个好的系统。而且，在有限的人力、物力，综合考虑时间成本，通常需要做出很多权衡。我们OpenIM的设计初衷，充分考虑了中小企业的需求，轻量级部署，同时也支持集群扩展，能支持几万用户，也能轻松扩展到上亿用户，是一个可信赖的开源项目。

IM系统技术挑战

可靠性

IM消息系统的可靠性，通常就是指消息投递的可靠性，即我们经常听到的“消息必达”，通常用消息的不丢失和不重复两个技术指标来表示。确保消息被发送后，能被接收者收到。由于网络环境的复杂性，以及用户在线的不确定性，消息的可靠性（不丢失、不重复）无疑是IM系统的核心指标，也是IM系统实现中的难点之一。总体来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令和通知，包括但不限于进群退群通知、好友添加通知等，为了方便描述，统称“消息”）。

从消息发送者和接收者用户行为来讲，消息“可靠性”应该分为以下几种情况：

（1）发送失败，对于这种情况IM系统必须要感知到，明确反馈发送方。如果此消息没有发送成功，发送方可以选择重试或者稍后再试。

（2）发送成功，如果接收方处在“在线”状态，应该立即收到此消息。如果接收方处在“离线”状态不能收到消息，一旦上线则立刻收到消息。

（3）消息不能重复，用数学术语表示：“有且仅有这条消息”，如果重复了，可能表达的意思就变了。
总之，一个商用 IM系统，必须包含消息“可靠性”逻辑，才能谈基本可用，这是IM系统最基本也是最核心的逻辑。

有序性（一致性）

IM系统中，特别需要考虑消息时序问题，如果后发送的消息先显示，可能严重扰乱聊天消息所要表达的意义，会造成聊天语义不连贯，引起误会。消息的时序性，也称为消息收发一致性，主要目标是：保证聊天消息的绝对时序。IM系统中消息时序的一致性问题看似简单，实则是非常有难度的技术热点话题之一。为什么会出现时序问题 1、分布式系统的出现导致时序不一致。IM系统模块众多，接入层、消息逻辑层等、每层都分布式集群化，这些应用分布在不同的机器上，如何保证时序是个难点。2、网络传输延迟导致时序不一致。不同用户发送的消息到达服务器的延时差异较大，给消息时序性带来挑战。

消息时序是分布式系统架构设计中非常难的问题，一个分布式的IM系统必须要解决这个问题，如何高效、低成本解决这个问题，是我们OpenIM要考虑的方向。

实时性