什么是 RPC

RPC(Remote Procedure Call),即远程过程调用,它允许像调用本地服务一样调用远程服务。是一种服务器-客户端(Client/Server)模式。

  • 远程:指的是需要经过网络的,而不是应用内部、机器内部进行的。
  • 过程:也就是方法。

那“远程过程调用”,就是:可以跨过一段网络,调用另外一个网络节点上的方法。以上就是对远程过程调用的简单理解。

RPC 调用分以下两种:

  1. 同步调用:客户方等待调用执行完成并返回结果。
  2. 异步调用:客户方调用后不用等待执行结果返回,但依然可以通过回调通知等方式获取返回结果。 若客户方不关心调用返回结果,则变成单向异步调用,单向调用不用返回结果。

异步和同步的区分在于是否等待服务端执行完成并返回结果。

RPC 基本原理

RPC核心功能

知道什么是RPC以后就会发现,RPC需要解决一些问题:

  1. 既然是远程调用,那么客户端如何知道服务端的地址?
  2. 如果客户端和服务端使用的是不同语言写的程序,那么参数该如何表达和解析?
  3. 如何进行网络传输?

这三个问题的解决方案也是RPC的核心功能:服务寻址、数据编解码和网络传输。

服务寻址

如果是本地调用,被调用的方法在同一个进程内,操作系统或者是虚拟机可以去地址空间去找;但是在远程调用中,这是行不通的,因为两个进程的地址空间是完全不一样的,肯定也无法知道远端的进程在那。

如果要想实现远程调用,我们需要对服务消费者和服务提供者两者进行约束:在远程过程调用中所有的函数都必须有一个 ID,这个 ID 在整套系统中是唯一存在确定的。服务消费者在做远程过程调用时,发送的消息体中必须要携带这个 ID。服务消费者和服务提供者分别维护一个函数和 ID 的对应表。当服务消费者需要进行远程调用时,它就查一下这个表,找出对应的 ID,然后把它传给服务端,服务端也通过查表,来确定客户端需要调用的函数,然后执行相应函数的代码就行。

服务寻址的实现方式有很多种,常见的是:服务注册中心。要调用服务,首先你需要一个服务注册中心去查询对方服务都有哪些实例,然后根据负载均衡策略择优选一。

服务注册
  1. 从服务提供者的角度看:当提供者服务启动时,需要自动向注册中心注册服务;当提供者服务停止时,需要向注册中心注销服务;提供者需要定时向注册中心发送心跳。如果一段时间未收到来自提供者的心跳后,注册中心会判定提供者已经停止服务,并从注册中心下架对应的服务。
  2. 从调用者的角度看:调用者启动时订阅注册中心的消息并从注册中心获取提供者的地址;当有提供者上线或者下线时,注册中心会告知到调用者;调用者下线时,取消订阅。

数据编解码

对计算机网络稍微有一点熟悉的同学都知道,数据在网络中传输都是二进制的:01010101010101010,类似这种,只有二进制数据才能在网络间传。选择好的序列化协议特别重要,一个好的序列化协议能减少序列化数据带来的性能损耗。常见的RPC序列化协议如下:

  • XML(Extensible Markup Language)是一种常用的序列化和反序列化协议,具有跨机器,跨语言等优点。狭义web service就是基于SOAP消息传递协议(一个基于XML的可扩展消息信封格式)来进行数据交换的。

  • JSON(Javascript Object Notation)起源于弱类型语言Javascript, 是采用"Attribute-value"的方式来描述对象协议。与XML相比,其协议比较简单,解析速度比较快。

  • Protocol Buffers 是google提供的一个开源序列化框架,是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。同 XML 相比, Protobuf 的主要优点在于性能高。它以高效的二进制方式存储,比 XML 小 3 到 10 倍,快 20 到 100 倍。

以上每种协议都有其优点和适用场景,需要根据具体的需求和环境来选择合适的协议。

网络传输

提起网络传输大家脑海里肯定马上就能想到 TCP/IP四层模型、OSI 七层模型,那通常 RPC 会选择那一层作为传输协议呢?

在回答这个问题前,先来看下 RPC 需要网络传输实现什么样的功能。客户端的数据经过序列化后,就需要通过网络传输到服务端。网络传输层需要把前面说的函数 ID 和序列化后的参数字节流传给服务端,服务端处理完然后再把序列化后的调用结果传回客户端。

原则上只要能实现上面这个功能的都可以作为传输层来使用,具体协议没有限制。我们先来看下 TCP 协议,TCP 连接可以是按需连接,需要调用的时候就先建立连接,调用结束后就立马断掉,也可以是长连接,客户端和服务器建立起连接之后保持长期持有,不管此时有无数据包的发送,可以配合心跳检测机制定期检测建立的连接是否存活有效。

由此可见 TCP 的性能确实很好,因此市面上大部分 RPC 框架都使用 TCP 协议,但也有少部分框架使用其他协议,比如 gRPC 用的是 HTTP2 来实现。

一次RPC的调用过程

忽略服务端向注册中心注册服务的流程,下面是客户端和服务端之间进行一次RPC调用的完整过程。

image-20231102193528606
  1. 客户端(Client)通过本地调用的方式调用服务(以接口方式调用);
  2. 客户端存根(Client Stub)接收到调用请求后负责将方法、入参等信息进行组装序列化成能够进行网络传输的消息体(将消息体对象序列化为二进制流);
  3. 客户端存根(Client Stub)找到远程的服务地址,并且将消息通过网络发送给服务端(通过sockets发送消息);
  4. 服务端存根(Server Stub)收到消息后进行反序列化操作,即解码(将二进制流反序列化为消息对象);
  5. 服务端存根(Server Stub)通过解码结果调用本地的服务进行相关处理;
  6. 服务端(Server)将处理结果返回给服务端存根;
  7. 服务端存根(Server Stub)序列化处理结果(将结果消息对象序列化为二进制流);
  8. 服务端存根(Server Stub)将序列化结果通过网络发送至客户端(通过sockets发送消息);
  9. 客户端存根(Server Stub)接收到消息,进行反序列化解码(将结果二进制流反序列化为消息对象);
  10. 客户端得到最终的结果。

这里面有一个词语:存根(Stub)。这里存根的作用我认为和Linux内核里面的库打桩机制有点类似。在Linux中,一个"桩"(stub)就是一个程序或函数的临时替代品,"桩"可以模拟出类似于真实的程序或函数的行为。所以,在RPC中,客户端存根和服务器存根的作用是隐藏RPC底层机制的复杂性,让开发者可以像调用本地函数一样调用远程函数。

实践

基于HTTP协议的RPC

服务端代码:

type Args struct {
	A, B int
}

type Compute int

func (c *Compute) Add(args *Args, reply *int) error {
	*reply = args.A + args.B
	return nil
}

func main() {
	compute := new(Compute)
	rpc.HandleHTTP() // 注册 HTTP 路由
    // 注册 RPC 服务
	if err := rpc.Register(compute); err != nil {
		log.Fatal("Register error:", err)
	}

	listen, err := net.Listen("tcp", ":8080")
	if err != nil {
		log.Fatal("Listen error:", err)
	}
	if err = http.Serve(listen, nil); err != nil {
		log.Fatal("Serve error:", err)
	}
}

rpc库对注册的方法有一定的限制,方法必须满足签名func (t *T) MethodName(argType T1, replyType *T2) error{}

  1. 方法名必需是可导出的。
  2. 方法接收两个参数,这两个参数都是可导出的,且第二个参数必需为指针类型。
  3. 方法必需返回一个error类型的参数。

客户端代码:

type Args struct {
	A, B int
}

func main() {
	client, err := rpc.DialHTTP("tcp", "localhost:8080")
	if err != nil {
		log.Fatal("dialing:", err)
	}

	args := &Args{3, 5}
	// 同步调用
	var reply1 int
	if err = client.Call("Compute.Add", args, &reply1); err != nil {
		log.Fatal("Compute error:", err)
	}
	fmt.Printf("同步调用的sum: %d\n", reply1)

	// 异步调用
	var reply2 int
	divCall := client.Go("Compute.Add", args, &reply2, nil)
	_ = <-divCall.Done // 接收调用结果
	fmt.Printf("异步调用的sum: %d\n", reply2)
}

运行结果如下:

PS D:\GolandProjects\RPC\client> go run .\client.go
同步调用的sum: 8
异步调用的sum: 8

基于TCP协议的RPC

服务端代码:

type Args struct {
	A, B int
}

type Compute int

func (c *Compute) Add(args *Args, reply *int) error {
	*reply = args.A + args.B
	return nil
}

func main() {
	compute := new(Compute)
	if err := rpc.Register(compute); err != nil {
		log.Fatal("Register error:", err)
	}

	listen, err := net.Listen("tcp", ":8080")
	if err != nil {
		log.Fatal("Listen error:", err)
	}
	rpc.Accept(listen)
}

客户端代码:

type Args struct {
	A, B int
}

func main() {
	client, err := rpc.Dial("tcp", "localhost:8080")
	if err != nil {
		log.Fatal("dialing:", err)
	}

	args := &Args{6, 8}
	// 同步调用
	var reply1 int
	if err = client.Call("Compute.Add", args, &reply1); err != nil {
		log.Fatal("Compute error:", err)
	}
	fmt.Printf("同步调用的sum: %d\n", reply1)

	// 异步调用
	var reply2 int
	divCall := client.Go("Compute.Add", args, &reply2, nil)
	_ = <-divCall.Done // 接收调用结果
	fmt.Printf("异步调用的sum: %d\n", reply2)
}

运行结果:

PS D:\GolandProjects\RPC\client> go run .\client.go
同步调用的sum: 14
异步调用的sum: 14
Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐