首先使用Go原生net/rpc实现基础RPC，服务端注册Calculator服务并监听TCP连接，客户端通过Dial调用远程方法；接着采用gRPC实现跨语言RPC，定义proto文件生成代码，支持强类型、流式调用与多语言互通；再集成etcd或Consul实现服务注册与发现，结合gRPC负载均衡机制应对实例动态变化；最后通过Interceptor添加日志、认证等中间件，提升系统可观测性与安全性。
在分布式系统中，RPC（Remote Procedure Call）是服务间通信的核心机制。Golang凭借其高效的并发模型和简洁的网络编程能力，非常适合实现分布式RPC调用。下面介绍如何使用Go原生net/rpc包结合HTTP或自定义协议，以及借助第三方库如gRPC来实现分布式RPC调用。
使用Go原生net/rpc实现基础RPC
Go标准库中的net/rpc支持基于GOB编码的RPC通信，适合内部服务间调用。
服务端实现：
package mainimport ( "log" "net" "net/rpc" )
type Args struct { A, B int }
type Calculator int
立即学习“go语言免费学习笔记（深入）”；
func (c Calculator) Multiply(args Args, reply int) error { reply = args.A args.B return nil }
func main() { calc := new(Calculator) rpc.Register(calc) listener, := net.Listen("tcp", ":8080") for { conn, := listener.Accept() go rpc.ServeConn(conn) } }
客户端调用：
package mainimport ( "fmt" "log" "net/rpc" )
func main() { client, err := rpc.Dial("tcp", "localhost:8080") if err != nil { log.Fatal("连接失败:", err) } args := Args{4, 5} var reply int err = client.Call("Calculator.Multiply", args, &reply) if err != nil { log.Fatal("调用失败:", err) } fmt.Printf("结果: %d\n", reply) }
这种方式简单直接，但仅限于Go语言之间通信，且缺乏跨语言支持和高级特性。
使用gRPC实现跨语言分布式RPC
gRPC是Google开源的高性能RPC框架，支持多语言，基于HTTP/2和Protocol Buffers，更适合生产级分布式系统。
步骤如下：
- 定义.proto文件描述服务接口和消息结构
- 使用protoc生成Go代码
- 实现服务端逻辑
- 客户端发起远程调用
示例proto文件（calculator.proto）：
syntax = "proto3"; package main;service Calculator { rpc Multiply (Args) returns (Result); }
message Args { int32 a = 1; int32 b = 2; }
message Result { int32 value = 1; }
使用protoc --go_out=plugins=grpc:. calculator.proto生成代码。
gRPC服务端：
注册并启动gRPC服务器，监听指定端口。
gRPC客户端：
通过grpc.Dial连接服务端，调用生成的客户端方法。
gRPC优势包括强类型接口、自动编解码、流式调用、超时控制、负载均衡等，适合复杂分布式架构。
集成服务发现与负载均衡
在真实分布式环境中，服务实例动态变化，需引入服务注册与发现机制。
常见方案：
- 使用etcd或Consul作为注册中心
- 服务启动时向注册中心上报地址
- 客户端通过查询注册中心获取可用节点
- 结合gRPC的balancer实现负载均衡
例如，将gRPC客户端连接目标设为注册中心管理的服务名，由resolver解析实际地址列表。
添加中间件增强功能
在RPC调用链中可加入日志、监控、认证、限流等中间件。
gRPC通过Interceptor机制支持：
- UnaryInterceptor用于普通调用
- StreamInterceptor用于流式通信
例如记录每次调用耗时，或验证请求token。
基本上就这些。从简单的net/rpc到生产级gRPC，Golang提供了灵活的工具链来构建可靠的分布式RPC系统。选择哪种方式取决于是否需要跨语言、性能要求和运维复杂度。不复杂但容易忽略的是错误处理和服务治理细节。
