1. 为什么要手写通信框架从业务痛点说起1.1 一个让我下决心的线上事故先说个真实的场景。去年我在某电商平台做交易链路优化遇到一个非常头疼的问题核心服务调用下游的会员系统时用HTTP方式每次请求耗时平均在80ms左右TPS一旦过千超时率就直线飙升。简单加了线程池结果Tomcat线程一满整个服务的吞吐量直接归零。当时排障排了一整天最后发现是TCP连接建立和销毁太频繁HTTP头部的浪费也大得惊人。后面我整理了一下HTTP调用在这个场景里有几个致命弱点连接利用率低每次请求都可能新建连接握手开销全摊在业务耗时里。序列化成本高JSON膨胀严重大报文在网络上来回搬运带宽被白白吃掉。线程模型落后Tomcat每请求一线程高并发下线程切换成本巨大。没有连接池意识长连接维护、心跳检测、重连机制都要自己写。那段时间我正好在复习Netty准备面试就想干脆把下游通信从HTTP换成自定义的长连接RPC。于是花了三个周末基于Netty手写了一版高可靠通信框架把它套到线上系统里跑了一段时间。这篇文章就把整个设计和落地过程拆开讲一遍包括协议设计、心跳重连、超时重试、优雅停机这些核心模块以及我在面试中实际被问到的难点解法。1.2 原生NIO的坑与Netty的答案很多人问为什么不直接用Java原生NIO写非要用Netty。老实说原生NIO不是不能写但写出来的代码维护成本非常之高。你需要在业务代码里处理ByteBuffer的读写翻转、Selector的注册和轮询、IO线程的分配还要面对令人头疼的半包粘包问题。比如你读到了一个不完整的消息得自己缓存剩余字节等下一个事件触发再拼接这部分逻辑极其容易出Bug而且排起来非常费劲。Netty把这些东西全包装好了基于事件循环的Reactor模型你不用手动管理线程。提供了开箱即用的编解码器比如LengthFieldBasedFrameDecoder直接解决半包粘包。ByteBuf替代了ByteBuffer读写指针分离自动扩容抛开了flip()的噩梦。内置内存池和零拷贝机制减少GC压力。一个很重要的点是Netty对连接异常、断线重连、空闲检测都有一套成熟的扩展点叫Handler你要做的是把业务逻辑塞进去而不是重造轮子。说白了用Netty是站在巨人的肩膀上做框架而不是自己从地基开始搬砖。你真正要做的事情只有三件定义协议、管理连接状态、承载业务逻辑。1.3 高可靠通信框架到底解决什么问题先梳理一下需求因为我见过很多新手上来就写代码结果写着写着就失控了。我这版框架要解决的其实是四个核心问题通信效率要远高于HTTP核心指标是延迟和吞吐量。稳定性网络抖动、服务重启、GC停顿都不能导致整个调用永久阻塞。易用性上游调用方只需要拿到一个接口代理对象不需要感知底层网络细节。可观测性调用超时、重试次数、连接状态都要有清晰的日志和指标。所以整个框架从设计的第一天开始就没有想过做成一个大而全的中间件而是按最小可用 可扩展的思路来。后面的每一层设计都是围绕这四个问题展开的。2. 整体技术选型与架构拆解2.1 通信框架的边界什么该做什么不该做手写框架最容易犯的错误是贪多嚼不烂。我一开始也差点走偏想把服务注册发现、负载均衡、熔断限流全塞进去后来想清楚了这些都是另一个层面的问题。我这个阶段要做的是一个纯粹的点对点可靠通信底座把网络层的各个细节打磨到极致。框架边界定下来后模块划分就非常清晰了序列化模块负责Java对象与字节数组的互转支持扩展。协议模块定义消息头和消息体的格式保证接收方可以准确解析。网络模块基于Netty封装客户端和服务端包括连接管理、线程模型配置。调用模块同步转异步的实现Future和回调机制的封装。治理模块心跳检测、断线重连、超时控制、重试策略。这样的分层有一个直接的好处就是每一块都能独立测试。比如序列化模块我单独打了一个测试包压测性能网络模块用模拟收发测试验证半包粘包处理最后再整体联调。2.2 五个关键组件与一套流程画一条完整的调用链路你就知道这些组件怎么协作的。客户端发起调用时代理层把方法名、参数对象打包成请求消息交给协议编码器序列化成字节流再通过Netty通道发送到服务端。服务端经过解码器还原出请求对象通过反射调用目标方法拿到结果后再编码返回。这个过程里有五个关键组件不可或缺代理工厂把接口动态代理成调用入口屏蔽网络细节。消息对象请求和响应共用一个结构包括消息ID、消息类型、业务数据。编解码器协议编码器和解码器成对存在各自的Handler在Pipeline里处理。响应映射表用消息ID关联Future对象拿到响应后唤醒等待线程。超时调度器负责检查哪些请求长时间没响应主动失败并触发重试。这五个组件我没用任何复杂的容器全部用普通Java类写好再通过构造器注入组合起来。简单意味着容易维护也意味着面试的时候你能把每个环节讲清楚。2.3 线程模型的底层逻辑Netty的线程模型是Reactor模式划分为Boss线程组和Worker线程组。Boss组负责accept新连接然后把连接注册到某个Worker线程上Worker线程负责该连接所有的读写IO事件。主从Reactor的好处是IO线程和业务线程分离IO线程只管数据收发具体的业务逻辑丢给业务线程池去处理。这个设计极度重要。我在写服务端的时候处理策略很简单将解码后的请求丢进独立的业务线程池IO线程立刻返回。这样做的原因也很直白如果IO线程直接在Handler里执行慢业务会导致该线程上的所有连接都被拖累一个慢请求堵死一大片。线程池参数的配置也踩过坑后面专门在实战部分细说。这里先记住一个原则IO线程的个数一般是CPU核数的两倍业务线程池的存活时间、队列大小要根据接口耗时分布来定。3. 协议设计通信的交通规则3.1 自定义协议结构设计协议是通信框架的命根子。我用的是常规的自定义二进制协议消息头固定长度消息体长度可变。具体字段如下字段长度说明魔数4字节固定为0xA1B2C3D4用于快速校验版本号1字节协议版本方便后续升级消息类型1字节请求/响应/心跳/异常序列化方式1字节标识用的是哪种序列化器压缩标记1字节是否压缩压缩算法类型消息ID8字节全局唯一关联请求与响应数据长度4字节消息体字节长度消息体变长序列化后的业务数据这个协议的每个字段都有它的存在理由。魔数是接收方做的第一层守卫如果第一个字节对不上直接判定非法连接并关闭。版本号和序列化方式保证了服务端升级的时候旧客户端还能通信一段时间。消息ID是整个异步调用模型的基础没有它你根本不知道收到的响应对应哪个请求。在实际测试中这个头部的开销也就20字节左右相比HTTP动辄几百字节的头部省太多了。一个有趣的对比是同样是调用一个简单的getUser方法HTTP请求实体整体在300字节以上我自定义协议可以压到40字节以内这对于高吞吐场景是非常明显的优势。3.2 序列化方案对比与选型序列化决定了三个指标时间开销、空间开销、跨语言能力。我在对比时用了一个8万条用户记录的样例数据测试结果如下方案序列化耗时(ms)反序列化耗时(ms)压缩后大小(KB)跨语言支持Java原生6321090162差JSON300560210好Hessian26038098较好Kryo8910561需注册Protobuf566234好最终我选了Kryo原因很简单在我这个封闭场景里客户端服务端都是Java不存在跨语言需求Kryo的性能和体积都很有竞争力。Protobuf当然更稳但要写.proto文件改动成本高不适合快速迭代的业务。用Kryo有几个注意点Kryo不是线程安全的所以我用ThreadLocal管理要提前注册类型不注册的话每次写入类名会有额外开销。实际测试下来注册后的性能比不注册提升了将近40%这个细节值得注意。3.3 半包粘包怎么破半包粘包问题几乎是面试必问的。TCP是流式协议底层会按缓冲区大小分段也可能会把几个小包合并成一个所以你要自定协议边界。我的代码里直接在Netty的Pipeline加入LengthFieldBasedFrameDecoder配置依赖协议头里的长度字段来切分消息。关键配置参数如下LengthFieldBasedFrameDecoder decoder new LengthFieldBasedFrameDecoder( 1024 * 1024, // 最大帧长度超过直接报错防御大报文攻击 17, // 长度字段偏移量魔数4版本1类型1序列化1压缩1ID8 4, // 长度字段占4个字节 0, // 长度字段后无需额外补偿字节 4); // 剥离掉长度字段本身这个编码方式的处理逻辑是Netty根据长度字段的值从缓冲区中提取出完整的数据帧然后把帧头长度字段剥离把剩余的有效数据交给后面的解码器。加上这个Decoder之后Handler收到的永远是一整包数据半包粘包问题在框架层就被消灭了。面试官如果往下深挖会问LengthFieldBasedFrameDecoder内部怎么处理缓冲你要能答出它是累积到ByteBuf然后做二次扫描的对于超过maxFrameLength的包会抛出异常。这些都是很加分的点。4. 高可靠机制的核心实现4.1 心跳机制与空闲检测长连接的维护离不开心跳。服务端如果发现某个连接长时间没有数据就会认为客户端可能挂了主动回收连接客户端定时发送心跳包试探服务端是否存活服务端不响应就触发重连。我在客户端和服务端Pipeline里都加了IdleStateHandler// 客户端侧3秒内没有写数据就触发写空闲事件 pipeline.addLast(idleStateHandler, new IdleStateHandler(0, 3, 0)); // 服务端侧10秒内没有收到对方任何数据就触发读空闲事件 pipeline.addLast(idleStateHandler, new IdleStateHandler(10, 0, 0));客户端在userEventTriggered里收到写空闲事件就发送一个心跳包服务端收到心跳包后刷新读空闲计时器。如果服务端超过10秒没有收到任何消息包括心跳就认为连接失效主动close。这个机制我在实际环境中验证过效果模拟拔网线场景客户端最多5秒内就能感知连接异常触发重连对比之前用HTTP那套动辄几十秒才发现超时效果差别非常大。服务端的读空闲时间一定要比客户端的心跳间隔大留出余量。比如客户端3秒发一次心跳服务端至少设置10秒避免网络轻微抖动导致的误判。4.2 超时控制与重试策略超时控制是通信框架里最容易写错的模块。我最早用Future.get(timeout)来实现等待超时后来才发现有个隐患如果服务端响应非常晚但客户端已经超时了那么这条响应回来后会找不到对应的Future扔到回调里没人处理就变成了幽灵响应。所以我的超时方案里加了双重保障业务线程在Future上以给定时间等待到点获取不到结果就抛超时异常。定时任务线程同时扫描超时请求表发现超时的请求就主动把对应Future标记为超时状态避免后续响应错误地唤醒它。重试策略上第一版是无限重试上线当天就出问题了某服务挂了所有请求都在重试瞬间打爆了它的下游。后来改成了有限次数加重试间隔退避。我采用的策略是最多重试2次每次间隔50ms且只对网络异常和超时异常重试业务异常一律不重试。这里一定要强调幂等性如果下游接口不是幂等的比如支付接口重试就可能导致重复扣款。我在框架层面提供了一个重试策略接口默认实现是保守的需要幂等的业务可以在服务端处理请求ID去重。4.3 连接池设计长连接虽然省去了建连开销但单一连接在高并发下会成为热点而且无法利用多核。我的方案是维护一个固定大小的连接池每个连接绑定到Netty的一个Channel上通过轮询算法分配连接。public class ConnectionPool { private final Channel[] channels; private final AtomicInteger index new AtomicInteger(0); public Channel getChannel() { int i index.getAndIncrement(); return channels[Math.abs(i % channels.length)]; } public void markInvalid(Channel ch) { // 标记连接失效触发重连机制 } }连接池的初始化和维护是异步的避免阻塞服务启动。当一个连接出现问题被关闭连接池会自动创建一个新连接补位保证可用连接数恒定。测试下来4个连接的客户端在800QPS下依然稳定单个连接在300QPS左右就会开始出现等待。4.4 优雅停机这个点很少人注意但线上差点出事。有次我发布新版本直接kill掉进程结果大量上游调用直接报连接拒绝。原因很简单连接被强杀对端还认为连接是好的还在往这个死连接上发请求。Netty提供了优雅停机的接口我在框架里接入了JVM的ShutdownHook流程是停止接收新请求关闭监听端口。发送一个关闭信号给已连接的客户端告诉它们重连其他节点。等待一定时间默认10秒让正在处理的请求自然结束。关闭所有Channel释放线程池释放连接池。Runtime.getRuntime().addShutdownHook(new Thread(() - { // 1. 标记服务为停止状态 server.setStopFlag(true); // 2. 广播下线通知可选 // 3. 等待在途请求处理完 executor.awaitTermination(10, TimeUnit.SECONDS); // 4. 优雅关闭Netty bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); }));不要直接调用System.exit硬退出。优雅停机除了能避免线上故障面试时提出来也是一大亮点说明你真正考虑过生产环境。4.5 快速失败与熔断如果对端服务彻底挂了重试只会浪费资源。我在客户端加了一个简单的熔断器基于连续失败次数触发连续失败3次进入半开状态后续请求直接快速失败。每5秒尝试一次探测请求成功后重新闭合。熔断状态下调用方立刻收到服务不可用异常不需要等待超时。之所以要做这一层是因为实际场景中服务端故障恢复通常需要几十秒这段时间里不停发起新请求没有任何意义。熔断保证了故障范围被隔离不会引发雪崩。5. 面试难点剖析这些问题才是真正分水岭5.1 从Reactor模型追到线程切换面试官会从为什么用Netty切入然后追到Reactor模型。我最常被问的一个坑是Netty中的连接是单线程处理的如果业务代码不小心在Handler里做了耗时的同步操作会发生什么答案是在该连接上所有事件处理被阻塞包括后续的数据读写、心跳事件整个连接看上去像卡死了一样。更糟的是缓存在Socket缓冲区里的数据一直积压TCP窗口收缩客户端会被迫放慢发送速度。所以我的做法是业务Handler里不做任何耗时操作纯做协议解析然后丢进独立的业务线程池。用EventExecutorGroup也能给Handler绑一个独立线程组但要注意它默认还是和IO线程共享事件循环的精确的线程模型最终要看你的EventExecutor配置。面试官问到这个层次已经是比较深的考察了能答出来很加分。5.2 ByteBuf与零拷贝ByteBuf是Netty底层数据的核心抽象。面试必问和原生ByteBuffer的区别核心就是读写指针分离。ByteBuffer需要flip切换读写模式ByteBuf直接用readerIndex和writerIndex两个指针不需要flip。零拷贝解释起来是有套路的Netty的零拷贝不是传统意义上的CPU零拷贝而是提供几种避免数据复制的机制组合缓冲区CompositeByteBuf将多个ByteBuf拼成一个逻辑视图不实际复制。FileRegion文件传输底层用FileChannel.transferTo直接DMA搬运。池化内存分配内存复用减少GC。ByteBuf的引用计数也要注意我踩过内存泄漏的坑。我在Handler里接收消息后如果要把消息传给其他线程处理必须调用retain()增加引用计数处理完再release()。否则业务线程还没用数据已经被回收了。5.3 内存池不能只背概念内存池的面试深度比想象中深。面试官会问Netty的池化机制是如果分配的我要能大致说出PooledByteBufAllocator基于内存块管理按多个规格默认16字节递增到16MB分类同规格的按链表缓存。我们框架里有一组直接相关的配置PooledByteBufAllocator allocator new PooledByteBufAllocator( true, // 支持堆外内存 1, // 每个线程的堆外内存缓存个数 1, // 每个线程的堆内存缓存个数 8192, // 每块内存块最小字节数 11 // 内存块最大字节数 );启用池化后压测时GC次数肉眼可见地减少。堆外内存分配相比堆内存分配要快但要注意堆外内存不受JVM堆大小控制必须配合-XX:MaxDirectMemorySize设置上限否则内存溢出时很难排查。5.4 高性能下的隐患与排查单个请求的延迟很漂亮不代表高并发下不出问题。我在压测2000QPS时发现一个很奇怪的现象服务端CPU只有50%但吞吐量上不去了客户端大量请求超时。排查过程花了大半天最后定位到问题出在背压机制上。服务端的Netty接收缓冲区大小是固定的如果业务线程处理不过来IO线程不断从Socket读数据填充到Channel的待处理队列队列越来越长内存越来越大最终触发高水位限制Channel自动停止读取。这就是Netty的自动读调节机制。解决方式是服务端也要做流控Channel配置里设置合适的writeBufferWaterMark同时在业务线程池上使用有界队列满了直接拒绝新任务而不是无限堆积。6. 压测与调优实录6.1 压测方案设计与工具选择我用的压测工具比较常规本机搭建了Client模拟真实调用服务端部署在另外一台4核8G的机器上。压测场景是一个查询接口内部模拟了20ms的DB访问耗时。压测步骤是关键。我分了三轮第一轮固定客户端连接数为1逐步提升并发线程数摸清单连接极限。第二轮固定并发线程数为200调整连接池大小观察不同连接数对吞吐量的影响。第三轮固定参数跑10分钟观察稳定性、GC频率和内存曲线。每轮压测完记录四组数据QPS、平均耗时、TP99耗时、错误率。6.2 三个真实数据与调优决策第一轮压测结果让我很意外。单个连接并发线程从50加到200QPS只从420涨到530平均延迟却从48ms涨到120ms说明单连接已经成了瓶颈线程增加只增加排队时间。这个结论直接指导了连接池规模的确定。第二轮对比数据如下连接池大小QPS平均延迟(ms)TP99(ms)错误率15301206800.20%2980621900.03%41730441200.01%81690451270.01%4个连接之后吞吐量就不再上升延迟也基本持平说明瓶颈转移到了业务处理本身。最后一轮跑10分钟内存曲线非常平稳Full GC基本没有但在压测第8分钟观察到一个异常某个消息的TP99从120ms突然跳到800ms持续了十几秒。查日志后发现是业务线程池的队列溢出了。业务线程池核心线程8个队列容量1000理论上2000QPS完全够用但那次对端服务的GC停顿导致单次处理耗时从20ms涨到了500ms排队任务暴涨。我调整了线程池参数把队列改为SynchronousQueue配合CallerRunsPolicy拒绝策略宁可牺牲一点吞吐也要保住尾延迟的稳定性。6.3 排查定位的常用工具压测和线上问题排查离不开工具。我日常使用的组合是jstack抓线程快照看线程状态、等待什么锁。jstat观察GC频率和耗时。netstat看连接数量、收发队列积压情况。自定义指标框架内埋点记录每个阶段的耗时比如发送队列等待时间、IO处理时间、业务执行时间。自定义指标这个做法强烈推荐。我在消息对象的上下文里记了几个时间戳分别标记进入客户端、序列化完成、网络发送、服务端接收、解码完成、业务开始、业务完成、返回客户端。这样压测时候能一眼看出时间都耗在哪个环节。有一次靠这个发现序列化竟然占了40%的总耗时最后通过优化Kryo注册机制才解决。7. 踩坑记录那些文档里没有的教训7.1 连接泄漏一个被忽略的低级问题框架刚写完的时候压测一会儿就OOM。排查后发现是连接池的问题连接池只在初始化的时创建Channel当某个Channel异常关闭后markInvalid方法标记了它但补位的逻辑没有在每次获取Channel时检查状态导致客户端永远在用一个失效的Channel发数据底层一直在抛异常上层却在无限重试内存被异常对象堆满。修法很简单getChannel里加一个isActive检查不活跃就触发重连再返回。这个坑看起来很基础但恰恰是集成多个模块时最容易出现的衔接问题。模块单独测没问题拼在一起就出事。7.2 回调地狱与Future的弯弯绕客户端异步回调版本我用了CompletableFuture但早期代码里出现了回调套回调的情况。一个真正的重试逻辑是发送请求获得Future异步等待响应超时后在这个Future上完成重试重新发一个请求再等响应。这个逻辑如果拆成回调嵌套写法代码非常难懂。后来我改成递归Future的组合public CompletableFutureResponse sendWithRetry(Request req, int retryTimes) { CompletableFutureResponse future doSend(req); if (retryTimes 0) { future future.handle((resp, e) - { if (e null) return CompletableFuture.completedFuture(resp); // 指数退避后递归重试 return sendWithRetry(req, retryTimes - 1).getNow(null); }).thenCompose(f - f); } return future; }这样逻辑是同步的直观格式但执行却完全是异步的可读性和性能兼得。真到线上排查超时重试问题时这种写法的日志链路一眼就能看明白。7.3 序列化版本的兼容性版本升级的时候服务端先发新版客户端旧版还能不能通信我在一个内部类的字段删除后就遇到了反序列化的问题。Kryo注册的类如果中途改了字段结构旧数据可能反序列化失败。我做的处理是三管齐下每个接口级别维护一个协议版本号消息头里带版本字段。服务端发现客户端版本过低返回明确的版本错配异常而不是内部错误。变更字段时保留老字段只加新字段用注解标记废弃而不是直接删除。这样做虽然不能解决所有兼容性场景但至少能保证发布过程的平滑也方便回滚。7.4 IdleStateHandler临界条件有个线上故障非常诡异两个实例之间偶发断连平均每天一两次而且都是凌晨。排查发现是服务端的读空闲时间设成了10秒客户端的正常请求间隔大约9秒心跳间隔15秒。某些请求延迟波动超过1秒的时候服务端连续10秒收不到数据就主动断开了连接。解决办法有两个一是把服务端读空闲调大到30秒二是客户端把心跳间隔加密比如5秒一次保证任意时间窗口内都有数据流动。两种都做了之后这个故障就消失了。心跳参数必须结合业务请求频率来设计不能拍脑袋定。7.5 堆外内存泄漏的排查思路压测完发现进程内存一直涨堆内存却一直平稳Netty的内存池又没有明显的活跃对象。我用了Netty自带的泄漏检测器启动参数加-Dio.netty.leakDetection.levelPARANOID把系统属性设置成最高级别日志里很快就定位到一个Handler在转发消息到业务线程时没有retain导致原对象被提前释放。排查完一定要把泄漏检测调回SIMPLE或者关闭因为PARANOID模式性能开销很大只适合测试环境。这个经验也算是我压箱底的了。8. 手写框架的最终形态与复盘心得这套框架从设计到线上稳定运行前后经历了三轮重构。第一轮能跑通流程但不稳定第二轮补齐了重试和超时控制第三轮才真正把连接池、熔断、优雅停机这些生产级能力做好。每次重构都是被线上问题逼着走的反过来想如果一开始就把这些场景想清楚至少能省下一半的排障时间。框架完成后我拿它和之前的HTTP方案做了对比同样业务场景下平均延迟从80ms降到了22ms吞吐量从800QPS提升到了1700QPS超时率基本归零。这个数字变化是我对一个框架到底解决什么问题这个问题的最终回答。面试层面这个手写的项目是绝对的加分项。Netty相关的常见八股大约有十个方向但我面试时被反复追问的核心始终是几个你的协议为什么这么设计你的线程模型是怎么配置的你的重试机制会不会把线下游打挂你的连接池是怎么维护的。这些问题只要你是真正动手实现过一遍就能给出有细节、能落地的答案而不是背教材。最后再分享一个经验学习Netty最好的路径不是死磕源码而是先拿它做一个小项目遇到问题再看源码。源码文档讲得很细但如果你不知道这些设计解决的是什么真实痛点看了也记不住。从一个小目标开始比如写一个心跳保活的最小通信组件跑通后再一点一点加上重试、超时、连接池整个过程走完你会发现自己对网络编程的理解完全不一样了。