写这种自建IM的文章我其实特别有感触。前两年我们部门要做内部沟通工具第一反应是想找现成的商业SDK结果对比了一圈不是功能臃肿就是费用太高数据还全部过第三方服务。最后我把目光转到开源IM项目上挖到一款非常典型的轻量级开源即时通讯系统——界面交互几乎1比1还原了微信的聊天体验但整个代码库干净利落没有一堆用不上的功能堆砌。这个项目让我第一次意识到一个真正好的开源IM不是功能越多越好而是能不能让你在最短时间内跑通一条完整的消息链路。如果你也是后端开发、客户端开发或者架构师想自建IM又不想从零造轮子这篇拆解应该能帮你省下不少时间。1. 项目定位解读轻量级开源IM想解决的三个核心问题1.1 “1比1还原微信”到底还原的是什么很多人听到“1比1还原微信”第一反应是界面像素级复刻其实真不是这个意思。开源IM说的“还原”还原的是微信这套成熟产品在聊天场景里的核心交互逻辑会话列表、单聊、群聊、消息状态发送中/已送达/已读、撤回、置顶、未读计数还有通讯录和好友验证流程你日常高频使用的聊天功能在这类项目里都能找到对应的实现。从我实际使用的体验来看这种“产品功能上的还原”恰恰是自建IM最稀缺的部分。市面上很多开源的即时通讯组件只解决一件事——把消息从A点传到B点至于会话怎么组织、未读数怎么记、离线消息怎么补发全部留给你自己写。而这类还原微信交互的开源IM直接把产品层、业务层、传输层打通了部署完之后你看到的是一个“能用的聊天软件”而不是“一堆接口”。当然要提醒一句这种还原是功能层面的参考不是让你拿去做一个高仿微信的壳子去分发。它真正的价值是给你一套可参考的完整产品设计让你站在一个成熟IM的思路上做自己的业务。1.2 轻量级不等于功能缩水关键在设计取舍“轻量级”这个词经常被误解。有人觉得轻量就是功能少、代码少、啥都干不了。实际上我看过的开源IM项目轻主要体现在三件事依赖少、模块边界清晰、部署成本低。举个最直观的例子整套系统跑起来只需要一个服务端加一个客户端服务端依赖的无非就是数据库、缓存和一套长连接服务不需要你上一堆微服务组件。代码层面连接管理、消息收发、业务接口、数据存储这几个模块分得很清楚。你改动某个模块不会牵一发动全身。但轻量也意味着有一些取舍。端到端加密、万人超级群、分布式消息路由这类重型IM才有的能力这种轻量级项目通常不内置需要你自己扩展。所以选择这类项目之前要有个预判如果你的目标是做一个企业内部沟通工具、客服IM、或者带聊天功能的行业应用它非常合适如果你想做一个对标企业微信级别的超级IM那就得考虑更重的方案。1.3 选择开源IM而不是商业SDK的真实原因商业IM SDK当然有它的优势稳定、省事、功能齐全。但对于很多团队来说商业SDK的问题恰恰是“什么都给你安排好了你也什么都改不了”。数据存储在别人那里、协议是黑盒、客户端UI要按着他的规范来。尤其是企业内部的私有化部署需求商业方案往往要按设备数、用户数收费一年下来不是小数目。开源IM就不一样。代码在你手上你可以把它嵌进自己的业务系统可以跟企业内部账号体系打通可以做深度定制。数据完全自主可控。当然代价就是要自己处理部署、运维、二次开发的问题。从我的实际经验看只要团队里有一个人能看懂Java或者Go代码这种投入就完全可控而且能积累下一套属于自己的IM技术资产后面接什么项目都能复用。2. 系统架构与核心模块拆解一条消息从发送到送达的完整链路2.1 长连接与消息通道的设计思路所有IM系统的地基不是数据库表设计不是业务接口而是那根贯穿始终的长连接。为什么IM不用普通的HTTP请求轮询我给你算一笔账传统HTTP轮询是客户端每隔几秒请求一次服务器“有没有新消息”假设一个客户端1秒轮询一次1000个在线用户就是每秒1000次请求其中绝大部分都是在问“没有新消息”服务器资源全浪费在空转上。长连接思路完全不同。客户端和服务器建立一条TCP/WebSocket连接后服务器主动把消息推给客户端。没有新消息的时候这条连接几乎不产生通信只是定期发个心跳包告诉服务器“我还活着”。单从资源利用率看长连接就是为IM这种“被动接收消息”的场景量身定做的。那长连接是怎么维护的关键在连接管理模块。服务端会维护一张在线连接表通常存在Redis里记录每个用户的连接状态、所在节点、最近心跳时间。心跳超时了就判定用户离线把状态改成离线后续消息走离线存储用户重连上来再查一遍离线消息补发。这套机制就是IM在线状态的核心比你想的要简单但坑很多后面我专门讲排障。2.2 消息收发与可靠性投递机制我们从一次最简单的对话来看一条消息的完整生命周期。用户A给用户B发一句话经过的路径大致是这样的A的客户端把消息封装成协议包通过长连接发送到接入服务接入服务先做基础校验然后把消息丢给消息服务消息服务把消息持久化到数据库同时更新会话列表和未读计数接着查一下B是否在线——如果在同一台服务器上直接通过本地连接推送如果在别的节点通过消息总线转发过去B收到消息后返回一个已接收回执客户端再展示“已送达”状态。这里最容易被忽略的是可靠性。IM系统最容易犯的错就是“发送即忘”。真实的IM架构里发送端会维护一个待确认队列发出去的消息如果一段时间没收到服务端的ack就会自动重发。服务端收到重复消息时通过消息ID做幂等判断保证同一条消息不会被重复存储和重复投递。离线消息也不仅仅是“存一下”那么简单。一个用户离线期间可能有几百条消息源源不断进来每条都要落库等用户上线后再分页拉取。这个逻辑如果没设计好用户一上线客户端就要拼了命地拉消息很容易出现消息顺序乱、丢消息的现象。做这类项目时消息ID用单调递增序列是一个比较稳的方案按ID翻页就能保证不重不漏。2.3 会话、联系人与消息存储的核心表设计存储设计是整个IM系统里最考验基本功的部分。我们看一个通用方案大致是这么几张核心表。用户表user用户ID、昵称、头像、密码摘要、状态这些基本字段没什么悬念。会话表conversation一个会话对应一个聊天窗口。单聊是两个人一个会话群聊是一群人一个会话。关键字段是会话类型、最近一条消息的内容、最近消息时间、成员数。这张表就是聊天列表页的数据来源。成员表conversation_member记录每个用户和会话的关系包含会话ID、用户ID、最后已读消息ID、未读消息数。为什么不能把未读数直接存用户表因为一个用户有N个会话一个会话有N个用户多对多关系必须拆出来。消息表message字段包括消息ID、会话ID、发送者ID、消息类型文本/图片/语音/系统消息、内容、发送时间、撤回标记。这里有个性能关键点——消息表是增长最快的所以通常需要按会话ID做分表或者按时间归档。像“1比1还原微信”这类项目消息表的索引设计基本都会围绕“查最近N条”“按会话翻页拉历史”这两个高频场景来建。群聊的处理也值得一提。发一条群消息时消息本身只落库一次然后通过“扩散写”的方式给每个在线群成员推送在线通知离线成员则靠上线后的同步机制补齐。这种方案比“每发一条群消息就给每个成员写一条消息记录”省太多空间了是行业里比较通用的做法。3. 部署与二次开发实操把IM系统跑起来并改成自己的3.1 环境准备与快速启动流程大部分轻量级开源IM项目的技术栈都比较常规常见组合是Spring Boot MySQL Redis WebSocket/Netty客户端有Web版和移动端版本。部署前先确认环境我拿一套典型配置说明你用同类版本基本可以照抄JDK 8 或 11MySQL 5.7 或 8.0Redis 6.xMaven 3.6Node.js如果Web端需要自己构建部署流程一般也就三步。先把整个项目从Git仓库克隆到服务器用IDEA打开服务端代码。检查配置文件里的数据库连接和Redis配置改成你自己的地址。建好数据库后执行项目自带的SQL初始化脚本。然后启动服务端。启动成功后再用浏览器打开Web客户端页面配置一下WebSocket服务地址如果看到“连接成功”的状态说明长连接已经通了。这一步有经验的人会多做一个动作先看日志。正常启动时日志会打印服务监听端口、数据库连接池初始化完成、Redis连接测试通过这几条关键信息。不要看到端口起来了就觉得自己成功了长连接服务是常驻进程任何一条依赖连不上都会导致运行期问题而且这种问题在日志里往往隐藏得很深。3.2 服务端与客户端的关键配置项解析配置是部署过程中最容易让人懵的环节。我来解析几个必须搞明白的配置项理解了它们以后换什么IM项目都能举一反三。先看服务端。端口配置不用多说。数据库连接池的初始连接数和最大连接数值得注意如果预期在线人数不多不需要开太大的池子反而浪费。Redis的key前缀也要留意多环境共用一套Redis时用不同前缀区分测试环境和生产环境不然数据全串了。再看WebSocket服务。连接路径、心跳超时时间、消息体大小上限三个参数很关键。心跳超时时间设得太短稍微有点网络抖动就误判用户离线设得太长用户真正断线了要很久才能感知到。消息体大小上限决定单条消息能传多大的文本默认值通常够用但如果你要做文件消息、图片消息的base64直传必须手动调大不然客户端发大消息会被默默截断而且不报错。客户端配置相对简单服务器地址、端口、连接协议ws还是wss、自动重连间隔。有一点要特别说生产环境一定要用wssWebSocket over TLS如果只在HTTP站点上跑ws浏览器会直接拦截这是很多初次部署的人踩的最多的坑。3.3 以最小成本做二次开发接入自己的业务账号体系自建IM系统最常遇到的一个需求就是不要用项目自带的注册登录而是要跟公司已有的账号体系打通。这个改动其实比你想的要小很多。以Spring Boot服务端为例一般消息接口会有一个获取当前登录用户的方法。比如从请求头里拿token解析出用户ID。你需要做的就是把这段逻辑替换成对接公司内部SSO的代码。接好后修改Redis里存储用户状态的方式把项目自建的用户ID映射成公司工号或者统一ID剩余功能不用动。还有一个很常见的改造是发业务卡片消息。普通文本消息content存的是纯字符串但如果你要发一条包含标题、摘要、图片、跳转链接的小程序样式卡片可以把消息类型扩展成“卡片消息”把content存成JSON字符串客户端再按类型解析渲染。这个扩展思路基本是通用的我在好几个项目里都这么干过改动量很小但能解决很多场景需求。建议二开前先做的事情通读连接管理模块和消息存储模块不需要每行都看懂但要知道消息进来走什么类、落库走什么Mapper、推送时怎么找到目标连接。这两个模块理清了后面百分之八十的改动你都能知道往哪里下手。4. 高并发场景下的性能优化从几千连接到几十万在线的改造思路4.1 单机部署的瓶颈主要卡在哪里很多团队用IM系统刚开始用户量不大单机部署完全跑得动。但是业务增长后在线人数、消息量上来了单机瓶颈就暴露了。IM系统的单机瓶颈有三个连接数、消息吞吐量、存储写入性能。连接数是最早撞到的墙。每条长连接在服务器上都是一个文件描述符还占内存缓冲区、线程资源。一台常规配置的云服务器撑起一两万个并发长连接往往已经到了极限注意是连接数不是同时在线逻辑用户数——一个用户可以多端登录还要多算几倍连接。消息吞吐量紧随其后。单机消息处理的瓶颈通常在数据库写入。特别是群聊场景一个大群几百号人一条消息进来要更新会话、写消息记录、给在线成员推送、给离线成员记账这些操作在一个进程里处理时CPU和数据库IO很快会被顶满。等到CPU使用率和数据库慢查询同时拉高时单机已经救不回来了必须在架构上做分层。4.2 连接层和消息层分别怎么扩展要支撑更高并发第一步是把接入层做成无状态的。也就是说长连接服务拆成多个实例前面加一层负载均衡。客户端的WebSocket地址是一个域名DNS解析到负载均衡器负载均衡器按最小连接数算法分发给不同实例。此时“用户连到哪台机器”这个问题就被负载均衡抽象掉了服务端不关心具体节点。但这里有一个IM系统特有的麻烦用户A连在实例1用户B连在实例2A发消息给B实例1怎么知道要把消息推给实例2上的B答案是实例之间要同步在线状态和转发消息。最通用的做法是用Redis的发布订阅模式实例1收到消息后往Redis一个主题里发布一条通知所有实例都在订阅这个主题谁发现目标用户在自己节点上谁就执行推送。这个方案工程上很成熟也是轻量级系统升级并发时最常见的第一板斧。消息层也要跟着改造。原来同步写数据库的方式在高并发下要改为异步削峰先把消息写入Redis队列再由一个独立消费者批量落库。批量插入可以把数据库写入性能提升好几倍而且还能顺带做消息幂等。这里有一个平衡点要把握好——异步落库意味着极端情况下可能会短暂丢失数据但IM场景对秒级消息可用性要求不是特别高大部分团队能接收这种折中。4.3 性能测试方法与核心参数调优做高并发改造不能靠感觉。项目上线前我会用压测工具模拟几千个WebSocket客户端同时连接、同时发消息先把服务端的表现量化出来。压测时要重点盯三个指标每秒处理消息数TPS、消息投递延迟的P99值99%的消息在多少毫秒内送达、以及连接建立的成功率。压测过程中最常发现的问题是线程池配置不合理。Netty默认的EventLoop线程数是CPU核数的两倍实测下来这个值偏低可以适当调大但要拿数据说话不要一味加。Redis连接池的最大连接数如果设很小高并发下会出现获取连接超时消息就会积压在队列里。还有几个容易被忽略的系统层参数Linux的net.core.somaxconn决定服务器端等待accept的连接队列长度默认值太小会导致高峰连接直接被拒文件描述符上限ulimit -n至少要设到65535以上。这些参数网上都能查到配置方法改造完务必压测验证不要只改不测。5. 常见问题排查手记与避坑清单5.1 部署阶段最容易踩的坑聊几个我实际部署过程中遇到过的坑很多都是环境问题但排查起来很费时间。第一个坑是MySQL的字符集。网上大多数开源IM项目默认建库的字符集是utf8mb4但如果你用MySQL 5.7之前的版本或者建库时没注意建出来是utf8mb3那中文没问题但emoji表情比如微信里常见的这类存进去就是乱码或者直接报错。库里还没建表的话最快的方式是建库时直接指定字符集CREATE DATABASE im DEFAULT CHARSET utf8mb4。第二个坑是Nginx反向代理WebSocket时默认配置不会转发Upgrade和Connection这两个协议头前端一直显示连接失败但后端日志看没有报错。这个需要在Nginx站点配置里手动加两行proxy_set_header Upgrade $http_upgrade以及proxy_set_header Connection upgrade。大部分所谓“部署之后连接不上”的案例十有八九是这个问题。第三个坑是防火墙和端口。常见部署方式下WebSocket端口是独立的比如TCP 8080或8443这个端口和HTTP端口不是一回事。云服务器安全策略里只放行了80/443但8000端口没放行用户自然连接不上。排查的时候先在本机测用命令行WebSocket客户端连一下ws://127.0.0.1:8080/ws通了再检查云策略。5.2 消息发送失败或消息丢失的排查路径消息发不出去这个问题出现时先不要急按路径排查。先看发送方。客户端发消息后有没有收到服务端的成功回执如果连回执都没有基本是消息压根没送到服务端。查这几种可能性客户端连接断开了但界面还显示在线、请求被防火墙拦了、消息内容超过服务端限制被丢弃。再看数据库。消息是否落库了如果服务端ack了但库里查不到消息说明问题出在持久化环节比如异步落库的队列出问题消费者崩了。查队列长度和消费者日志。再看接收方。如果消息落库了但对方没收到接下来要查接收方连接状态。在Redis里查看对方在线状态的key如果显示离线消息是走的离线补发逻辑此时客户端需要重新上线发起同步如果显示在线但不推送就要看推送服务和消息总线的日志了。一开始自己遇到消息“神秘消失”的时候我也是到处翻代码后来总结出一个经验先把“服务端有没有收到”“服务端有没有存下”“服务端有没有发出”这三个节点的日志串起来看两分钟就能定位到问题在哪一段完全不用猜。5.3 避坑清单汇总排查过程中我把最常见的坑整理成了一张表平时自己排查基本就对着这张表操作。问题现象可能原因解决办法客户端连接失败一直转圈WebSocket路径不对或者Nginx未转发升级头确认代理配置添加Upgrade转发中文正常emoji存库报错数据库字符集不是utf8mb4重建数据库或修改表字符集经常显示“已送达”但没“已读”接收端App被系统杀死长连接断开设置保活机制或接入厂商推送通道群消息延迟高消息扩散逻辑在单线程里处理改为多线程扩散或批量推送服务端CPU飙升日志级别太高或循环日志刷屏把日志级别调到WARN按业务打点采样大图片发不出去Nginx的上传大小限制增加client_max_body_size配置用户离线后消息丢了离线消息没有单独存储检查离线消息写入逻辑和补发接口两台服务器之间消息不通Redis pub/sub通道未配置检查Redis网络连通性并配置共享主题这张表不是万能的但它覆盖了轻量级IM系统最常见的八成问题。真遇到没覆盖到的按上一节说的“串三个节点日志”的思路去查基本都能找到答案。我个人在实际改造这套开源IM的过程中最大的体会是不要把思路一开始就放在“我要加多少功能”上而是先花时间去理解长连接管理和消息存储这两条主线。这两条主线只要搞清楚IM系统不管是自用还是交付都给客户你都能做到心里有底。现在很多项目看起来功能花哨折腾一圈回来底子还是这两件事。把这个底子打牢了后面你不管是用这套系统给企业做内部沟通工具还是在这个基础上扩展成带业务属性的行业IM都能顺理成章地推进下去。