Go语言RPC服务搭建教程

Go标准库的net/rpc虽可快速搭建轻量级内部服务，但因其仅支持同构Go环境、缺乏跨语言能力、无内置超时/重试/熔断/指标等生产级特性，且存在连接泄漏风险、错误处理薄弱、编码格式受限（默认仅gob）、HTTP传输不兼容REST、JSON-RPC支持需手动配置等严重短板，**根本不适合真实生产环境**；一旦涉及高并发、TLS、负载均衡、服务发现或跨语言调用，应立即转向gRPC、Twirp等成熟框架——硬扛net/rpc不仅徒增维护成本，更会埋下静默故障、接口契约失控和错误分类失效等隐患。

Go 的 net/rpc 能不能直接用在生产环境？

不能，除非你控制全部客户端和服务端，且不跨语言、不需高并发、不碰 TLS 或负载均衡。它设计初衷是「同构 Go 系统内部轻量通信」，不是通用 RPC 框架。

常见错误现象：rpc: client protocol error、连接突然断开后不重试、http: response.WriteHeader on hijacked connection（用 HTTP 传输时）、结构体字段没导出导致序列化为空。

• 只支持 gob 编码，默认无 JSON 支持（得自己注册 jsonrpc 服务）
• 服务端方法签名必须严格为 func(*T, *S) error，参数和返回值都得是指针，且类型必须可被 gob 编码
• 没有内置超时、重试、熔断、指标暴露，连日志都要自己塞进 handler
• HTTP transport 是“伪 HTTP”——它复用了 http.Server 但绕过路由，所有请求都打到固定路径 /rpc，跟 REST 完全不兼容

怎么让 net/rpc 支持 JSON 调用？

用 jsonrpc.NewServer() 替换默认的 rpc.NewServer()，再手动挂载到 HTTP handler；否则客户端发 JSON 请求，服务端会直接报 invalid request。

使用场景：前端调试、curl 测试、或已有简单 JSON 接口需求，但不想引入 gRPC 或 Gin。

• 服务端要显式调用 server.RegisterName("MyService", &myService{})，名字必须和客户端请求里的 service/method 匹配（如 MyService.Add）
• 客户端得用 jsonrpc.Dial("tcp", "localhost:8080")，不能用 rpc.Dial —— 后者只认 gob
• JSON 请求体格式必须是标准 JSON-RPC 2.0：包含 jsonrpc、method、params、id 字段，少一个就 400
• 注意：Go 标准库的 jsonrpc 不支持通知（notification），id 为 null 会直接忽略

net/rpc 的连接管理为什么容易泄漏？

因为 rpc.Server 本身不持有 listener，也不管理 conn 生命周期；你用 http.Serve 或 listener.Accept() 启动后，每个连接由底层 net.Conn 自行处理，一旦客户端异常断开，服务端可能卡在 conn.Read 上，goroutine 积压。

性能影响：1000 并发连接可能对应 1000+ 阻塞 goroutine，内存和 fd 持续上涨。

• 必须给 listener 设置 SetDeadline 或用 net.ListenConfig{KeepAlive: 30 * time.Second}
• HTTP transport 下，别直接传 http.Server{Handler: server}，要用 http.HandlerFunc 包一层，确保每次请求都走新 goroutine 且可设超时
• 客户端侧也要设 config.Timeout，否则 client.Call 可能永久阻塞
• 没有连接池 —— 每次 rpc.Dial 都建新 TCP 连接，高频调用务必自己封装复用逻辑

什么时候该果断放弃 net/rpc？

当你需要任意一项：跨语言调用、流式响应、服务发现、自动重试、OpenAPI 文档、TLS 双向认证、或哪怕只是把 RPC 方法映射成 REST 路径（如 POST /v1/add）。

这时候继续硬刚 net/rpc，花半天写的中间层代码，不如直接切到 gRPC-Go 或 Twirp，它们生成代码、协议定义、工具链都更稳。

• gRPC 的 .proto 文件天然约束接口契约，而 net/rpc 的结构体字段增减毫无提示，客户端一升级就静默失败
• HTTP/2 底层让 gRPC 天然支持 header、trailer、cancel、deadline，net/rpc 连 context.Context 都得靠参数透传
• 即使只是想“快速跑通”，用 kratos 或 kitex 的脚手架也比手搓 rpc.Register + http.Serve 更少出错

真正容易被忽略的是错误传播方式：net/rpc 把所有 error 都转成字符串塞进 response，客户端没法区分是业务错误还是网络错误，也没法做 typed error 处理 —— 这点在重试策略里会直接踩坑。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。