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

common wx：CodingTechWork

介绍

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. 服务化治理：微服务架构、分布式架构。

架构

架构图

一次RPC调用流程

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主要用于外部异构环境，浏览器接口调用、第三方接口调用等。