如何使用Golang实现RPC序列化与反序列化_Golang RPC数据编码与解码方法

net/rpc 默认用 gob，不支持跨语言；换 JSON 需用 jsonrpc 包并调用 jsonrpc.ServeConn；换 protobuf 应直接用 gRPC；自定义 ServerCodec 必须处理分帧、Header 解析和错误传播。

Go 标准库的 net/rpc 默认使用 gob 编码，不支持跨语言、不兼容 JSON 或 Protocol Buffers——如果你需要自定义序列化（比如用 json 或 protobuf），必须绕过默认机制，自己接管编解码流程。

为什么不能直接替换 rpc.Server 的编解码器？

标准 rpc.Server 和 rpc.Client 将编码/解码深度耦合在 rpc.Server.ServeCodec 和 rpc.NewClientWithCodec 中，底层依赖 rpc.ServerCodec 接口。它要求你同时实现 ReadRequestHeader/ReadRequestBody 和 WriteResponse 等方法，不能只换一个序列化格式。

常见错误是试图“简单替换 gob 为 json”，结果发现请求头读不出来、响应乱序、或连接直接断开——因为 json 没有 gob 那样的类型元信息和流式分帧能力。

• gob 自带类型描述、支持指针/接口/循环引用，且天然适配 Go 运行时；json 是纯文本、无类型、需显式结构体标签
• RPC 协议不是“发一串 JSON 就完事”，它需要严格区分 header（含方法名、序列号）和 body（参数），而 json 不提供内置分界机制
• 标准 rpc/jsonrpc 包只是对 gob 编解码逻辑的重写，并非“用 encoding/json 替代 gob”——它仍遵循 RPC 帧格式约定

如何用 json 实现兼容标准 rpc.Client 的服务端？

使用 net/rpc/jsonrpc 是最轻量、最兼容的方式：它复用了标准 rpc 的注册与调用逻辑，仅替换底层编解码器。客户端无需改代码，只要把 rpc.NewClient 换成 jsonrpc.NewClient 即可。

服务端启动示例：

package main
import (
"net"
"net/rpc"
"net/rpc/jsonrpc"
)
type Args struct{ A, B int }
type Quotient struct{ Quo, Rem int }
type Arith int
func (t Arith) Multiply(args Args, reply int) error {
reply = args.A * args.B
return nil
}
func main() {
rpc.Register(new(Arith))
listener,  := net.Listen("tcp", ":1234")
for {
conn,  := listener.Accept()
go jsonrpc.ServeConn(conn) // ← 关键：用 jsonrpc.ServeConn 替代 rpc.ServeConn
}
}

注意点：

• 必须用 jsonrpc.ServeConn 启动连接，不能用 rpc.ServeConn
• 客户端必须用 jsonrpc.NewClient 或 jsonrpc.Dial，否则会因帧格式不匹配而报 invalid character 错误
• 结构体字段必须首字母大写（导出），且建议加 json: 标签以控制 key 名

如何用 protobuf + gRPC 替代原生 net/rpc？

如果你真正想要的是高性能、跨语言、带 IDL 的 RPC，不要硬改 net/rpc，直接用 gRPC-Go。它本质是基于 HTTP/2 的二进制 RPC 框架，protobuf 是其默认序列化协议，天然支持 streaming、拦截器、超时、认证等。

关键区别：

• net/rpc 是 TCP + 自定义二进制帧（gob）或 JSON 帧；gRPC 是 HTTP/2 + protobuf + gRPC-encoding（length-delimited）
• gRPC 要求先写 .proto 文件生成 Go 代码；net/rpc 直接注册结构体和方法
• 没有 gRPC 服务端，protobuf 只是序列化工具——你仍需自己设计传输层（比如用 net.Conn + 自定义分帧），这极易出错

所以，除非你有强约束（如必须复用现有 net/rpc 客户端、不能引入新协议栈），否则别尝试“给 net/rpc 换 protobuf 底层”。真要这么做，得完整实现 rpc.ServerCodec，包括：ReadRequestHeader 解析 method/service/seq，ReadRequestBody 用 proto.Unmarshal，还要处理 length-prefix framing——这已接近重写整个 RPC 栈。

自定义编解码器时最容易忽略的细节

当你实现自己的 rpc.ServerCodec，以下三点几乎必踩坑：

• TCP 是字节流，没有消息边界——必须自己加长度前缀（如 4 字节 uint32 表示后续 payload 长度），否则 ReadRequestBody 会阻塞或读错数据
• ReadRequestHeader 必须严格按 RPC 协议解析出 ServiceMethod 字符串（格式为 "Service.Method"）和 Seq（请求序号），漏掉任一字段会导致客户端永远收不到响应
• WriteResponse 的 err 参数不能忽略：如果业务逻辑返回 error，必须写入 response body 并设置 ErrorResponse 标志，否则客户端 Call 会卡死或 panic

真正稳定的自定义方案，往往不是从零写 ServerCodec，而是基于 gRPC 的 Codec 接口或 go-micro 的 codec 插件机制——它们已封装好分帧、上下文、错误传播等细节。