Go rpc.Server.ServeCodec 怎么接入自定义消息编码

Go 的 net/rpc 默认通过 ServeConn 使用 gob 编码。如果客户端已经约定了 JSON、长度前缀或其他二进制协议，服务端不需要重写 RPC 方法分发，只要实现 rpc.ServerCodec，再把它交给 server.ServeCodec 即可。关键是把“拆帧”和“RPC 语义”分开：codec 负责读写消息，net/rpc 负责校验请求、调用方法和组织响应。

一、先确定 ServeCodec 接管的边界

ServeConn 会替你创建 gob codec；ServeCodec 则把编解码责任交给传入对象。官方接口要求四个方法：ReadRequestHeader、ReadRequestBody、WriteResponse 和 Close。服务端读取请求头和请求体后，仍然按照已经注册的服务方法执行；因此自定义编码只改变线上消息格式，不改变 Go 方法签名或注册方式。

下面选一个容易和其他语言对接的约定：每条消息由四字节大端长度和 JSON 负载组成。请求头包含 service_method 与 seq，请求体单独编码；响应沿用 seq，错误文本放入 error。这只是示例协议，生产环境还应增加最大帧长、版本字段和超时策略。

二、用长度前缀实现可拆帧的 codec

实现时可以让 ReadRequestHeader 先读完整帧并缓存请求体，让紧随其后的 ReadRequestBody 只负责把缓存内容解码到参数对象。这样既遵守 net/rpc 的调用顺序，也不会把 TCP 粘包误当成一个请求。

package customrpc

import (
    "encoding/binary"
    "encoding/json"
    "fmt"
    "io"
    "net"
    "net/rpc"
    "sync"
)

type envelope struct {
    ServiceMethod string          `json:"service_method,omitempty"`
    Seq           uint64          `json:"seq"`
    Body          json.RawMessage `json:"body,omitempty"`
    Error         string          `json:"error,omitempty"`
}

type Codec struct {
    conn      net.Conn
    pending   json.RawMessage
    writeLock sync.Mutex // RPC 方法并发返回时，保证一帧完整写出
}

func NewCodec(conn net.Conn) *Codec { return &Codec{conn: conn} }

func (c *Codec) readFrame() ([]byte, error) {
    var size uint32
    if err := binary.Read(c.conn, binary.BigEndian, &size); err != nil {
        return nil, err
    }
    if size == 0 || size > 4 uint64(^uint32(0)) { return fmt.Errorf("frame too large") }
    if err := binary.Write(c.conn, binary.BigEndian, uint32(len(payload))); err != nil { return err }
    _, err = c.conn.Write(payload)
    return err
}

func (c *Codec) Close() error { return c.conn.Close() }

这里的 pending 只适用于单连接上按顺序读取请求的服务端 codec；ServeCodec 本身由一个读取循环串行调用这两个读方法，而业务方法可以并发执行。响应侧必须加锁，这是接口契约里的并发边界。

三、把 codec 接到自定义 Server

服务端注册普通 RPC 接收者后，接收连接并调用 ServeCodec。示例中的服务方法没有任何自定义协议代码，说明编码层已经和业务层解耦。

type Math struct{}

func (Math) Add(args struct{ A, B int }, reply *int) error {
    *reply = args.A + args.B // 业务方法只处理已解码的参数
    return nil
}

func serve(conn net.Conn) error {
    server := rpc.NewServer()
    if err := server.RegisterName("Math", new(Math)); err != nil {
        return err // 注册失败时不要启动半成品连接
    }
    server.ServeCodec(NewCodec(conn)) // ServeCodec 返回后 codec 已被关闭
    return nil
}

ServeCodec 会持续读请求；遇到不能继续读取的错误后，等待已经启动的 RPC 响应发送完毕，再调用 Close。因此不要在外层和 codec 内部重复关闭连接，也不要把 ServeRequest 当成长连接循环：它只同步处理一条请求，而且官方说明它不会替调用方关闭 codec。

四、客户端协议和上线边界

自定义服务端只能解决一半问题。客户端必须使用完全相同的长度字节序、JSON 字段名、Seq 关联方式和错误表示；如果客户端仍使用 gob 的 rpc.NewClient，两端会在第一帧就无法互相理解。跨语言场景通常需要同时实现客户端 codec，或改用已经定义清楚的 HTTP/JSON、Protobuf 等协议。

上线前至少固定三项边界：单帧最大长度，读取和写入超时，以及协议版本兼容策略。解析失败要返回明确 RPC 错误并关闭不可恢复的连接；对于可丢弃的非法 body，应确保读取循环仍能落在下一条帧边界上。

常见问题

ServeCodec 和 ServeConn 能同时调用吗？

可以分别服务不同连接，但同一连接只能选择一种 codec。ServeConn 是 gob 默认路径，ServeCodec 是自定义路径。

为什么 WriteResponse 必须加互斥锁？

服务方法会并发执行，多个响应可能同时返回。没有锁时长度前缀和 JSON 字节可能交错，客户端即使拿到正确 Seq 也无法拆帧。

ReadRequestBody 收到 nil 需要怎么办？

按接口语义把当前 body 读出并丢弃，同时清空缓存，避免下一次请求复用旧参数；示例中的 nil 分支就是这个用途。