RPC——RPC协议介绍及原理详解

- 日理万妓 2024-03-16 16:38 51阅读 0赞

## common wx：`CodingTechWork` ##

### 介绍![RPC学习总结思维导图][RPC] ###

## RPC框架 ##

#### 概念 ####

1.  RPC（Remote Procedure Call Protocol） 远程过程调用协议。
2.  RPC是一种通过网络从远程计算机程序上请求服务，不需要了解底层网络技术的协议。
3.  RPC主要作用就是不同的服务间方法调用就像本地调用一样便捷。

#### 常用RPC技术或框架 ####

1.  应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
2.  远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
3.  通信框架：MINA 和 Netty

##### 主流的gRPC、Thrift、Dubbo #####

1.  `gRPC`：gRPC是Google开源软件，gRPC是基于HTTP2.0协议，而HTTP2.0是基于二进制的HTTP协议升级版本，底层使用Netty框架支持。
2.  `Thrift`：Thrift是Facebook开源项目，其是一个跨语言的服务开发框架。用户只需在进行二开即可，对底层的RPC通讯透明。
3.  `Dubbo`：Dubbo是阿里开源组件协议和序列化框架都可以插拔，依托Spring框架开发，远程接口是基于Java接口，适用于微服务架构。

#### 为什么要有RPC？ ####

1.  `服务化`：微服务化，跨平台的服务之间远程调用；
2.  `分布式系统架构`：分布式服务跨机器进行远程调用；
3.  `服务可重用`：开发一个公共能力服务，供多个服务远程调用。
4.  `系统间交互调用`：两台服务器A、B，服务器A上的应用a需要调用服务器B上的应用b提供的方法，而应用a和应用b不在一个内存空间，不能直接调用，此时，需要通过网络传输来表达需要调用的语义及传输调用的数据。

#### 使用场景 ####

1.  `大型网站`：内部涉及多个子系统，服务、接口较多。
2.  `注册发现机制`：如Nacos、Dubbo等，一般都有注册中心，服务有多个实例，调用方调用的哪个实例无感知。
3.  安全性\`：不暴露资源。
4.  `服务化治理`：微服务架构、分布式架构。

### 架构 ###

#### 架构图 ####

![在这里插入图片描述][655c04a02b08474e985ff4bf8a561d12.png]

#### 一次RPC调用流程 ####

![在这里插入图片描述][f1ada8de70e34174b55b5374fa46021b.png]

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

### 核心功能 ###

#### 重要组成 ####

1.  客户端：Client，服务调用方。
2.  客户端存根：Client Stub，存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
3.  服务端存根：Server Stub，接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
4.  服务端：Server，服务的真正提供者。
5.  newtwork service：底层传输，tcp或http

#### 功能实现 ####

功能实现主要分为服务寻址、序列化和反序列化、网络传输功能。

##### 服务寻址功能 #####

###### Call ID映射 ######

1.  本地：在本地方法调用中，函数体是直接通过函数指针来指定的，但是在远程调用中，由于两个进程的地址空间完全不一样，函数指针不起作用。
2.  远程：RPC中所有函数或方法都有自己的一个ID，在所有进程中都唯一。客户端在做远程过程调用时，必须附上这个ID，即客户端会查一下表，找出相应的Call ID，然后传给服务端，服务端也会查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
3.  Call ID映射表一般是一个哈希表。

###### 技术示例 ######

需要通过服务注册中心去查询对方服务有哪些实例。

1.  Nacos整合OpenFeign实现RPC调用。
2.  Spring Cloud集成Dubbo实现RPC调用。

##### 序列化和反序列化功能 #####

###### 概述 ######

1.  序列化：将消息对象转换为二进制流。
2.  反序列化：将二进制流转换为消息对象。

###### 必要性 ######

1.  远程调用涉及到数据的传输，在本地调用中，只需要将数据压入栈中，然后让函数去栈中读取即可。
2.  但远程的数据传输，由于客户端和服务端不在同一个服务器上，涉及不同的进程，不能通过内存传递参数，此时就需要将客户端先将请求参数转成字节流（编码），传递给服务端，服务端再将字节流转为自己可读取格式（解码），这就是序列化和反序列化的过程。反之，服务端返回值也逆向经历序列化和反序列化到客户端。

###### 序列化的优势 ######

1.  将消息对象转为二进制字节流，便于网络传输。
2.  可跨平台、跨语言。如Python编写的客户端请求序列化参数传输到Java编写的服务端进行反序列化。

##### 网络传输功能 #####

###### 作用 ######

1.  客户端将Call ID和序列化后的参数字节流传输给服务端。
2.  服务端将序列化后的调用结果回传给客户端。

###### 协议 ######

主要有TCP、UDP、HTTP协议。

###### 基于TCP协议 ######

1.  客户端和服务端建立Socket连接。
2.  客户端通过Socket将需要调用的接口名称、方法名称及参数序列化后传递给服务端。
3.  服务端反序列化后再利用反射调用对应的方法，将结果返回给客户端。

###### 基于HTTP协议 ######

1.  客户端向服务端发送请求，如GET、POST、PUT、DELETE等请求。
2.  服务端根据不同的请求参数和请求URL进行方法调用，返回JSON或者XML数据结果。

###### TCP和HTTP对比 ######

1.  基于TCP协议实现的RPC调用，由于是底层协议栈，更佳灵活的对协议字段进行定制，可减少网络开销，提高性能，实现更大的吞吐量和并发数。但，底层复杂，实现代价高。
2.  基于HTTP协议实现的RPC调用，已封装实现序列化，但HTTP属于应用层协议，HTTP传输所占用的字节数比TCP更高，传输效率对比TCP较低。

### RPC与Restful API对比 ###

#### 侧重不同 ####

1.  RPC侧重于操作
2.  Restful侧重于资源

#### 传输效率 ####

1.  RPC效率更高，可自定义TCP协议，控制请求报文体积。
2.  Restful效率更低，基于HTTP协议。

#### 复杂度 ####

1.  RPC实现复杂，需关注服务寻址、序列化和反序列化及网络传输，调用流程繁琐。
2.  Restful实现简单，无需关注序列化和反序列化、网络传输，调用流程便捷。

#### 使用场景 ####

1.  RPC适用于公司内部服务调用，如部门之间不同平台的服务调用，性能消耗低，传输效率高，实现复杂一些。
2.  HTTP主要用于外部异构环境，浏览器接口调用、第三方接口调用等。

[RPC]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/24ac6af09a15428e851f7f0b6866bba1.png
[655c04a02b08474e985ff4bf8a561d12.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/665f02965dbf4beabf88acc86021d4ed.png
[f1ada8de70e34174b55b5374fa46021b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/aae276863f24407e9bda008c5e1e0ab2.png