GolangRPC服务实现 net/rpc包案例-Golang-PHP中文网

答案：Go的net/rpc包通过gob序列化实现Go语言间简单高效的RPC通信，适用于内部服务交互。它使用标准库即可完成服务注册、TCP监听与调用，但仅限Go环境、缺乏跨语言支持与高级特性。

golangrpc服务实现 net/rpc包案例

在Go语言的世界里，实现RPC（远程过程调用）服务其实远没有想象中那么复杂，尤其是当你选择使用其内置的

net/rpc

登录后复制

包时。说白了，它就是让你可以像调用本地函数一样，去调用另一台机器上的函数，极大地简化了分布式系统的开发。

net/rpc

登录后复制

提供了一种非常直接、高效的方式来构建Go服务间的通信，尤其适用于纯Go环境下的内部服务交互。

解决方案

要实现一个基于

net/rpc

登录后复制

的RPC服务，核心在于定义好服务端可被调用的方法，然后在客户端通过网络连接去调用它们。

服务端实现：

定义服务结构体和方法： 创建一个普通的Go结构体，并为其定义方法。这些方法必须遵循

func (t *T) MethodName(args *ArgsType, reply *ReplyType) error

登录后复制

的签名。

ArgsType

登录后复制

和

ReplyType

登录后复制

可以是任何可被

gob

登录后复制

编码的类型（

net/rpc

登录后复制

默认使用

gob

登录后复制

进行数据序列化）。

package main

import (
    "log"
    "net"
    "net/rpc"
    "time"
)

// Arith 是一个算术服务
type Arith struct{}

// Args 是算术方法的参数
type Args struct {
    A, B int
}

// Multiply 方法用于计算乘积
func (t *Arith) Multiply(args *Args, reply *int) error {
    *reply = args.A * args.B
    log.Printf("Server received Multiply(%d, %d), returning %d", args.A, args.B, *reply)
    return nil
}

// Divide 方法用于计算除法
func (t *Arith) Divide(args *Args, reply *float64) error {
    if args.B == 0 {
        return rpc.ErrShutdown // 模拟一个错误
    }
    *reply = float64(args.A) / float64(args.B)
    log.Printf("Server received Divide(%d, %d), returning %.2f", args.A, args.B, *reply)
    return nil
}

func main() {
    arith := new(Arith)
    rpc.Register(arith) // 注册服务实例，服务名为 "Arith"

    // 也可以使用 rpc.RegisterName("MyArithService", arith) 来指定服务名

    listener, err := net.Listen("tcp", ":1234")
    if err != nil {
        log.Fatalf("Listen error: %v", err)
    }
    log.Println("RPC server listening on :1234")

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Printf("Accept error: %v", err)
            // 实际应用中可能需要更复杂的错误处理，比如重试或退出
            time.Sleep(time.Second) // 避免CPU空转
            continue
        }
        go rpc.ServeConn(conn) // 为每个连接启动一个 goroutine 处理RPC请求
    }
}

登录后复制

客户端实现：

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

连接RPC服务： 使用
```
rpc.Dial
```
登录后复制
或
```
rpc.DialHTTP
```
登录后复制
连接到RPC服务端。

调用远程方法： 通过

client.Call("ServiceName.MethodName", args, &reply)

登录后复制

来调用远程方法。

package main

import (
    "fmt"
    "log"
    "net/rpc"
    "time"
)

// Args 结构体需要和服务端定义的一致
type Args struct {
    A, B int
}

func main() {
    // 尝试连接RPC服务，如果连接不上，会重试几次
    var client *rpc.Client
    var err error
    for i := 0; i < 5; i++ {
        client, err = rpc.Dial("tcp", "localhost:1234")
        if err == nil {
            log.Println("Successfully connected to RPC server.")
            break
        }
        log.Printf("Failed to connect to RPC server, retrying in 2 seconds... (%v)", err)
        time.Sleep(2 * time.Second)
    }

    if err != nil {
        log.Fatalf("Could not connect to RPC server after multiple retries: %v", err)
    }
    defer client.Close()

    // 调用 Multiply 方法
    argsMultiply := Args{7, 8}
    var replyMultiply int
    err = client.Call("Arith.Multiply", argsMultiply, &replyMultiply)
    if err != nil {
        log.Fatalf("Arith.Multiply error: %v", err)
    }
    fmt.Printf("Arith: %d * %d = %d\n", argsMultiply.A, argsMultiply.B, replyMultiply)

    // 调用 Divide 方法
    argsDivide := Args{10, 3}
    var replyDivide float64
    err = client.Call("Arith.Divide", argsDivide, &replyDivide)
    if err != nil {
        log.Fatalf("Arith.Divide error: %v", err)
    }
    fmt.Printf("Arith: %d / %d = %.2f\n", argsDivide.A, argsDivide.B, replyDivide)

    // 尝试一个会出错的调用
    argsDivideByZero := Args{10, 0}
    var replyDivideByZero float64
    err = client.Call("Arith.Divide", argsDivideByZero, &replyDivideByZero)
    if err != nil {
        fmt.Printf("Arith.Divide (by zero) error: %v\n", err) // 预期会报错
    } else {
        fmt.Printf("Arith: %d / %d = %.2f (unexpected success)\n", argsDivideByZero.A, argsDivideByZero.B, replyDivideByZero)
    }
}

登录后复制

net/rpc

登录后复制

与 gRPC 等框架有何不同？为什么它仍然值得关注？

在我看来，

net/rpc

登录后复制

就像Go语言标准库里一个被低估的宝藏。它简单、直接，而且是Go原生支持的。它与gRPC这些“重型”框架最显著的区别在于：

协议与序列化：
```
net/rpc
```
登录后复制
默认使用Go的
```
gob
```
登录后复制
编码，这意味着它天生就是为Go语言环境设计的。数据传输基于TCP或HTTP，但内部的序列化是Go特有的。而gRPC则基于HTTP/2协议，使用Protocol Buffers作为其默认的接口定义语言（IDL）和序列化机制。这让gRPC拥有跨语言的强大能力，你用Go写的服务可以很方便地被Java、Python等其他语言的客户端调用。
```
net/rpc
```
登录后复制
在这方面就显得“偏科”了，它更适合纯Go系统内部的通信。
特性集： gRPC提供了更丰富的功能，比如流式RPC（客户端流、服务端流、双向流）、拦截器（middleware）、更完善的错误码机制、负载均衡、服务发现的集成等等。
```
net/rpc
```
登录后复制
就显得“裸奔”多了，很多高级特性需要你自己去实现或集成第三方库。比如，你想要一个请求超时机制，
```
net/rpc
```
登录后复制
本身没有，你得在客户端调用时用
```
context.WithTimeout
```
登录后复制
包裹。
复杂度和学习曲线： 毫无疑问，
```
net/rpc
```
登录后复制
的学习曲线几乎是平的，你只需要理解几个函数调用和方法签名就行。gRPC则需要你学习Protocol Buffers语法、代码生成、各种流式模型，初期上手门槛相对高一些。

那么，为什么

net/rpc

登录后复制

仍然值得关注呢？很简单，它够用且足够快。 对于许多内部服务、微服务之间的Go-to-Go通信，或者当你不需要复杂的跨语言互操作性、不需要流式传输时，

net/rpc

登录后复制

简直是最佳选择。它减少了引入额外依赖的复杂性，编译出来的二进制文件更小，部署也更简单。在我过去的经验里，很多时候我们追求“最新最酷”的技术，却忽略了“最适合”的才是最好的。当你发现一个简单的需求被gRPC的复杂性压得喘不过气时，回过头来看看

net/rpc

登录后复制

，你会发现它真的“香”。

net/rpc

登录后复制

服务端与客户端的核心实现细节是什么？

要深入理解

net/rpc

登录后复制

，我们需要看它在底层是如何工作的，以及它对我们代码有哪些约束。

服务端核心细节：

服务注册： 这是服务端最关键的一步。通过
```
rpc.Register(receiver interface{})
```
登录后复制
或
```
rpc.RegisterName(name string, receiver interface{})
```
登录后复制
，你将一个Go对象的方法暴露为RPC服务。
- ```
rpc.Register(arith)
```
  登录后复制
  ：默认会使用类型名（
```
Arith
```
  登录后复制
  ）作为服务名。
- ```
rpc.RegisterName("MyCalculator", arith)
```
  登录后复制
  ：允许你自定义服务名，这在你有多个相同类型的服务实例，或者想给服务一个更友好的名字时很有用。
- 方法签名要求： 只有符合特定签名的方法才会被注册：
  - 必须是导出的方法（首字母大写）。
  - 方法必须有两个导出类型的参数。
  - 第二个参数必须是指针类型。
  - 方法必须返回一个
```
error
```
    登录后复制
    类型。
  - 例如：
```
func (t *T) Method(args *ArgsType, reply *ReplyType) error
```
    登录后复制
- 为什么是这样？
```
args
```
  登录后复制
  用于接收客户端的请求数据，
```
reply
```
  登录后复制
  用于存放方法执行结果并返回给客户端，
```
error
```
  登录后复制
  则用于指示方法执行过程中是否出错。这种设计非常Go-idiomatic。
网络监听：
```
net.Listen("tcp", ":port")
```
登录后复制
是Go标准库的网络监听方式，它创建一个监听器，等待客户端连接。
连接处理：
- ```
listener.Accept()
```
  登录后复制
  ：接受一个传入的连接。
- ```
rpc.ServeConn(conn)
```
  登录后复制
  ：这是
```
net/rpc
```
  登录后复制
  的核心。它会在一个独立的goroutine中处理这个TCP连接上的所有RPC请求。
```
ServeConn
```
  登录后复制
  会持续读取连接上的数据，解析RPC请求，调用对应的服务方法，并将结果写回连接。如果连接关闭或者发生错误，
```
ServeConn
```
  登录后复制
  就会退出。
- HTTP传输：
```
net/rpc
```
  登录后复制
  也支持通过HTTP传输RPC请求，这在某些场景下（例如，穿越防火墙）可能更方便。你需要使用
```
rpc.HandleHTTP()
```
  登录后复制
  注册RPC的HTTP处理函数，然后像普通的HTTP服务一样启动
```
http.ListenAndServe
```
  登录后复制
  。客户端则使用
```
rpc.DialHTTP
```
  登录后复制
  来连接。这种方式实际上是在HTTP请求体中承载了
```
gob
```
  登录后复制
  编码的RPC数据。

客户端核心细节：

豆包爱学

豆包旗下AI学习应用

674

查看详情

建立连接：
- ```
rpc.Dial("tcp", "host:port")
```
  登录后复制
  ：建立一个TCP连接并返回一个
```
*rpc.Client
```
  登录后复制
  实例。
- ```
rpc.DialHTTP("tcp", "host:port")
```
  登录后复制
  ：用于连接通过HTTP暴露的RPC服务。
- 异步连接：
```
rpc.Dial
```
  登录后复制
  和
```
rpc.DialHTTP
```
  登录后复制
  是阻塞的，直到连接建立或失败。在生产环境中，你可能需要实现重试逻辑，或者使用连接池来管理多个客户端连接。
方法调用：
- ```
client.Call("ServiceName.MethodName", args, &reply)
```
  登录后复制
  ：这是客户端发起RPC调用的核心方法。
  - ```
  "ServiceName.MethodName"
```
  登录后复制
  ：字符串形式的服务名和方法名组合。这要求你在服务端注册时要么使用默认类型名，要么使用
```
  RegisterName
```
  登录后复制
  指定。
- ```
args
```
    登录后复制
    ：传递给远程方法的参数，必须是可
```
gob
```
    登录后复制
    编码的类型。
  - ```
  &reply
```
  登录后复制
  ：用于接收远程方法返回结果的指针，同样必须是可
```
  gob
```
  登录后复制
  编码的类型。
- 阻塞调用：
```
  Call
```
  登录后复制
  方法是阻塞的，它会等待远程方法执行完毕并返回结果。
- 异步调用： 如果你需要非阻塞调用，可以使用
```
client.Go("ServiceName.MethodName", args, &reply, ch)
```
  登录后复制
  。它会返回一个
```
*rpc.Call
```
  登录后复制
  对象，你可以通过检查
```
Call.Done
```
  登录后复制
  通道来获取异步调用的结果和错误。
错误处理：
```
Call
```
登录后复制
方法会返回一个
```
error
```
登录后复制
。这个错误可能是网络错误（连接断开、超时等），也可能是远程方法返回的错误。服务端方法返回的
```
error
```
登录后复制
会被序列化并通过网络传输到客户端。

理解这些细节，特别是方法签名和

gob

登录后复制

编码，对于正确使用

net/rpc

登录后复制

至关重要。它不像一些框架那样帮你隐藏了所有底层细节，而是提供了一个相对透明但又足够方便的抽象层。

在实际项目中，

net/rpc

登录后复制

可能面临哪些挑战和限制？

尽管

net/rpc

登录后复制

在某些场景下非常实用，但在实际的生产环境中，它确实存在一些局限性，可能会成为你选择其他RPC框架的理由。

跨语言兼容性差： 这是最大的限制。由于默认使用
```
gob
```
登录后复制
编码，
```
net/rpc
```
登录后复制
几乎只能用于Go服务之间的通信。如果你有一个异构系统，比如前端用JavaScript，后端用Go，或者需要与其他语言（Java, Python等）的服务进行通信，那么
```
net/rpc
```
登录后复制
就力不从心了。这时，gRPC（Protocol Buffers）、Thrift或RESTful API会是更好的选择。
缺乏高级特性：
- 没有内置的流式RPC： 无法像gRPC那样方便地实现客户端流、服务端流或双向流。如果你需要长时间连接并持续发送/接收数据（例如，实时数据推送、聊天应用），
```
net/rpc
```
  登录后复制
  会显得笨拙。
- 没有内置的拦截器/中间件： 你无法像gRPC那样通过拦截器统一处理日志、认证、限流、熔断等横切关注点。你需要手动在每个服务方法内部实现这些逻辑，或者在
```
ServeConn
```
  登录后复制
  的外部包裹一层。
- 没有内置的负载均衡和服务发现：
```
net/rpc
```
  登录后复制
  客户端需要知道服务端的具体地址。在微服务架构中，服务实例是动态变化的，你需要额外集成如Consul、Etcd或Kubernetes等服务发现机制，并在客户端实现负载均衡策略。
- 错误码不够丰富： 默认只返回一个
```
error
```
  登录后复制
  接口，不像gRPC有丰富的状态码和详细信息。这使得错误处理和排查在某些情况下不够精细。
协议限制： 默认使用TCP或HTTP/1.1。它不直接支持HTTP/2，这意味着你无法利用HTTP/2的多路复用、头部压缩等特性，这在高性能和低延迟场景下可能是一个劣势。
接口定义和版本管理：
```
net/rpc
```
登录后复制
没有IDL，这意味着服务接口的定义完全依赖于Go代码本身。当服务接口发生变化时（例如，参数增减、类型修改），客户端和服务端需要严格同步更新，否则会导致序列化错误或运行时错误。这在大型项目或多团队协作时，可能成为一个版本管理的噩梦。相比之下，gRPC的Protocol Buffers提供了一个清晰的契约，可以方便地进行版本管理和兼容性检查。
安全性：
```
net/rpc
```
登录后复制
本身不提供加密传输（TLS/SSL）或身份验证机制。在生产环境中，你需要手动在TCP连接层添加TLS，或者在应用层实现认证授权逻辑。

总的来说，

net/rpc

登录后复制

更像是一个“瑞士军刀”中的基础刀片，它锋利、直接，但缺少其他专业工具的辅助功能。它最适合用于那些对Go生态系统深度绑定、对性能有一定要求、且功能需求相对简单的内部服务。一旦你的项目开始走向异构、复杂，或者对高级特性有强烈需求时，你会发现它力不从心，这时候，就是考虑gRPC或其他更强大的RPC框架的时候了。选择工具，永远是根据场景来定，没有银弹。

以上就是GolangRPC服务实现 net/rpc包案例的详细内容，更多请关注php中文网其它相关文章！