接到“基于Java NIO与Netty实现高并发微信个人号消息代理服务”这类需求时我第一反应不是写代码而是把题目里的几个关键词拆开盯了几分钟高并发、Java NIO、Netty、消息代理服务。做过长连接网关的人都知道真正难的不是“能把消息发出去”而是当几万条长连接同时在线、每秒几千条消息穿梭时连接状态、线程模型、消息可靠性还能不能稳得住。这篇文章就是把这套架构从设计到落地完整讲清楚给正在搞高并发IM、消息推送或自研网关的同学一个能直接参考的工程模板顺带说说那些常规文档里不会写的坑。先讲清楚一个前提个人号消息代理这个方向非常容易被用歪。我这里只讨论在合法授权、符合平台规范前提下的消息聚合、自动提醒、客服消息中转等场景且能走官方开放通道就优先走官方通道完全不涉及任何钻平台规则空子的手段。本文的核心是把“长连接高并发消息代理”当作一个通用技术问题来拆解重点放在NIO/Netty架构、高并发设计和工程落地经验上。1. 项目需求拆解与整体架构思路1.1 消息代理服务到底要扛什么所谓消息代理服务本质上是一个长连接网关。它不是我们常说的消息中间件Kafka/RabbitMQ那种而是面向大量账号实体的接入层负责把客户端的长连接管理起来同时向上游业务方提供指令下发和状态回传的能力。放到这个项目里业务实体是微信个人号但是换成企业微信、钉钉、自研IM客户端架构完全复用。这类系统要解决的三个核心问题连接管理几万到几十万条TCP连接要长期稳定在线不能被网络抖动、服务端重启、客户端切换网络搞垮。消息路由上游业务发来“给某个账号下发一条通知”的指令时网关必须快速找到对应的连接准确写过去客户端上报的结果也要能原路返回给业务方。状态与可靠性连接在线离线、消息是否送达、ack是否回来、超时要不要重试这些状态必须清晰否则整个系统就是一团乱麻。我见过不少团队一开始就在写业务逻辑结果连接量一上来线程池被打爆、内存泄漏、粘包解析乱掉最后全部返工。正确的做法是先想清楚架构边界再动手。1.2 为什么选Java NIO Netty而不是BIO我经常被问到这个问题尤其在给新人讲解的时候。用一句话回答BIO是“一个客户端一个线程”NIO是“一个线程管一万个客户端”Netty是把NIO封装到极致。传统BIO模型下每个TCP连接都要占一个线程线程又要占栈内存和CPU上下文切换的资源。按1条连接1个线程来算5万连接就是5万线程这还没算业务线程。操作系统不可能无限创建线程就算能创建调度开销也会把CPU耗光完全没有可扩展性。Java NIO引入的三件套——Buffer、Channel、Selector——提供了多路复用的能力。一个Selector线程可以同时监听成千上万个Channel的读写事件哪个Channel有数据就处理哪个没有事件就阻塞等待。这就像银行网点从“一个客户配一个柜员”改成“一个接待员引导大家到空闲窗口”人力成本大幅下降。但直接基于Java NIO自研网关非常不划算。Selector的空轮询bug、ByteBuffer的粘包拆包处理、半包重排、异常断开连接清理、心跳超时检测这些轮子全部自己造的话开发周期少说两三个月而且极易出问题。Netty把这些全部封装成了成熟组件同时保留了极高的灵活性。还有一个现实因素Netty在Java生态里几乎是长连接服务的标准答案Dubbo、RocketMQ、Elasticsearch、Spark的底层通信都大量使用。团队招人、排查问题、找资料都要容易得多。1.3 整体模块划分与一次消息的完整旅程这套代理服务的物理模块可以这么划分客户端/个人号实体(长连接) - Netty接入网关(协议编解码、心跳、流量控制) - Session管理与路由核心(在线状态、连接定位) - 业务异步线程池(处理业务逻辑不阻塞IO线程) - 缓存与存储层(Redis MySQL) - 对外API(给上游业务下发指令)模块之间的依赖关系必须单向不能出现业务逻辑反向依赖Netty Handler的情况。一次“上游下发消息给客户端”的完整旅程是这样的上游业务调用网关的API传入目标账号ID和消息内容。API层生成全局唯一消息ID交给路由核心。路由核心查Redis中的route:userId - gatewayId映射确认目标账号落在哪个网关节点。本节点直接通过Session表找到Channel写到TCP连接非本节点则通过内部RPC或MQ转给对应网关。客户端收到消息后回ACK网关把投递状态更新到缓存和数据库。如果超时未收到ACK进入重试流程重试3次仍失败则标记为“投递失败”等待账号上线后走离线消息补拉。这条链路里的每一步都有专门的设计点下面逐个拆开讲。2. 通信协议设计与Netty粘包拆包实战2.1 通信协议帧怎么定长连接网关的第一件事是定义清晰的消息协议。TCP是字节流协议没有消息边界所以必须在业务层自己约定帧格式。我常用的一个轻量级二进制协议格式如下字段长度(字节)说明魔数2固定为0x5A 0x5A快速识别非法连接版本号1协议版本方便后续演进消息类型10心跳 1业务请求 2业务响应序列号4由发送方生成用于去重和请求追踪包体长度4后续payload业务body的长度业务body不定长JSON或Protobuf序列化后的数据头部总共12字节包体我限制最大2MB。这个上限要显式配置在解码器里否则一个超大长度字段就可能让解码器申请巨大内存直接被恶意包打挂。为什么不直接用现成的字符串分隔或全JSON传输小业务可以但高并发场景下二进制协议体积小、解析快Netty的ByteBuf对二进制操作又是天然友好。至于body内部用JSON还是Protobuf我倾向业务初期用JSON方便排查问题等性能瓶颈明确后再切Protobuf不要一上来就上Protobuf增加调试成本。2.2 用LengthFieldBasedFrameDecoder解决粘包拆包“粘包/拆包处理”是Netty面试和实战里的高频问题。现象说起来很形象TCP是水管里的连续水流根本没有“包”的概念。客户端一次写了一个完整帧服务端read可能把两次写入的数据合并成一个字节数组读出来这叫粘包反过来一个帧数据太大分了好几个TCP段到达服务端第一次只读到半个帧这叫拆包半包。Netty提供LengthFieldBasedFrameDecoder专门解决基于长度字段的帧切割。我的协议里长度字段在偏移8的位置占4字节前面8字节是魔数、版本、消息类型、序列号。配置如下ch.pipeline().addLast(frameDecoder, new LengthFieldBasedFrameDecoder( 2 * 1024 * 1024, // maxFrameLength最大帧长度2MB 8, // lengthFieldOffset长度字段从第9字节开始所以偏移是8 4, // lengthFieldLength长度字段占4字节 0, // lengthAdjustment长度字段值就是真实body长度无需调整 12 // initialBytesToStrip剥离前12字节头部让下游拿到纯body ));这个配置的语义是读满12字节头部后解析长度字段然后等待累计长度达到12 bodyLength再切出一个完整帧最后把前面的12字节去掉把纯body交给下一个Handler。这里有一个工程细节initialBytesToStrip 12意味着下游Handler拿到的ByteBuf只剩业务body拿不到序列号和消息类型。如果业务需要这些头部信息就不要剥离而是在下一个Decoder里自行读取这12字节并组装成完整Message对象。我实际项目中更推荐后者因为路由、追踪都依赖序列号单纯把头部剥掉等于把关键上下文丢了。如果不用Netty现成Decoder自己写ByteToMessageDecoder也是可以的核心逻辑长这样public class MessageDecoder extends ByteToMessageDecoder { Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) { if (in.readableBytes() 12) { return; // 字节不够头部长度等下次数据到达再继续 } in.markReaderIndex(); short magic in.readShort(); if (magic ! 0x5A5A) { ctx.close(); return; } in.readByte(); // version int type in.readByte(); int seq in.readInt(); int length in.readInt(); if (in.readableBytes() length) { in.resetReaderIndex(); // 半包重置读指针等待下一批数据 return; } byte[] body new byte[length]; in.readBytes(body); out.add(new Message(type, seq, body)); } }这个写法的关键是“读不够就resetReaderIndex然后return”这样下一个TCP段到了之后会从正确位置继续解析。理解这个小细节粘包拆包问题就通了一大半。2.3 心跳机制与空闲连接检测长连接最怕“僵尸连接”——TCP断了但双方没有感知这类连接会一直占着文件描述符和内存。解决手段就是心跳。我的方案是客户端主动心跳服务端做空闲检测ch.pipeline().addLast(idleHandler, new IdleStateHandler( 60, // readerIdleTime60秒内没读到任何数据触发读空闲 0, // writerIdleTime不检测写空闲服务端本身有下行推送 0, // allIdleTime不开启整体空闲 TimeUnit.SECONDS ));客户端每30秒发一个心跳包服务端收到后原样返回心跳响应。如果某条连接60秒没读到任何数据就认为是半死连接进入userEventTriggered处理逻辑Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent event (IdleStateEvent) evt; if (event.state() IdleState.READER_IDLE) { int failCount SessionManager.incrementHeartBeatFailCount(ctx.channel()); if (failCount 2) { // 连续3次读空闲判定死链 ctx.close(); } } } super.userEventTriggered(ctx, evt); }客户端断线重连也要讲究不能一断就连。我见过最朴素的实现是死循环重连服务端还没恢复客户端已经用几千个线程把端口打到半开。正确做法是指数退避加随机抖动第一次1秒、第二次2秒、第三次4秒最大到60秒同时加上随机0到1000毫秒的偏移避免大量客户端在同一瞬间重连形成“重连风暴”。2.4 会话管理与在线状态机连接建立不代表会话生效。一条连接从TCP建立到真正能收发业务消息要走状态机INIT - HANDSHAKING - AUTHED - ACTIVE - CLOSEDINIT是TCP刚建立时HANDSHAKING是客户端发来握手包、携带token和账号ID服务端验签通过后进入AUTHED此时把Session写入全局表状态变为ACTIVE连接断开或踢下线则进入CLOSED并清理资源。Session对象我通常这样设计public class ClientSession { private String userId; private Channel channel; private volatile boolean authed; private long lastActiveTime; private int heartbeatFailCount; private MapString, Object attributes new ConcurrentHashMap(); }全局的在线表用ConcurrentHashMappublic class SessionManager { private static final ConcurrentHashMapString, ClientSession SESSIONS new ConcurrentHashMap(); public static void addSession(ClientSession session) { SESSIONS.put(session.getUserId(), session); } public static ClientSession getByUserId(String userId) { return SESSIONS.get(userId); } public static void removeSession(String userId) { SESSIONS.remove(userId); } }这里面有一个多端登录的处理取舍。早期我做的时候允许同一账号多处登录一个userId对应多个Channel结果路由逻辑变得非常复杂给账号下发消息时要广播还是点对点哪个端优先后来业务确认默认一个账号同时只能在线一个端重复登录时强制踢掉旧连接。这样路由表就能保持在“账号ID - Channel”的一一映射简单可靠。最容易被忽视的是channelInactive里的清理。我踩过坑连接断开时只关了Channel忘了删Session导致Redis里的在线状态还是“在线”后面消息全推到死连接上。所以channelInactive里必须做三件事从Session表删除、从在线状态缓存删除、广播下线通知。3. 高并发与可靠性保障实践3.1 线程模型与业务异步化Netty的线程模型是Reactor模型的典型实现。一个NioEventLoopGroup包含多个NioEventLoop每个NioEventLoop负责一批Channel的IO读写。它像学校里的一个班主任同时盯着几十个学生Channel谁举手有读事件就处理谁。两个Group的分工是bossGroup负责accept新连接线程数建议1到2个。workerGroup负责已建立连接的IO读写线程数一般设为CPU核数 * 2。如果一个8核16线程的机器跑Java进程worker线程设16基本合理。设太少浪费CPU设太多线程切换开销反而拖慢延迟。Netty规范里反复强调一句话不要在EventLoop线程里做阻塞操作。查数据库、查Redis、调用远程接口、大循环计算这些都是阻塞操作一旦放到IO线程里这一个EventLoop下管的几百上千条连接全部跟着卡住。一个连接慢查询影响一批连接这就是长连接服务雪崩的常见开端。正确做法是Netty Handler收到消息后把业务逻辑丢到一个独立的业务线程池private static final ThreadPoolExecutor BIZ_POOL new ThreadPoolExecutor( CPU_COUNT * 2, CPU_COUNT * 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(1024), new ThreadFactoryBuilder().setNameFormat(biz-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() ); Override protected void channelRead0(ChannelHandlerContext ctx, Message msg) { BIZ_POOL.execute(() - { try { Object result businessService.handle(msg); ctx.channel().writeAndFlush(result); } catch (Exception e) { log.error(handle message error, e); } }); }线程池参数里最值得强调的是队列。我见过很多人用无界LinkedBlockingQueue觉得只要不拒绝就行但消息峰值一来队列无限膨胀内存直接被撑爆。用有界队列加拒绝策略让压力在入口就暴露出来比默默堆积到OOM强得多。至于拒绝策略CallerRunsPolicy会把任务塞回EventLoop线程执行、变成慢性阻塞也不算最优更稳妥是自定义策略记录失败消息、返回错误响应、触发限流降级。这块要结合业务容忍度来定。3.2 流量控制与背压保护高并发网关还有一个隐藏问题消息生产速度远超TCP发送能力。一个客户端的接收窗口只有几十KB服务端不管对方能否承受就一直写写缓冲就会无限增长最终内存被撑爆。Netty提供WriteBufferWaterMark高低水位保护ch.pipeline().addLast(new WriteBufferWaterMark(32 * 1024, 64 * 1024));写缓冲低于低水位32KB可以继续写超过高水位64KB进入不可写状态。业务线程在发消息前先检查Channel.isWritable()Channel channel session.getChannel(); if (!channel.isWritable()) { // 暂存待发队列或按消息优先级丢弃可降级消息 pendingQueue.offer(message); return; } channel.writeAndFlush(message);这个机制不复杂但很多人没意识到TCP发送缓冲会爆炸。我接手过一个现成项目高峰期网关占内存8个G全是写缓冲里堆的字节加上ByteBuf池化反而加剧了问题。除了单连接背压还需要全局限流。对单个账号可以用令牌桶限制每秒消息条数比如每账号每秒10条对整个网关限制每秒总下发消息数超出的消息进入降级流程。限流这件事越早做越省心等被流量打挂了再补就晚了。3.3 消息可靠性序列号、ACK与幂等高并发消息代理服务里“至少一次投递”是最常见的语义。因为网络传输不可能保证不丢包所以要靠ACK和重试覆盖丢失场景。我的消息流转设计是上游调用下发API时生成全局唯一messageId。网关记录“待ACK消息”到本地pending表设置超时时间。下发消息到客户端时消息体内携带messageId和客户端自己的seq。客户端收到后回复ACKACK里带上messageId。网关收到ACK后删除pending记录更新消息状态。超时未ACK则重试最多3次超过次数后标记失败等待下一个重试周期或人工干预。这里最容易踩的坑是重试导致重复投递。客户端网络状况差时ACK到了但网关已经超时重发消息客户端就收到两条。所以一定要做去重// 消息去重集合可以用Redis SETNX boolean first redis.setIfAbsent(processed:: messageId, 1, 5, TimeUnit.MINUTES); if (!first) { // 重复消息直接返回成功 return; }判断“是否已处理”放在业务处理最前面用Redis的setIfAbsent天然具备原子性天然就是幂等键。这个思路和数据库唯一索引如出一辙靠同一把锁拦住重复。3.4 MySQL高并发与数据一致性凡是被热搜词点名的“MySQL高并发解决方案”放到这种代理服务里核心就三个连接池控制、批量写入、分库分表。连接池。我用HikariCP配置关键参数如下maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 max-lifetime: 1800000 idle-timeout: 600000很多人觉得连接池越大越好其实不是。MySQL每开一个连接都要分配资源几百个连接去抢一个数据库反而把数据库线程打满。宁可让少量请求排队等待连接也别让连接池本身成为新的故障源。批量写入。消息流水表的写入压力非常大。如果每来一条消息就一条INSERT数据库磁盘IO会先扛不住。正确做法是在业务线程池里把消息聚合成批攒够50条或100条触发一次批量INSERT或者每隔10ms触发一次以时间换批量INSERT INTO message_log (user_id, message_id, content, status, create_time) VALUES (?, ?, ?, ?, ?), (?, ?, ?, ?, ?), (?, ?, ?, ?, ?);一批50条比50次单条INSERT开销小一个数量级实测吞吐提升非常可观。分库分表。用户量上来后message_log表按userId做哈希分表比如64张表再按月份做二级分表message_log_202601。分表键一定选查询最频繁的条件我们这里就是userId这样单用户查询消息记录永远落在同一张表不需要跨表聚合。数据一致性是另一个大坑。在线状态、未读消息数这些数据同时存在Redis和MySQL经常出现不一致。我的经验是以MySQL为最终事实源Redis只是加速缓存写操作先更新MySQL再删Redis缓存。读操作先读Redis缓存miss回源MySQL再回填缓存并设置过期时间。并发更新用版本号乐观锁UPDATE ... SET status ?, version version 1 WHERE msg_id ? AND version ?避免两个线程互相覆盖。延迟双删那套“先删缓存、再更新DB、延迟再删一次”的做法可以用于极端一致场景但要考虑到业务里常见“缓存和DB最终一致就能接受”不必把架构搞得太重。3.5 压测指标与Netty调优参数压测是检验架构的唯一标准。我在8核16G、JDK17环境下用自研压测客户端模拟了大量长连接记录的参考数据如下连接建立从0到2万条连接全部建立并完成握手在2.5秒以内。心跳维持2万连接稳定在线心跳报文占用CPU不超过5%。下行消息单机峰值为6000 QPS左右P99延迟18ms。内存2万连接、每连接平均约占用80KB内存总占用约1.6GBGC频率正常。Netty参数调优是我每次上线前必做的一步ServerBootstrap b new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .option(ChannelOption.SO_REUSEADDR, true) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) .childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(32 * 1024, 64 * 1024));SO_BACKLOG1024Linux内核半连接和全连接队列长度。高并发握手时这个值太小会直接丢连接。SO_REUSEADDR重启端口复用不然服务停了马上起会被“Address already in use”卡住。TCP_NODELAY禁用Nagle算法小消息立即发送避免30毫秒到40毫秒的延迟抖动。池化分配器减少ByteBuf创建销毁开销。压测过程中盯三样东西GC日志、线程状态、TCP连接数。GC频繁往往意味着ByteBuf泄漏或创建过多短生命周期对象线程block通常说明业务代码阻塞了EventLoop连接数只增不减就要重点排查死链接没有被清理。4. 常见问题与排查技巧实录4.1 粘包/拆包问题排查我见过最经典的故障服务上线第二天客户端开始报“消息解析失败”打开日志发现很多帧的body长度字段读成了负数或者消息体变成乱码。这种基本可以断定是粘包问题长度字段没有生效。排查分三步。第一步看抓包用tcpdump在服务端抓几个典型TCP段确认客户端实际发的字节流第二步看代码确认LengthFieldBasedFrameDecoder的参数是否和协议头一致特别是lengthFieldOffset有没有算错第三步做最小复现本地写一个客户端循环发10万条消息服务端统计out对象数量数量和发送包数对不上就是解码问题。实际排查中的一个技巧直接把收到的字节按十六进制打印到日志里对照协议定义逐个字节看。比如帧头魔数5A5A应该在每条独立消息的最前面如果一条日志里出现多个5A5A说明这条bytebuf里塞了多个消息Decoder没切干净。4.2 EventLoop线程阻塞引发的“假死”这是长连接系统比较隐蔽的故障。表面现象是服务没宕机、CPU不高、连接都还在但所有请求都超时心跳也收不到。jstack一下多个NioEventLoop线程停在JDBC Connection相关调用或某个同步锁的park状态。根因一定是有人把阻塞操作放进了IO线程。我在一个老项目里遇到过某个Handler里调用了数据库的SELECT COUNT(*) FROM large_table这条SQL跑了3秒结果这个EventLoop下面挂着的5000条连接全部卡了3秒体验就是“整个网关假死”。排查技巧线上出问题时先打线程快照搜NioEventLoop的栈凡是看到java.net.SocketInputStream.read、RMI、JDBC、lock这类字样立即定位到是哪个Handler引入的。把这个Handler改成提交到业务线程池问题立刻缓解。4.3 连接泄漏与文件句柄耗尽有一类bug是“连接只增不减”。每次客户端重连都成功但旧的连接没有被正确关闭导致lsof看到的TCP连接数持续上涨直到把进程的文件描述符上限顶爆。这种问题通常出在两端要么服务端收到异常断开时没触发channelInactive要么客户端重连时没有关掉旧连接。排查方式是把自定义的ChannelInboundHandler生命周期日志打出来在每个channelActive和channelInactive都打一条对照连接数看是否一一对应。如果channelActive一直涨、channelInactive没动静就是清理逻辑没执行。另外一个容易被忽略的系统参数是文件描述符上限。Linux默认的ulimit -n往往是1024跑长连接服务必须调高至少到100万级别ulimit -n 1000000以及修改/etc/sysctl.conf里的相关参数。这个不说的话新同学很容易在压测到第1000条连接时莫名其妙报“Too many open files”。4.4 ByteBuf内存泄漏Netty的ByteBuf有引用计数机制手动创建后不释放就会出现泄漏。典型报错是日志里的ResourceLeakDetector警告带有LEAK: ByteBuf.release() was not called before its garbage-collected。我用Netty三年真正遇到泄漏基本就这几种情况在Handler里手动Unpooled.buffer()创建了ByteBuf写完没release。在自定义Decoder里把原始ByteBuf切片后存到消息对象业务线程异步使用切片但没有retain()导致原ByteBuf被释放后切片引用失效。writeAndFlush返回的Future里操作了同一个ByteBuf双重释放。最简单稳妥的做法是业务Handler继承SimpleChannelInboundHandlerMessage它会在处理完消息后自动释放引用。手动创建ByteBuf时用ByteBufAllocator.DEFAULT.buffer()用完在finally里ReferenceCountUtil.release(buf)。排查泄漏时临时开启-Dio.netty.leakDetection.levelparanoid让泄漏点信息更清晰。生产环境不要长期开有性能损耗。4.5 重连风暴与热点账号消息挤压服务端一次重启客户端几万条连接同时重连瞬间SYN队列被打满表现为“新连接建立极慢大量connect timeout”。解决这个问题的思路是“削峰”客户端重连连上后不立即发业务请求先等一个随机延迟重连间隔采用指数退避加抖动服务端重启前先从注册中心摘除并广播一条“服务维护中请稍后重连”的消息让存量连接平滑退出。热点账号消息挤压是另一种常见故障。某个大号一天收到几十万条消息它的消息队列一直堆积其他账号的消息也跟着延迟。我现在的处理方式是给每个账号维护独立的有界队列热点账号有单独的子线程池同时在网关层做消息优先级实时通知类优先批量同步类降级到离线表。否则一个热点账号就能把整个网关节奏打乱。5. 集群化扩展与运维落地5.1 单机瓶颈与水平扩展思路单机性能再优化也有天花板。最明显的是文件描述符上限和内存。一条长连接在Java进程里至少占几十KB内存加上Netty的池化缓冲区2万连接就是1.5GB左右10万连接就要七八个G。这个时候不如直接水平扩展。集群化思路是网关节点横向多部署前面放负载均衡或DNS轮询客户端连到任意节点。每个节点管理自己负责的那批连接。关键点是路由表要全局共享。我在部署上采用的是注册中心加Redis route表的方式每个网关节点启动时把自己注册到Nacos/Consul上报节点ID和地址。客户端握手时网关把userId - gatewayId写进Redis带过期时间。上游消息进入任意节点先查本地Session表没命中再查Redis route表发现目标在别的节点就通过内部RPC或MQ转发过去。这个方案对“一个账号同一时刻只在一个节点连接”这种场景非常合适避免了复杂的一致性哈希重分布问题。5.2 跨节点消息路由方案跨节点路由最怕“死循环转发”。我的策略是转发只允许一跳网关A查route表发现目标在网关BA直接把消息投递到B的内部接口B负责下发客户端B不再回转到A。同时在消息头里加一个forwarded标记如果收到的消息已经带了这个标记就不再路由直接返回错误防止两个节点互相踢皮球。Redis route表要处理过期和异常情况。账号断开连接时主动删除route表如果节点宕机route表会残留在Redis里。解决方法是给route表设短过期时间比如300秒同时客户端端口连接断开后要主动重新握手刷新。Redis的故障也会影响路由所以本地Session表的命中率要尽量高查Redis是兜底而不是必选路径。5.3 优雅停机与客户端重连策略运维最怕的是“明天要升级网关今天开始担心”。优雅停机要做的事包括从注册中心摘除节点不再接受新连接。向存量连接广播“服务即将维护”的消息。给客户端一个随机延迟窗口避免同时重连。等待存量连接自然断开或超过最大等待时间后强制关闭。清空本地Session表和pending消息队列做最后的持久化。客户端重连策略我前面提过指数退避加抖动这里再补充一点重连时如果发现原节点还在注册中心可以考虑直连原节点减少路由漂移如果原节点已摘除再走负载均衡重新选一个节点。这样既兼顾了连接稳定性也避免了“刚刚还在线、重连后账号没了”的断档。5.4 监控指标与告警设计长连接服务必须有完善的监控否则故障定位像大海捞针。我常用的指标如下指标采集方式告警建议活跃连接数Handler里的AtomicInteger低于正常水位或接近上限时告警消息下发QPSMicrometer Counter突增或突减路由命中率本地Session命中次数/总路由次数低于90%持续5分钟业务线程池队列深度定时从ThreadPoolExecutor获取队列深度大于800持续1分钟JVM GC暂停时间GC日志 / JMX单次Full GC超过200ms把这些指标用Micrometer暴露给PrometheusGrafana出面板和告警。上线初期宁可多告警也不要漏告警连接数异常下跌往往比CPU飙高更早暴露问题。5.5 鉴权、加密与合规边界安全层面有几件必须做的事握手包必须带签名和过期时间不能裸奔传token。签名可以用HmacSHA256密钥放在配置中心。生产环境开启TLS用Netty的SslHandler包一层。消息内容涉及用户数据不加密等于裸奔。接入方要有独立的appId和secret消息按账号维度做权限校验A应用的业务方不能操作B应用的账号。记录操作审计日志谁在什么时间对哪个账号做了什么操作全部留痕。回到这个项目的性质。个人号消息代理服务如果不加约束很容易被用于营销轰炸、伪造通知、收集隐私。任何工程能力都不该成为这些用途的帮凶。我在业务边界上坚持只有合法授权、且符合平台规则的账号才能接入能走官方开放接口的任务绝不走私有长连接通道。不然技术做得多漂亮方向错了也是白搭。6. 落地过程中的几点真实体会这套架构从单机原型到集群上线我经历过几次比较痛苦的返工。第一个体会是不要一上来就上全家桶。我见过太多团队连协议都没定清楚就先把Kafka、Redis Cluster、注册中心搭起来结果业务还没跑通光排查消息丢失就花了一周。正确的顺序是先在单机把Netty的编解码、Session管理、心跳链路跑通再谈集群和扩展。第二个体会是Netty的线程模型值得翻来覆去看。很多人考八股文能背出Reactor模型但实际代码里还是悄悄在Handler里写阻塞调用。我后来给自己定了一条规矩Handler里除了解析消息和状态判断不允许出现任何IO调用。凡是碰DB、碰Redis、碰外部接口一律丢业务线程池。这条规矩救了我好几次。第三个体会是状态清理比状态建立更重要。连接断开时少删一个Session当时看不出来过两天在线状态表里就多出几千个死账号。我在上线前专门写了一个模拟故障的测试流程随机kill掉服务进程、强制断网、模拟客户端崩溃观察Session表、Redis route表、pending消息队列能否在几分钟内收敛。能收敛的架构才敢上生产。最后分享一个小技巧长连接服务上线前一定把“高峰期重启”演练一遍。优雅停机、客户端重连、路由表清理、离线消息补拉这几个环节串起来跑一遍比任何压测都能暴露问题。我压测跑出过10万连接在线、数据一切正常结果一重启连接全断、重连风暴直接把前端网关打崩。从那以后重启演练成了每次上线前的固定动作。