从仿微信IM实战剖析长连接、消息可靠性与音视频通话链路设计

简介：即时通讯（IM）系统是移动互联网应用的基础设施，其核心在于稳定可靠的长连接和高效的消息分发机制。本文从工程师实战视角出发，围绕IM系统的通信层设计，深入剖析基于Netty自定义TCP协议的长连接方案，对比WebSocket在不同网络环境下的优劣，并讲解消息幂等、离线补拉、未读数与会话列表等关键机制。同时，结合位置服务、机器人回调以及实时音视频通话等高频业务场景，介绍了Redis GEO、WebRTC、STUN/TURN与SFU的工程落地经验。针对弱网、高并发、NAT穿透失败等典型问题，本文提供了一套可复用的排查方法论。无论您是正在自研IM系统，还是评估私有化沟通工具的技术风险，都能从中获得从架构选型到问题定界的完整参考，理解消息不丢、不重、秒达背后的工程权衡。

1. 项目概述与整体设计思路

做聊天IM，精仿微信，这半年我一直在折腾这么一套东西。从单聊、群聊、朋友圈，到摇一摇、附近的人、收藏、扫码、机器人、名片，最后还加了实时音视频通话，几乎把微信移动端的主要交互都复刻了一遍。这篇东西适合谁看？大概两类：一类是正在做类似IM项目的开发同学，想知道功能拆开之后每一块到底怎么做，另一类是准备在团队内部做私有化沟通工具的技术负责人，拿这套思路去评估工作量和风险。我先把结论放在前面：聊天界面是最容易的，真正难的是长连接可靠性和音视频的链路质量，这两块如果前期没有设计好，后面会一直被坑。

1.1 仿微信IM系统到底解决了什么问题

很多人看到"仿微信"这三个字，第一反应是套壳、做UI。其实把一个IM做到真正像微信能用的程度，要解决的是一整套通信问题：消息能不能秒达、会不会丢、客户端断网重连之后能不能补拉消息、群聊里几百人同时发消息会不会把服务搞挂、朋友圈的拉取会不会越翻越慢、摇一摇和附近的人背后实际上是位置与随机匹配逻辑，而实时音视频通话又涉及NAT穿透和流媒体转发。这些问题单拎出来哪一个都能写长篇，组合在一起就是一个全栈项目。

回到项目本身，我的目标不是做一个能上架的微信克隆版，而是验证一条完整的技术链路：移动端App + 接入层长连接 + 业务服务 + 多媒体存储 + 位置服务 + 音视频网关。这样一套链路既可以用在企业私有化部署场景里，也可以作为教学项目把“IM”这个抽象概念落到代码上。很多团队想要一套内部沟通工具，但直接拿开源的Matrix或OpenIM又觉得定制成本高，自己从头写又怕坑太多。我这套东西正好卡在中间：功能形状贴近微信，技术选型不依赖特定商业服务，所有模块都能拆开替换。

1.2 技术选型与整体架构演进

技术栈的选型，我反复纠结过三轮。第一轮想得比较简单，后端用Spring Boot，长连接直接上WebSocket，客户端用Flutter一套代码跨Android和iOS。但做到后面发现，群聊消息推送和音视频信令对吞吐量的要求不是普通HTTP轮询能扛住的，Flutter在音视频这块又绕不开原生插件，于是调整成：后端Java + Netty做长连接接入层，业务逻辑用Spring Boot，消息队列用RocketMQ做削峰和异步解耦，缓存和离线数据用Redis，持久化用MySQL。音视频通话没有自己做全套WebRTC服务端，而是把WebRTC核心信令集成在IM服务里，媒体转发用LiveKit组件，这样工作量可控，穿透能力也有保障。

客户端这边，我最终没有用Flutter承接所有功能，因为扫码、摇一摇、实时音视频采集这些功能，跨端框架往往要写一堆Platform Channel，反而比原生更麻烦。所以我做了折中：聊天核心界面用Flutter实现，涉及硬件调用的扫码、摇一摇、音视频通话用Android原生Activity和iOS ViewController，通过桥接层互调。这套混合架构对于一个人独立开发来说是最省力的，UI组件复用度高，底层能力又不会被跨端框架锁死。

架构演进上，我踩过最重的坑是早期把消息直接通过HTTP接口轮询拉取，导致服务端压力巨大，客户端也频繁出现消息延迟。后来改成Netty长连接，架构变为：客户端 -> Nginx LB -> Netty Gateway -> RocketMQ -> 业务服务 -> MySQL/Redis。Netty Gateway负责维持连接、透明转发消息包、代理身份校验，业务服务不持有连接状态，只处理业务逻辑。这样的好处是Netty层可以水平扩展，就算某个Gateway节点宕机，客户端重连到其他节点，只要Redis里的session信息还在，消息链路就不会断。

2. 通信层与消息系统设计

2.1 长连接方案：为什么最终没有只用WebSocket

开发前期，我确实用WebSocket写过一版长连接，调试工具非常方便，浏览器也能直接连。但到了生产化验证时发现两个问题：一是移动网络环境下，WebSocket在切换基站时经常发生“假死”，连接没有主动断开但消息就是发不出去，需要额外的应用层心跳和重连机制维护；二是WebSocket基于HTTP协议升级，在服务端需要维护大量HTTP Upgrade状态，遇到超长连接的资源控制不够精细。所以后期我改成了以Netty自定义TCP私有协议为主，同时保留WebSocket端口作为Web端和调试入口。

这里要提醒一句，并不是说WebSocket不能用，很多成熟IM也有WebSocket接入方案。我的建议是，如果你的用户场景主要是Wi-Fi环境、Web端和移动端共存，用WebSocket可以省去很多协议解析工作；如果目标用户大量使用移动网络、对弱网体验要求高，还是老老实实用自定义TCP协议，或者至少加上更强的应用层心跳策略。我在TCP协议里做的数据帧结构很简单：4字节魔数 + 1字节版本号 + 1字节消息类型 + 4字节消息体长度 + N字节消息体，消息体统一用Protobuf序列化。之所以不用JSON直接裸传，是因为长连接场景下频繁序列化大JSON对CPU和带宽都不友好，Protobuf体积小、解析快，线上问题也容易定位。

2.2 消息模型与通知消息协议

消息协议是整个IM系统的核心，前期没设计好，后期加一个功能就要改协议。我给出的消息模型是这样设计的：

message Message { int64 msg_id = 1; // 消息唯一ID，全局递增，由服务端生成 int64 from_uid = 2; // 发送者ID int64 to_id = 3; // 单聊：接收者ID，群聊：群ID int32 chat_type = 4; // 1=单聊，2=群聊 int32 msg_type = 5; // 1=文本，2=图片，3=位置，4=名片，5=语音，6=视频，7=系统，8=机器人 bytes content = 6; // 消息内容，按msg_type不同对应不同PB结构 int64 client_msg_id = 7; // 客户端生成的临时ID，用于幂等去重 int64 timestamp = 8; // 客户端发送时间 int32 status = 9; // 消息状态：0正常，1撤回，2删除 }

客户端发送消息时，先生成一个client_msg_id，内容结构包括客户端时间戳和正文。服务端收到后先做幂等检查，如果Redis里没有这个client_msg_id就继续处理，否则直接返回重复响应。这样即使客户端超时重传，也不会产生两条重复消息。client_msg_id保存周期我设置为7天，这个时间和离线消息保留时间保持一致，避免用户清理历史记录后仍能重试成功。

2.3 单聊和群聊的消息收发流程

单聊的流程相对简单，客户端A发消息到接入层，接入层校验后投递到消息队列，业务消费者写库、刷新会话时间、计算未读数，再通知接入层向在线用户B推送。A发送成功后客户端会收到服务端回执，回执里携带服务端生成的msg_id，客户端用它替换本地临时ID，同时本地状态从“发送中”变成“已发送”。如果服务端回执返回失败，客户端会触发重试，间隔按1秒、3秒、5秒递增，最多重试3次。

群聊比单聊绕一些，难点在于消息需要分发给所有群成员。我的方案是“写扩散”和“读扩散”结合：成员数量少于200人的群，直接写扩散，也就是给每个在线成员推送一份消息到自己的会话流里；成员数超过200人的大群，则采用读扩散，成员进入群聊页面时主动拉取群消息表，平时只更新群未读计数。这种组合方式写起来不复杂，但能有效避免上万人群聊时写量爆炸的问题。群聊消息的已读回执我没有做全量记录，只统计了已读人数，因为微信本身也只显示群成员是否已读，不做逐人详情，这个数据用Redis计数器就能维护。

2.4 消息可靠性与幂等机制

消息可靠性是IM最容易被低估的部分。做过IM的人都知道，丢一条消息比发不出去严重得多，用户体验是直接“人没了”。为了保证不丢消息，我的做法是三级确认：

第一级，客户端发起消息后等待服务端回执，回执超时则重试。第二级，服务端保存成功后，再向接收方推送，接收方收到后返回ACK。第三级，如果接收方不在线或者ACK超时，服务端把消息写入Redis离线队列，并标记接收方会话的未读计数，等接收方上线后主动拉取。这套机制保证了消息至少被接收方拉取到一次，但不保证不重复，所以配合client_msg_id去重，最终实现“至少一次，不重复落地”。

实际写代码时有一个容易踩的坑：离线队列不能把全部消息都存在Redis里并无限期保留，内存扛不住。我给Redis离线队列里的每条消息加了TTL，默认7天，同时消息全文在MySQL保留30天。接收方上线拉离线消息时，只拉最近7天内的离线消息。更早的消息用户需要通过聊天记录翻页拉取，这样既保证了即时体验，又不会让Redis包揽所有历史存储。

3. 核心业务功能模块实现

3.1 单聊与群聊的会话列表和未读数设计

会话列表看起来是个简单的列表，实际上要做对细节。微信的会话列表是按最后一条消息时间倒序排序的，而且会话的未读数要能实时更新。我的实现是：每个用户维护一份Redis ZSET，key为conversation_list:{uid}，member为会话ID（单聊是对方uid，群聊是群ID），score为最后一条消息的发送时间戳。收到新消息时，更新ZSET的score，如果没有这个会话，就加进去。列表页读取时，先从ZSET取出前20个会话ID，再从Redis哈希表里批量取会话缩略信息（会话类型、最后消息、时间、未读数等）。并发量高的情况下，Redis ZSET依然是性能瓶颈的常见点，所以我做了分片，把用户按uid散到32个分片Redis实例上，实测十万在线用户下写ZSET的压力是可以接受的。

未读数不能只存在服务端，还要在客户端本地有个缓存。我的做法是服务端在推送新消息时带上unread_count增量，客户端本地自增。用户点击某个会话进入聊天页后，客户端上报一个批量已读请求，服务端把该会话未读数清零。这里要注意并发场景：如果用户同时打开多个会话，未读数不能互相干扰，所以客户端上报时只能针对当前打开的会话ID进行清零，其他会话的未读保持不变。

3.2 朋友圈动态的时间线与权限控制

朋友圈是另一个容易低估的模块。它的核心不是发动态，而是朋友圈的时间线是“好友关系+动态发布”的复杂结果集。我的表结构比较简单：动态表保存内容正文、发布用户ID、可见范围、地理位置和发布时间；动态媒体表保存图片或视频的URL和排序；评论表保存评论内容、评论者、回复对象；点赞表保存动态ID和点赞用户ID。这里最关键的一点是，朋友圈拉取必须做分页，而且分页要基于“时间游标”，不能基于传统的页码。因为用户发布动态是动态变化的，如果用页码分页，刷着刷着会出现重复或漏项。

权限控制上，我实现了三种可见范围：公开、仅好友、私密。公开和私密都容易判断，仅好友有一个隐藏坑：朋友圈的动态在好友列表里可见，但这个动态发布时，好友关系可能已经被删除了。所以每次拉取朋友圈时，我都需要去重新校验当前用户与动态发布者的好友关系，而不是信任发布时打上的标签。如果好友数量比较多，这个校验会比较吃性能，我采用了布隆过滤器先过滤掉大部分“非好友”，再对剩余少数做精确查库，实测性能影响很小。

时间线构建我用了“推拉结合”：普通用户朋友圈数据量不大，每次刷新的前几页，直接读取自己好友的动态列表，按时间聚合；对于粉丝特别多的大V账号，则把动态主动推送到关注者的粉丝时间线Redis队列中。在这个项目里，用户量级还不是特别大，所以主要用了拉取模式，推模式留了扩展接口。

3.3 收藏与扫码的通用方案

收藏功能本质上是一个“资源引用管理器”。收藏的不只是文字或图片，还包括语音、位置、名片、文件等，甚至收藏一条聊天记录时会包含多条子消息。所以我没有为每种消息类型单独建表，而是用了一张收藏表加一张收藏内容表，内容表里存content_type和content_id，具体内容仍然通过消息ID去消息表里查找。这样做的好处是收藏展示时高度统一，坏处是如果原消息被删除，收藏内容也需要额外做兜底。我在收藏时会把关键内容做一次快照（文本、图片URL、卡片信息），避免原消息删掉后收藏页变成死链。

扫码模块我分成了两个场景。第一个场景是App内扫一扫，调用系统相机识别二维码；第二个场景是扫码枪输入（比如仓库、门禁场景）。App内的二维码内容我定义了一套自定义协议，比如im://uid/12345表示查看用户，im://group/join?gid=6789表示加群，im://url/http%3A%2F%2Fxxx表示打开链接。服务端下发一个“二维码内容生成接口”，客户端用ZXing生成二维码图片，扫到后通过解析器分发到对应页面。这里有个坑：如果二维码内容里带中文或URL，必须做URL编码，否则扫描后解析会乱码。扫码枪我踩过更大的坑，下面问题排查部分专门说。

3.4 名片与位置消息

名片消息看起来只是发一张卡片，其实背后是一套“用户信息摘要”。发送名片时，客户端会把对方用户的头像、昵称、签名、用户ID打包成一个结构体，放进消息的content字段。接收方点击名片，会先拉起一个用户信息页，再通过接口获取最新的用户资料。这里必须注意：名片快照里的昵称头像可能过期，所以点击后一定要去服务端重新拉取，不能用名片里的静态数据直接显示全套信息。

位置消息同样简单，但要注意经纬度的精度和坐标系。国内地图服务一般用GCJ-02坐标系，而WebRTC定位接口返回的是WGS-84坐标，两者互换有偏移。我在发给好友位置时，客户端已经选择了地图选点，可以直接把GCJ-02坐标显示为地图缩略图。但如果是从GPS原始数据里直接取到的坐标，必须先转成GCJ-02再发，否则位置缩略图和真实位置相差几十米。服务端只负责存储和转发，不做坐标系转换，转换统一放在客户端做，避免不同端算法不一致。

4. 特色功能：摇一摇、附近的人、机器人、实时音视频

4.1 摇一摇的事件匹配算法

摇一摇的核心是“同一时间窗内随机配对”。客户端侧，我用Android的SensorManager和iOS的CoreMotion监听加速度计，检测到一段连续快速变化超过阈值的加速度后，触发一次摇动事件，然后调用服务端的匹配接口。服务端收到请求后，把用户加入Redis的摇一摇池子，池子的key可以按时间片切分，比如每30秒一个桶，用户在30秒内提交的摇动会被放入同一个桶。

匹配规则很简单：如果桶里有其他用户，随机取一个返回给对方；如果桶里已经等待了超过一定时间（我设置为10秒），则开始新的桶。这里有一个体验细节：微信摇一摇是“同时摇动才能配对”，所以客户端接到接口响应后会有一个短暂的转场动画，让用户感觉是在实时搜索。另外，摇一摇的结果页只能展示用户基本信息，不暴露详细位置和通信方式，要让用户决定是否发起打招呼。

摇一摇高并发下，Redis读写压力不大，但要注意防止恶意刷接口。我在接口上做了限流，每个用户每分钟最多摇10次，超过直接返回操作频繁。还有两个坑：一是iOS系统对传感器读取有系统级抖动，不能只用线性加速度大于一个固定值判断，我用的是峰值与均方根结合，检测更稳；二是摇一摇期间，用户可能误触手机产生多次摇动，客户端要做防抖，同一个用户1秒内的多次摇动只算一次。

4.2 附近的人：基于Redis GEO

附近的人要解决的问题是“给定一个经纬度，找出半径范围内的其他在线用户”。我直接使用了Redis GEO，这样不用自己算球面距离，Redis内部用geohash和有序集合实现，查询性能很好。实现时，用户打开附近的人页面时上报一次当前位置，服务端把用户ID和经纬度写入geo:nearby_users，并设置150秒过期。用户刷新列表时，通过GEORADIUS查询以自己为圆心、半径10公里内的用户，按距离升序返回。

这里有两个实际经验。第一，附近的人不需要实时更新，所以上报位置时可以做节流，5分钟内的重复上报忽略，减轻写压力。第二，用户关闭附近的人时，必须调用接口删除自己的位置记录，防止别人还能搜到“幽灵用户”。另外经纬度的精度也影响隐私，我返回给客户端的距离只显示到几百米，精确到米会让人有被跟踪的感觉。附近的人列表页还要做“只看女/只看男”的筛选，这需要在Redis GEO里存用户信息时附带一个profile键，但Redis GEO的member本身不能存附加字段，所以我是用geo:nearby_users:{sex}分集合存储，性别筛选时只查对应集合，省去了逐用户回查数据库的开销。

4.3 机器人消息的集成方式

机器人模块是我这个项目里比较有意思的设计。机器人本质上是另一种类型的用户，但它没有人类操作界面，而是通过服务端到服务端的回调来响应消息。我定义了三种机器人：客服机器人、群管理机器人、智能问答机器人。接入方式上，我提供了一个“机器人接入后台”，让开发者填一个回调URL、一个Secret Token，以及这个机器人能处理的消息类型。当用户发送给机器人账号的消息落库后，消息消费者会异步POST到回调URL，机器人服务收到请求后可以返回一个或多个回复消息，IM服务再把回复投递给用户。

在实际场景里要注意，机器人回调不能阻塞IM主流程。我最初是同步等待HTTP响应，经常遇到机器人服务性能抖动导致消息延迟，后来改成异步回调：IM服务先确认消息已收到，机器人服务在自己的队列里处理，通过另一个“主动下发消息”接口把回复发回IM。这样即使机器人服务挂了，IM本身不受影响。

机器人的另一个重要应用是群管理。我在群里内置了一个小助手机器人，新成员入群时自动发送欢迎语，群里出现违禁词时自动撤回并提醒，@全体成员这个功能也是通过机器人指令实现的。这里需要一个“消息钩子”机制，任何群消息在推送给其他成员之前，先经过机器人处理器，机器人可以决定放行、撤回或改写。钩子机制很容易造成性能瓶颈，所以我只对包含@机器人或者指定前缀（如“/cmd”）的消息做全量处理，其余消息直接透传。

4.4 实时音视频通话的关键链路

实时音视频通话是这个项目里技术含量最高、也最让我掉头发的一块。用WebRTC做一对一音视频通话，大体的流程是：发起方A创建offer，通过IM信令通道发给B；B创建answer，回传给A；A和B交换ICE候选地址；协商成功后，媒体数据直接通过P2P传输。信令通道我可以复用已经做好的长连接系统，只是消息类型加一个SIGNALING类型，承载SDP和候选信息。关键问题在于很多用户处于复杂NAT后面，P2P直连失败率不低，必须部署STUN/TURN服务器。

我给TURN服务器的建议是：如果项目规模不大，直接用coturn开源方案，单机撑几百路没问题。我的部署拓扑是：STUN服务放在公网，TURN服务同样放在公网，当ICE协商发现需要中继时，媒体流量会经过TURN转发。TURN服务器的带宽是整个音视频项目最大的开销，一路720P视频通话大约需要1Mbps到2Mbps的上行/下行带宽，如果是多人会议，这个数字会成倍增加，所以早期我限制一对一通话分辨率不超过720P，多人会议不超过360P。

在客户端实现上，我用LiveKit作为SFU方案，它内置了音视频转发、房间管理和录制功能，省去自己写WebRTC服务端的复杂逻辑。我把LiveKit的业务API和IM系统做了联动：用户点击视频通话时，IM服务先创建一个会议房间，返回房间名和token给双方，双方客户端通过LiveKit SDK加入同一个房间。这样通话过程的信令和房间管理由IM服务负责，媒体流完全走LiveKit，两条链路互相独立，稳定性高很多。如果在没有公网IP的内网环境测试，一定要确保客户端能访问到TURN服务器的3478端口和UDP转发端口范围，否则会发现既连不通又推不了流。

5. 高频问题与排查实录

5.1 消息延迟或丢失的排查思路

消息延迟是IM最容易被用户感知的问题。我遇到最多的情况是客户端已经显示发送成功，但对方很久才收到。排查时应该按下面顺序来：

先看接入层日志，确认消息有没有被Gateway接收到。如果Gateway没有收到，可能是客户端断网重连后没有上报离线消息拉取，或者重连后没有重新订阅会话；这时让客户端在重连成功后，主动调用一次“同步增量消息”接口，把断线期间的消息一次性拉下来。如果Gateway接收到了但消费者处理慢，就要看消息队列的堆积情况，我当时遇到过一次RocketMQ消费线程池配置过小，消息一多就积压，调大消费线程并发数后明显缓解。

需要特别留意的是，如果只有某一个人的消息延迟，大概率是这个人的长连接被服务端误踢了。我的Gateway里有一个心跳超时踢线下线机制，以前把超时时间设得比较短，导致网络上偶尔丢一个心跳包就把用户踢下线，客户端重连后又没有成功恢复session，消息就只能走离线队列。这个问题的解法是把心跳超时时间放宽，同时在Gateway收到重连请求时，主动验证Redis里的token，如果验证通过就销毁旧session并建立新session，避免产生幽灵连接。

5.2 音视频通话的NAT穿透失败

音视频通话常见的问题是“一个能发起通话，但对方一直听不到声音”或者“显示已连接但画面卡住”。第一种情况多半是麦克风权限没开启，但更隐蔽的原因是WebRTC在ICE协商时没有成功收集到有效的host candidate，只收集到了srflx candidate，导致媒体流在经过NAT时无法到达对端。

排查NAT穿透问题时，我习惯在客户端日志里打印完整ICE候选列表，如果发现对方只收到host类型的candidate，说明STUN服务器没有正常工作。要检查STUN服务是否通过UDP 3478端口可访问，以及防火墙是否放行了UDP端口范围。如果确定需要TURN中继但客户端没有拿到relay型的candidate，基本都是TURN服务器的认证配置或者端口没有打通。我在项目中用coturn配置了用户名为随机token的方式，每次呼叫前由IM服务生成一个短时有效的TURN凭证，这样既安全又不用在客户端内置长固定账号。

另外还有一个很隐蔽的问题：如果App运行在HTTPS网页里，WebRTC可能因为浏览器权限策略而无法获取摄像头或麦克风权限，这需要在页面里先申请设备权限。而对于Android App，如果targetSdkVersion较高，必须在代码里动态申请RECORD_AUDIO和CAMERA权限，申请时机最好放在用户点击音视频通话按钮之前，不要在进入视频页之后再弹窗，否则会出现黑屏。

5.3 扫码功能在手机和扫码枪上的兼容问题

手机扫码的坑主要集中在相机分辨率和对焦上。我在Android上用CameraX的ImageAnalysis，如果分析图像的分辨率设置过高，会频繁触发性能问题，导致二维码识别率下降；如果分辨率设置过低，又扫不出小码。实测下来，选择1280x720的预览分辨率配合ZXing的InvertedScanner，兼容性最好。iOS上用AVFoundation输出视频帧，要注意在识别成功之后关闭session，不然扫码页面会一直盯着二维码提示“成功”，非常尴尬。

扫码枪的兼容问题更邪门。我这里遇到过一个案例：霍尼韦尔的扫码枪连接Windows电脑后，在Web页面扫码，输入到输入框里的条形码后面总是多一个回车，导致判断出错。原因是扫码枪出厂默认配置为在扫码成功后发送一个回车键。解决方案有两种：一种是用扫码枪的配置手册，扫一个“关闭回车后缀”的配置码，让扫码枪只输出原始条码内容；另一种是在前端接收扫码枪输入时，监听keydown事件，当捕获到Enter键时，把之前输入的字符串作为条码内容提交，并阻断默认的回车换行行为。第二种方法更通用，不依赖具体硬件。另外还要注意输入框的focus位置，如果页面有多个输入框，扫码枪输入可能噼里啪啦弹到随机输入框里，必须给扫码输入框设置独立焦点区域，或者在全屏模式下统一接收。

5.4 机器人回调超时和群消息风暴

机器人回调超时是接入第三方AI服务时最容易出的问题。第三方接口响应普遍在几百毫秒到几秒不等，如果IM服务同步等待机器人返回，用户体验会被拖垮，而且如果机器人服务崩溃，IM服务还可能堆积大量线程。我的解决方案是：IM服务收到发给机器人的消息后，立即返回“已收到”，并把消息内容写入Kafka的机器人消息主题，机器人服务自己写一个消费者去消费，处理完再调用IM服务“发送消息”接口回复。这一层解耦是必须的，一开始偷懒做了同步调用，线上机器人一旦遇到慢查询，整个IM会话都会卡住。

群消息风暴则是另一个经典问题。当某个大群里有多个机器人互相触发时，会有几分钟内产生几千条消息的风险。我的做法是在机器人回调接口加了一层“每分钟发言次数限制”，每个群每小时最多允许机器人发送10条消息，超出部分自动降级为静默处理。同时在群聊推送层，如果检测到同一个群在1秒内有超过100条消息，就丢弃非@人的普通通知，只保留系统消息和@人的消息，避免把用户手机直接震爆。

6. 写在最后：一些个人的实践心得

这套仿微信IM系统做到现在，最深的体会不是哪个功能有多难，而是所有功能背后都有一套“看起来简单、做起来坑多”的细节。聊天窗口、朋友圈、扫码这些功能，单独看都是很常规的开发任务，但组合在一起并让它们在弱网、高并发、多端设备下稳定跑起来，才是真正考验架构能力的地方。

如果让我重新做一遍，我会在项目启动时就把“消息ID生成”“离线消息存储”“TURN服务器部署”这三件事再提前做重一点。消息ID生成要设计成可拆分、可路由的，不要等量大了再换策略；离线消息存储要有独立的存储引擎规划，不要把Redis当垃圾桶；TURN服务器最低也要两台双机房互备，因为音视频一旦断流，比消息延迟更让用户暴躁。

最后分享一个实操中小技巧：调试长连接相关问题时，别急着看客户端代码，先用命令行工具模拟一个合法连接，抓包确认服务端真的发来了数据，再排查客户端。我有很多次以为自己Netty写错了，结果发现是防火墙把端口拦了，顺手就把客户端和服务端日志一起看，反而绕了弯路。这套东西后续我打算再补一个Web管理端，用来查看在线人数、消息量、音视频通话质量指标，慢慢把它从“能用”打磨成“好维护”。如果你的项目也正在做类似方向，希望这篇内容能帮你避开一部分我已经踩过的坑。

本文还有配套的精品资源，点击获取