手写 RPC 实战：基于 Netty 完成客户端与服务端基础通讯

在分布式系统大行其道的今天，RPC（Remote Procedure Call，远程过程调用）早已成为微服务架构的"水电煤"。它让开发者像调用本地方法一样调用远程服务，彻底屏蔽了网络通讯的复杂性。而 Netty，作为高性能异步事件驱动的 NIO 框架，凭借其卓越的吞吐量和低延迟特性，几乎成为 RPC 框架的"标配底座"。

本文带你从零理解：如何基于 Netty 手写一个轻量级 RPC 框架的核心通讯层。不谈源码，只讲原理与实战思路，让你知其然更知其所以然。

一、RPC 的本质：一次"网络代理"的魔术

剥开 RPC 华丽的外衣，其核心无非是 "客户端发起请求 → 服务端执行 → 返回结果" 这一标准网络请求闭环。但难点在于，如何让这个过程对使用者完全透明？

• 客户端：需要一个"代理对象"（Proxy），当开发者调用 userService.getUser(1) 时，代理会拦截这次调用，将方法名、参数类型、参数值序列化成字节流，通过 Netty 发送出去。

• 服务端：需要监听端口接收请求，反序列化后找到对应的服务实现类，执行方法，再将返回值序列化回传给客户端。

在这个过程中，Netty 扮演的就是高速传输通道的角色——它基于 NIO（非阻塞 I/O）模型，能支撑海量连接并发，这是传统 BIO（阻塞 I/O）无法企及的。

二、通讯协议设计：让双方"听得懂"彼此

在动手搭建客户端和服务端之前，必须先约定"通讯语言"，也就是协议。Netty 只负责传输字节流，它不关心内容含义。因此，我们必须定义一套双方都能解析的数据格式。

实战中最常用的方式是 "定长 Header + 变长 Body" 的协议结构。例如：

• 魔数（4 字节）：用于校验是否是合法请求，防止恶意数据包。

• 消息长度（4 字节）：记录整个数据包的长度，用于粘包拆包处理。

• 请求 ID（8 字节）：唯一标识一次调用，用于异步回调匹配。

• 消息体（变长）：真正的内容，包括调用的类名、方法名、参数等，以 JSON 或 Protobuf 序列化。

有了这套协议，客户端发出去的"字节流"到了服务端，服务端就能按位置截取并解析出完整请求，反之亦然。

三、客户端：发起调用与异步等待

客户端的核心逻辑分为两步：连接建立和请求发送。

1. 连接管理：Netty 的 Bootstrap 类负责启动客户端，配置 EventLoopGroup（线程组），并设置 ChannelInitializer 来添加编解码处理器（Handler）。这里关键点是设置 keepalive 和 tcpNoDelay 参数，以优化长连接的稳定性。

2. 请求发送与响应等待：当代理对象触发调用时，客户端将请求对象序列化为字节，通过 ChannelHandlerContext 写入 Socket。因为是异步非阻塞，我们不能直接"等"结果，否则线程会阻塞。实战中的标准做法是使用 CompletableFuture 或 Promise 机制：发送请求前，先生成一个唯一 ID，将其与一个 Future 对象存入 Map 中；当服务端响应返回时，Netty 的 Handler 根据响应中的 ID 从 Map 中取出对应的 Future，并 complete() 返回结果。这样，上层调用者就能同步等待，而底层依旧是异步通讯。

四、服务端：接收请求与反射调用

服务端作为"守门人"，需要持续监听端口，它的实现相对对称，但逻辑更重。

• 启动服务：使用 ServerBootstrap，绑定两个线程组（Boss 负责接收连接，Worker 负责处理读写）。同样配置编解码器，确保从 Socket 读到的字节流能还原成请求对象。

• 核心业务处理：服务端接收到完整请求后，会将其派发给业务线程池（而非在 Netty 的 I/O 线程中直接执行，防止阻塞网络读写）。业务线程拿到请求中的 className、methodName、parameterTypes 和 args，通过 Java 反射机制找到本地的服务实现类实例，调用对应方法获得返回值。

• 响应回传：将返回值同样按协议格式序列化，通过 Netty 的 Channel 写回客户端。注意，这里需要处理异常情况——如果反射调用抛出异常，也需要将异常信息封装返回，而不是直接断开连接。

五、难点攻坚：粘包拆包与线程模型

手写 RPC 过程中，有两个"拦路虎"必须解决：

1. 粘包拆包：TCP 是流式协议，数据包没有边界。客户端发送的两个请求可能被服务端一次性读到一个字节数组里，或者一个请求被拆成两次读取。Netty 提供了强大的 LengthFieldBasedFrameDecoder，它能够根据协议中的"消息长度"字段自动截取完整数据包，我们只需要直接使用即可，无需手写拆包逻辑。

2. 线程隔离：Netty 的 I/O 线程（EventLoop）极其宝贵，只负责网络数据的读写和编解码。真正的业务逻辑（反射调用、数据库操作）必须提交到自定义的"业务线程池"中执行。这样即使某个业务方法执行缓慢，也不会影响其他连接的读写，保障了整体吞吐量。

六、实战心得：从通讯到完整框架的跨越

当我们基于 Netty 搭建出基础通讯层后，其实已经完成了 RPC 框架 70% 的工作。剩下的 30%，更多的是服务注册与发现（集成 ZooKeeper 或 Nacos）、负载均衡（随机、轮询、一致性哈希）、以及容错机制（重试、熔断）。

但对于初学者而言，理解"客户端代理 + 协议编解码 + 网络传输 + 服务端反射调用"这一基础闭环，远比直接使用 Dubbo 或 gRPC 更有价值。Netty 赋予了 RPC 飞驰的速度，而精巧的协议和代理设计则赋予了它灵魂。

当你亲手完成一次从客户端发起调用到服务端返回响应的完整流程，看到控制台打印出预期的结果时，你便真正叩开了分布式通信世界的大门。这便是手写的魅力——虽简陋，却深刻。