开篇
自互联网诞生以来，即时通讯平台就一直存在。从世界范围来看，WhatsApp、Facebook、 微信、Telegram是领先的消息平台，用户主要使用这些平台与家人和朋友保持联系。随着互联网的发展，人与人之间的沟通是刚需，无处不在，几乎所有的APP都集成IM功能，从社交、游戏、到生活中的方方面面，打车、找房等。可以说IM作为一种通讯能力，已经成为互联网上的基础设施，成为许多APP不可或缺的功能。现在绝大多数APP使用IM云服务商的SDK，方便接入的同时，也带来了几个深层次的问题：（1）成本问题：企业每年额外支付上万乃至数十万的云服务费用，是个不小的成本；（2）数据隐私问题：企业的用户数据、聊天记录等核心数据存储在IM云服务商，如何保证数据的安全性是个极大挑战；（3）需求定制问题：IM需求多样化，IM功能只能由IM云服务商通过SDK的形式提供给大家使用，对于一些定制化的需求，是否支持，什么时候实现，都是个未知数；（4）云服务商绑架问题：一旦使用IM云服务，形成捆绑关系，迁移成本高，受制于人。
OpenIM采用和IM云服务相同的接口，提供服务端和客户端SDK，让开发者以免费或低成本接入IMSDK，并私有化部署，完成IM功能接入。
介绍
OpenIM：由前微信技术专家打造的基于 Go 实现的即时通讯（IM）项目，从服务端到客户端SDK开源即时通讯（IM）整体解决方案。开发文档完善，代码100%开源，支持Andorid、iOS原生开发，支持Flutter、uni-app跨端开发，支持小程序、React等所有主流web前端技术框架， PC支持Electron，可以轻松替代第三方IM云服务。
后台架构
服务端由接入层、逻辑层和存储层组成，好处在于各个层次能够依据业务特点专注于自己的事情，提高系统复用性，降低业务间的耦合。
（1）接入层：消息通过 websocket 协议接入，其他通过 http/https 协议接入，消息是高频及核心功能，通过双协议路由，体现了轻重分离的设计思想。
（2）逻辑层：通过 rpc 实现无状态逻辑服务，易于平行扩展，消息通过 MQ 解耦。
（3）存储层：redis 存储 token 和 seq；mongodb 存储离线消息，并定时删除 14 天（可自行配置）前数据；mysql 存储全量历史消息以及用户相关资料。数据分层存储，充分利用不同存储组件的特性。
（4）Etcd：服务注册和发现、以及分布式配置中心。
消息流程
Open-IM 消息模型采用经典的收件箱模型，并通过全局 seq 做消息对齐，这里带来架构的简化，体现了简单美的架构设计理念。很多开发者通过网络文章，了解到收件箱模型的原理，也知道 seq 的概念，但如何在项目中做权衡和取舍，爱因斯坦曾经说过“事情应该力求简单，不过不能过于简单”，我们看到很多技术文章对收件箱模型和 seq 的滥用，要么系统设计复杂，要么过于简单，最后的结果是系统不稳定，消息可达率无法达到要求。以下我们简单讲解消息如何发送，系统如何简单解耦，接收方如何实时收到消息，并如何利用 seq 做全局消息对齐，确保消息百分百可达。
客户端架构
客户端 SDK 负责和 IM 服务端交互，本地数据存储和同步，消息、事件回调。开发者通过集成 SDK，自行开发聊天界面 UI，设置事件监听回调实现数据和 UI 对接。
Open-IMSDK 分为三层：网络层、逻辑层、存储层。分层治理，各司其职，实现高效、稳定、统一的客户端架构。
SDK集成流程
OpenIM SDK 集成非常简单，由于开发者私有化部署，代码、配置、数据都在自家服务器上，不用向云平台申请 AppKey 和 Secret，相比第三方 IM 云服务，可见 OpenIM 更安全、可控、自由度更高。
OpenIMgithub开源地址：
https://github.com/OpenIMSDK/Open-IM-Server
开发者文档:
OpenIM官网 ： https://www.rentsoft.cn
OpenIM官方论坛：https://forum.rentsoft.cn/
有疑问加站长微信联系（非本文作者）
