Golang 如何实现一个简单的 RPC 框架

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《Golang 如何实现一个简单的 RPC 框架》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

因为net/rpc缺乏跨语言支持、服务发现、健壮超时与上下文取消、错误分类及panic恢复等生产必需能力，仅适用于学习或轻量内部通信。

为什么不用 net/rpc 直接上生产

net/rpc 是 Go 标准库自带的 RPC 实现，支持 JSON/GOB 编码和 HTTP/TCP 传输，但实际用起来会很快撞墙：它不支持跨语言调用、没有服务发现、超时控制弱（SetDeadline 需手动管理）、上下文取消基本靠自己套壳，而且错误信息藏在 rpc.ServerError 里，日志一打全是 rpc: failed to decode args 这种无意义提示。

所以「简单」不等于「直接用标准库跑通就行」，而是指：核心流程可控、关键点可插拔、不引入重量级依赖。下面的实现就基于这个原则。

如何用 gob + net 搭出最小可行 RPC 通信层

跳过所有中间件和注册中心，先让两个进程能互相发函数名+参数+拿到返回值。关键不是“多快”，而是“哪几行代码决定调用是否成立”。

服务端监听 TCP，接收连接后启动 goroutine 处理单次请求；客户端拨号、写入 gob.Encoder 编码后的结构体、读取响应。必须注意：

• gob 要求结构体字段首字母大写（导出），且类型必须可序列化（不能含 func、map[interface{}]interface{} 等）
• 每次请求/响应需严格配对：先写长度（4 字节 uint32），再写 gob 数据，否则解码会卡死或 panic
• 不要复用 gob.Encoder/Decoder 实例——它们不是并发安全的，每个连接应新建一对

示例片段（服务端处理逻辑）：

func handleConn(conn net.Conn) {
    defer conn.Close()
    dec := gob.NewDecoder(conn)
    enc := gob.NewEncoder(conn)
    var req struct {
        Method string
        Args   interface{}
    }
    if err := dec.Decode(&req); err != nil {
        return // 忽略错误，不返回
    }
    // 根据 req.Method 查找本地函数，反射调用...
    resp := invoke(req.Method, req.Args)
    enc.Encode(resp)
}

怎么让客户端调用看起来像本地函数

目标是写 user, err := client.GetUser(123)，而不是 client.Call("GetUser", 123, &user)。这需要生成桩（stub）——但不用代码生成工具，用 Go 的 reflect 在运行时动态包装。

核心思路：客户端持有一个 map[string]func(...interface{}) []interface{}，键是方法名，值是闭包，闭包里做三件事：把参数 encode 发出去、decode 响应、按顺序 unpack 到返回值切片。调用时用 reflect.ValueOf(fn).Call() 把用户传的参数转成 []reflect.Value。

容易漏掉的点：

• 返回值切片长度必须和函数声明一致，否则 Call() panic；如果函数返回 error，要额外检查最后一个返回值是否为 nil
• 客户端必须设置连接超时：net.DialTimeout("tcp", addr, 5*time.Second)，否则 DNS 卡住或服务宕机时会 hang 死
• 别在 stub 里做重试——重试逻辑属于调用方策略，stub 只负责一次尽力而为

哪些地方必须自己补，标准库完全不管

net/rpc 和上面手写的最小实现，都默认假设「连接稳定、服务一直在线、参数永远合法」。真实场景下这几块必须立刻补上：

• 连接池：TCP 连接不能每次 Dial 再 Close，要用 sync.Pool 缓存 *rpc.Client 或底层 net.Conn，否则压测时 fd 耗尽
• 超时透传：用户调用 GetUser(ctx, 123) 里的 ctx 必须能中断底层 gob.Decode ——但 gob 不接受 context.Context，得用 conn.SetReadDeadline 配合 timer 手动触发
• 错误分类：网络错误（net.OpError）、编码错误（gob.TypeError）、业务错误（自定义 error code）要分开展示，否则运维查问题全靠猜

最常被忽略的是服务端 panic 恢复。没加 defer func() { recover() }()，一个空指针就能让整个 RPC 服务退出。这不是健壮性问题，是可用性底线。

本篇关于《Golang 如何实现一个简单的 RPC 框架》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！