如何使用Golang实现微服务之间的RPC调用_Golang微服务RPC通信与实现技巧

选grpc还是jsON-RPC取决于场景：gRPC适合内部高一致性、高吞吐的go微服务链路；json-RPC或net/rpc更轻量，适合跨语言调试或Go运维工具。

用 gRPC 还是 JSON-RPC？选型直接决定调试成本

Go 微服务间 RPC 通信，gRPC 是默认首选，但不是所有场景都适合。如果你的服务要被 python/JS 客户端频繁调用、需要浏览器直连、或团队对 Protocol Buffers 不熟，JSON-RPC（配合 net/rpc 或 gorilla/rpc）反而更轻量、易 debug。

常见错误：用 gRPC 对接前端 fetch 请求，结果卡在 CORS 或 http/2 不兼容上；或者用 net/rpc 暴露服务却忘了它默认只支持 Go 客户端，其他语言根本连不上。

• gRPC 要求定义 .proto 文件，生成强类型 stub，适合内部高一致性、高吞吐服务（如订单→库存→支付链路）
• net/rpc 基于 Go 的 encoding/gob，仅限 Go-to-Go，启动快、无依赖，适合运维工具类微服务间短时通信
• 若需跨语言且拒绝 protobuf，可选 JSON-RPC 2.0 + gorilla/rpc，但注意它不自带服务发现和重试

gRPC Server 启动时 panic: “transport: http2Server.Handlestreams received bogus greeting”

这个错误基本等于客户端没按 HTTP/2 + TLS（或明文 h2c）规范发起连接。Go 的 grpc.Server 默认要求 TLS，但开发环境常想跳过证书——必须显式启用 h2c（HTTP/2 without TLS）。

正确做法不是关 TLS，而是用 grpc.Creds 配合 credentials.NewTLS(nil) 不够，得换底层 listener：

立即学习“go语言免费学习笔记（深入）”；

lis, _ := net.Listen("tcp", ":8080") // 关键：用 http2.ConfigureServer 包一层 s := &http2.Server{} grpcServer := grpc.NewServer(     grpc.ForceServerCodec(&codec{}), // 可选：自定义编解码 ) httpServer := &http.Server{     Addr:    ":8080",     Handler: h2c.NewHandler(grpcServer, &s), } httpServer.Serve(lis) // 而非 grpcServer.Serve(lis)

否则 curl 或 postman 直连会报上述错误；用 grpcurl 则必须加 -plaintext 参数。

net/rpc 注册方法名必须首字母大写且带接收者

net/rpc 对方法签名极其敏感：必须是导出方法（首字母大写），且第一个参数为指针或值类型，第二个必须是指针类型响应。漏掉任一条件，rpc.register 不报错，但客户端调用返回 "method not found"。

典型错误写法：

func (s *Service) processOrder(req OrderRequest, resp *OrderResponse) error { ... } // 小写 processOrder → 不可见 func (s *Service) ProcessOrder(req OrderRequest, resp OrderResponse) error { ... } // resp 不是指针 → 拒绝注册

正确写法：

func (s *Service) ProcessOrder(req *OrderRequest, resp *OrderResponse) error {     *resp = OrderResponse{ID: req.ID + "-done"}     return nil }

另外，net/rpc 默认用 gob 编码，不兼容其他语言；若强行传 JSON 字符串，需自定义 Codec，但代价是失去标准反射机制。

超时控制不能只靠 context.WithTimeout —— 底层连接也得设

RPC 调用中只在 client 端用 ctx, cancel := context.WithTimeout(ctx, 5*time.Second) 是不够的。gRPC 的底层 HTTP/2 连接可能因网络卡顿迟迟不建立，而 context 超时只作用于 RPC 方法调用阶段，不覆盖 dial 阶段。

必须显式配置 grpc.WithTimeout（已弃用）或更可靠的 grpc.WithTransportCredentials + 自定义 grpc.DialOption：

conn, err := grpc.Dial("127.0.0.1:8080",     grpc.WithTransportCredentials(insecure.NewCredentials()),     grpc.WithBlock(), // 同步阻塞等待连接成功     grpc.WithTimeout(3*time.Second), // 连接级超时（注意：gRPC v1.60+ 已移除此选项） ) // 替代方案：用 grpc.WithDialer + net.DialTimeout

实际项目中建议统一封装 dial 函数，把连接超时、keepalive、backoff 都固化进去，避免每个服务单独写重复逻辑。

真正难处理的是 streaming 场景：context 超时后，server 端 goroutine 可能还在跑，必须靠业务层主动检查 ctx.Done() 并提前 return，否则资源泄漏比 REST 更隐蔽。