如何在Golang中实现RPC调用_RPC调用流程与实现方式

最简 net/rpc 调用需服务端用 rpc.RegisterName("Arith", new(Arith)) 注册、监听 TCP 并 Accept，客户端用 client.Call("Arith.Multiply", &args, &reply)；方法签名必须为 func(T, Arg, *Reply) error，且字段全导出。

Go 标准库 net/rpc 怎么跑通一个最简调用

标准库的 net/rpc 默认基于 HTTP 或 TCP 传输，使用 Go 自带的 gob 编码。它不依赖外部框架，但要求服务端和客户端类型定义严格一致，且只支持导出（首字母大写）的方法。

关键约束：func (t *T) MethodName(argType *Arg, replyType *Reply) error 必须满足：接收者是指针、两个参数都是指针、返回 error。

• 服务端注册时必须用 rpc.RegisterName("MyService", &MyService{}) 显式命名，否则客户端无法按名查找
• 客户端连接后要先调用 client.Call("MyService.MethodName", &arg, &reply)，方法名是 "服务名.方法名" 字符串，不是反射自动推导
• 如果服务端没监听或客户端 dial 超时，Call 会直接返回 rpc: no such service 类错误，不是网络层错误 —— 这说明服务未注册或名称不匹配，不是连不上

package main
import (
"net/rpc"
"net"
"log"
)
type Args struct{ A, B int }
type Reply struct{ Result int }
type Arith int
func (t Arith) Multiply(args Args, reply Reply) error {
reply.Result = args.A  args.B
return nil
}
func main() {
rpc.RegisterName("Arith", new(Arith))
listener, _ := net.Listen("tcp", ":1234")
rpc.Accept(listener)
}

为什么用 jsonrpc 替代默认 gob 编码

gob 是 Go 专属二进制格式，跨语言调用完全不可行；而 jsonrpc 协议天然兼容 Python、Node.js、curl 等任意能发 HTTP POST 的客户端。Go 标准库提供了 net/rpc/jsonrpc 包，只需替换连接建立方式。

• 服务端仍用 rpc.Register，但监听后需用 jsonrpc.ServeConn(conn) 处理单个连接，或包装成 HTTP handler
• 客户端不能直接用 rpc.Dial，得用 jsonrpc.Dial("tcp", "localhost:1234")
• HTTP 场景下，建议用 http.Serve + rpc.HTTPHandler 暴露 /rpc 端点，此时客户端可用 curl -X POST -H "Content-Type: application/json" --data '{"method":"Arith.Multiply","params":[{"A":3,"B":4}],"id":1}' http://localhost:8080/rpc

rpc.Client.Call 返回 rpc: can't find method 怎么排查

这个错误和网络无关，只表示服务端没找到对应方法。常见原因不是拼写错，而是结构体字段未导出或参数类型不匹配。

• 检查 Args 和 Reply 中所有字段是否首字母大写（如 A int ✅，a int ❌）
• 确认客户端传入的 args 是指针，且类型与服务端签名中声明的 *Args 完全一致（包括包路径，比如 myproj.Args 和 main.Args 视为不同类型）
• 服务端若用 rpc.Register(&MyService{})，则方法名前缀是 MyService.MethodName；若用 rpc.RegisterName("X", &MyService{})，则必须用 X.MethodName
• 如果服务端重启过但客户端复用旧 *rpc.Client，可能因底层连接断开导致后续调用静默失败 —— 建议每次调用前检查 client.Go 的返回值或封装重连逻辑

生产环境为什么不推荐裸用 net/rpc

它缺少超时控制、上下文传播、中间件、服务发现、负载均衡等现代 RPC 必备能力。例如 client.Call 没有 context.Context 参数，无法主动取消；也没有内置重试或熔断。

• 超时只能靠底层连接设置（如 net.DialTimeout），但业务逻辑超时无法单独控制
• 日志、鉴权、链路追踪需手动在每个方法里加，无法统一拦截
• 服务部署多个实例时，客户端得自己维护节点列表并做轮询 —— 标准库不提供服务注册/发现机制
• 真正落地的项目基本都转向 gRPC（基于 HTTP/2 + Protocol Buffers）或轻量方案如 kitex、kratos，它们把序列化、传输、错误码、元数据都标准化了

如果只是内部小工具或 PoC，net/rpc 足够快；但只要

涉及稳定性、可观测性或跨团队协作，就得接受它只是一个教学级参考实现。