一文带你了解RPC框架和实现原理

一、介绍

RPCRemote Procedure Call):远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的思想。

RPC 是一种技术思想而非一种规范或协议,常见RPC技术和框架有:

  • 应用级的服务框架:阿里的 Dubbo/DubboxGoogle gRPCSpring Boot/Spring Cloud
  • 远程通信协议:RMISocketSOAP(HTTP XML)REST(HTTP JSON)
  • 通信框架:MINANetty

下面重点介绍三种:

  • gRPC:是 Google 公布的开源软件,基于最新的 HTTP 2.0协议,并支持常见的众多编程语言。RPC框架是基于 HTTP协议实现的,底层使用到了Netty 框架的支持。
  • Thrift:是 Facebook的开源RPC框架,主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行,应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性,还是有一定成本的。
  • Dubbo:是阿里集团开源的一个极为出名的 RPC框架,在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是极其鲜明的特色。

二、完整的 RPC 框架

在一个典型RPC 的使用场景中,包含了服务发现、负载、容错、网络传输、序列化等组件,其中“RPC 协议”就指明了程序如何进行网络传输和序列化。
一文带你了解RPC框架和实现原理_第1张图片

1、RPC核心功能

RPC 的核心功能是指实现一个RPC最重要的功能模块,就是上图中的”RPC协议”部分:
一文带你了解RPC框架和实现原理_第2张图片

2、RPC组成部分

一个 RPC 的核心功能主要有 5个部分组成,分别是:客户端、客户端Stub、网络传输模块、服务端 Stub、服务端等。
一文带你了解RPC框架和实现原理_第3张图片

下面分别介绍核心 RPC 框架的重要组成:

  • 客户端(Client):服务调用方。
  • 客户端存根(Client Stub):存放服务端地址信息,将客户端的请求参数数据信息打包成网络消息,再通过网络传输发送给服务端。
  • 服务端存根(Server Stub):接收客户端发送过来的请求消息并进行解包,然后再调用本地服务进行处理。
  • 服务端(Server):服务的真正提供者。
  • Network Service:底层传输,可以是TCPHTTP

如果网络传输中使用的是HTTP协议,建立HTTP协议之间有 TCP三次握手,断开HTTP协议时有TCP四次挥手:
一文带你了解RPC框架和实现原理_第4张图片

3、详细调用过程

RPC 实现流程和分工角色可以用下图来表示:
一文带你了解RPC框架和实现原理_第5张图片
一次RPC 调用流程如下:

  • 服务消费者(Client 客户端)通过本地调用的方式调用服务。
  • 客户端存根(Client Stub)接收到调用请求后负责将方法、入参等信息序列化(组装)成能够进行网络传输的消息体。
  • 客户端存根(Client Stub)找到远程的服务地址,并且将消息通过网络发送给服务端。
  • 服务端存根(Server Stub)收到消息后进行解码(反序列化操作)。
  • 服务端存根(Server Stub)根据解码结果调用本地的服务进行相关处理
  • 服务端(Server)本地服务业务处理。
  • 处理结果返回给服务端存根(Server Stub)。
  • 服务端存根(Server Stub)序列化结果。
  • 服务端存根(Server Stub)将结果通过网络发送至消费方。
  • 客户端存根(Client Stub)接收到消息,并进行解码(反序列化)。
  • 服务消费方得到最终结果。

4、RPC 核心之功能实现

RPC的核心功能主要由 5个模块组成,如果想要自己实现一个RPC,最简单的方式要实现三个技术点,分别是:

  • 服务寻址
  • 数据流的序列化和反序列化
  • 网络传输

4.1、服务寻址

服务寻址可以使用 Call ID 映射。在本地调用中,函数体是直接通过函数指针来指定的,但是在远程调用中,函数指针是不行的,因为两个进程的地址空间是完全不一样的。

所以在 RPC 中,所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。

客户端在做远程过程调用时,必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个函数和Call ID的对应表。

当客户端需要进行远程调用时,它就查一下这个表,找出相应的Call ID,然后把它传给服务端,服务端也通过查表,来确定客户端需要调用的函数,然后执行相应函数的代码。

实现方式:服务注册中心。

要调用服务,首先你需要一个服务注册中心去查询对方服务都有哪些实例。Dubbo的服务注册中心是可以配置的,官方推荐使用Zookeeper

实现案例:RMIRemote Method Invocation,远程方法调用)也就是RPC本身的实现方式。
一文带你了解RPC框架和实现原理_第6张图片

Registry(服务发现):借助JNDI发布并调用了 RMI服务。实际上,JNDI就是一个注册表,服务端将服务对象放入到注册表中,客户端从注册表中获取服务对象。

RMI 服务在服务端实现之后需要注册到 RMI Server 上,然后客户端从指定的RMI地址上 Lookup 服务,调用该服务对应的方法即可完成远程方法调用。

Registry 是个很重要的功能,当服务端开发完服务之后,要对外暴露,如果没有服务注册,则客户端是无从调用的,即使服务端的服务就在那里。

4.2、序列化和反序列化

客户端怎么把参数值传给远程的函数呢?在本地调用中,我们只需要把参数压到栈里,然后让函数自己去栈里读就行。

但是在远程过程调用时,客户端跟服务端是不同的进程,不能通过内存来传递参数。

这时候就需要客户端把参数先转成一个字节流,传给服务端后,再把字节流转成自己能读取的格式。

  • 对象转换为有序字节流的过程叫做序列化
  • 将二进制流转换成对象的过程叫做反序列化

这个过程叫序列化和反序列化。同理,从服务端返回的值也需要序列化反序列化的过程。

4.3、网络传输

远程调用往往用在网络上,客户端和服务端是通过网络连接的。

所有的数据都需要通过网络传输,因此就需要有一个网络传输层。网络传输层需要把Call ID 和序列化后的参数字节流传给服务端,然后再把序列化后的调用结果传回客户端。

只要能完成这两者的,都可以作为传输层使用。因此,它所使用的协议其实是不限的,能完成传输就行。

尽管大部分RPC 框架都使用TCP 协议,但其实UDP 也可以,而gRPC干脆就用了HTTP2

TCP 的连接是最常见的,简要分析基于 TCP 的连接:通常 TCP 连接可以是按需连接(需要调用的时候就先建立连接,调用结束后就立马断掉),也可以是长连接(客户端和服务器建立起连接之后保持长期持有,不管此时有无数据包的发送,可以配合心跳检测机制定期检测建立的连接是否存活有效),多个远程过程调用共享同一个连接。

所以,要实现一个 RPC 框架,只需要把以下三点实现了就基本完成了:

  • Call ID 映射:可以直接使用函数字符串,也可以使用整数ID。映射表一般就是一个哈希表。
  • 序列化反序列化:可以自己写,也可以使用 Protobuf或者 FlatBuffers 之类的。
  • 网络传输库:可以自己写 Socket,或者用AsioZeroMQNetty 之类。

RPC 核心之网络传输协议

要实现一个 RPC,需要选择网络传输的方式。
一文带你了解RPC框架和实现原理_第7张图片

RPC 中可选的网络传输方式有多种,可以选择 TCP 协议、UDP协议、HTTP 协议。

每一种协议对整体的性能和效率都有不同的影响,如何选择一个正确的网络传输协议呢?首先要搞明白各种传输协议在RPC 中的工作方式。

基于TCP 协议的 RPC 调用

由服务的调用方与服务的提供方建立 Socket 连接,并由服务的调用方通过Socket将需要调用的接口名称、方法名称和参数序列化后传递给服务的提供方,服务的提供方反序列化后再利用反射调用相关的方法。

最后将结果返回给服务的调用方,整个基于 TCP 协议的 RPC调用大致如此。

但是在实例应用中则会进行一系列的封装,如RMI 便是在 TCP协议上传递可序列化的Java 对象。

基于 HTTP协议的RPC 调用

该方法更像是访问网页一样,只是它的返回结果更加单一简单。

其大致流程为:由服务的调用者向服务的提供者发送请求,这种请求的方式可能是 GETPOSTPUTDELETE等中的一种,服务的提供者可能会根据不同的请求方式做出不同的处理,或者某个方法只允许某种请求方式。

而调用的具体方法则是根据 URL 进行方法调用,而方法所需要的参数可能是对服务调用方传输过去的 XML 数据或者JSON数据解析后的结果,最后返回 JOSN或者 XML 的数据结果。

由于目前有很多开源的Web 服务器,如Tomcat,所以其实现起来更加容易,就像做 Web项目一样。

两种方式对比

基于TCP的协议实现的 RPC调用,由于TCP协议处于协议栈的下层,能够更加灵活地对协议字段进行定制,减少网络开销,提高性能,实现更大的吞吐量和并发数。

但是需要更多关注底层复杂的细节,实现的代价更高。同时对不同平台,如安卓,iOS 等,需要重新开发出不同的工具包来进行请求发送和相应解析,工作量大,难以快速响应和满足用户需求。

基于HTTP 协议实现的RPC则可以使用JSONXML 格式的请求或响应数据。

JSONXML作为通用的格式标准(使用 HTTP 协议也需要序列化和反序列化,不过这不是该协议下关心的内容,成熟的Web 程序已经做好了序列化内容),开源的解析工具已经相当成熟,在其上进行二次开发会非常便捷和简单。

但是由于 HTTP 协议是上层协议,发送包含同等内容的信息,使用HTTP协议传输所占用的字节数会比使用 TCP协议传输所占用的字节数更高。

因此在同等网络下,通过 HTTP协议传输相同内容,效率会比基于TCP协议的数据效率要低,信息传输所占用的时间也会更长,当然压缩数据,能够缩小这一差距。

你可能感兴趣的:(RPC,java,rpc,后端,网络通信,软件架构师)