【RPC】RPC框架实现原理---未研读
解释一
原文：https://www.jianshu.com/p/78f72ccf0377
一、什么是RPC框架？
RPC，全称为Remote Procedure Call，即远程过程调用，是一种计算机通信协议。
二、RPC框架的实现原理？
主要有以下几个步骤：
1、建立通信
主要是通过在客户端和服务器之间建立TCP连接，可以短链接（需要调用的时候就先建立连接，调用结束后就立马断掉），也可以是长连接（客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效），多个远程过程调用共享同一个连接。
2、服务寻址
解决寻址的问题：即A机器上的应用A要调用B机器上的应用B，那么此时对于A来说如何告知底层的RPC框架所要调用的服务具体在哪里呢？
通常情况下我们需要提供：B机器（主机名或IP地址）、特定的端口、方法或者函数的名称、入参出参等信息。
比如基于Web服务协议栈的RPC，就需要提供一个endpoint URI，或者是从UDDI服务上进行查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
3、网络传输
3.1、序列化
当A机器上的应用发起一个RPC调用时，调用方法和其入参等信息需要通过底层的网络协议如TCP传输到B机器，由于网络协议是基于二进制的，所有我们传输的参数数据都需要先进行序列化（Serialize）或者编组（marshal）成二进制的形式才能在网络中进行传输。然后通过寻址操作和网络传输将序列化或者编组之后的二进制数据发送给B机器。
3.2、反序列化
当B机器接收到A机器的应用发来的请求之后，又需要对接收到的参数等信息进行反序列化操作（序列化的逆操作），即将二进制信息恢复为内存中的表达方式，然后再找到对应的方法（寻址的一部分）进行本地调用（一般是通过生成代理Proxy去调用, 通常会有JDK动态代理、CGLIB动态代理、Javassist生成字节码技术等），之后得到调用的返回值。
4、服务调用
B机器进行本地调用（通过代理Proxy）之后得到了返回值，此时还需要再把返回值发送回A机器，同样也需要经过序列化操作，然后再经过网络传输将二进制数据发送回A机器，而当A机器接收到这些返回值之后，则再次进行反序列化操作，恢复为内存中的表达方式，最后再交给A机器上的应用进行相关处理（一般是业务逻辑处理操作）。
通常，经过以上四个步骤之后，一次完整的RPC调用算是完成了，另外可能因为网络抖动等原因需要重试等。
三、为什么需要RPC？
主要就是因为在几个进程内（应用分布在不同的机器上），无法共用内存空间，或者在一台机器内通过本地调用无法完成相关的需求，比如不同的系统之间的通讯，甚至不同组织之间的通讯。此外由于机器的横向扩展，需要在多台机器组成的集群上部署应用等等。
四、RPC支持哪些协议？
最早的CORBA、Java RMI， WebService方式的RPC风格， Hessian, Thrift甚至Rest API。
五、RPC的实现基础？
1、需要有非常高效的网络通信，比如一般选择Netty作为网络通信框架
2、需要有比较高效的序列化框架，比如谷歌的Protobuf序列化框架
3、可靠的寻址方式（主要是提供服务的发现），比如可以使用Zookeeper来注册服务等等
4、如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能
六、RPC调用过程？
6.1 一个基本的RPC架构里面应该至少包含以下4个组件：
1、客户端（Client）:服务调用方（服务消费者）
2、客户端存根（Client Stub）:存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端
3、服务端存根（Server Stub）:接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理
4、服务端（Server）:服务的真正提供者
6.2 具体的调用过程如下：
1、服务消费者（client客户端）通过本地调用的方式调用服务
2、客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体
3、客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端
4、服务端存根（server stub）收到消息后进行解码（反序列化操作）
5、服务端存根（server stub）根据解码结果调用本地的服务进行相关处理
6、本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）
7、服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方
8、客户端存根（client stub）接收到消息，并进行解码（反序列化）
9、服务消费方得到最终结果
image.png
而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。
七、RPC框架需要解决的问题？
1、如何确定客户端和服务端之间的通信协议？
2、如何更高效地进行网络通信？
3、服务端提供的服务如何暴露给客户端？
4、客户端如何发现这些暴露的服务？
5、如何更高效地对请求对象和响应结果进行序列化和反序列化操作？
八、使用了哪些技术？
8.1、动态代理
生成Client Stub（客户端存根）和Server Stub（服务端存根）的时候需要用到java动态代理技术，可以使用jdk提供的原生的动态代理机制，也可以使用开源的：Cglib代理，Javassist字节码生成技术。
8.2、序列化
在网络中，所有的数据都将会被转化为字节进行传送，所以为了能够使参数对象在网络中进行传输，需要对这些参数进行序列化和反序列化操作。
序列化：把对象转换为字节序列的过程称为对象的序列化，也就是编码的过程。
反序列化：把字节序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。
目前比较高效的开源序列化框架：如Kryo、fastjson和Protobuf等。
8.3、NIO通信
出于并发性能的考虑，传统的阻塞式 IO 显然不太合适，因此我们需要异步的 IO，即 NIO。
Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。可以选择Netty或者mina来解决NIO数据传输的问题。
8.4、服务注册中心
可选：Redis、Zookeeper、Consul 、Etcd。
一般使用ZooKeeper提供服务注册与发现功能，解决单点故障以及分布式部署的问题(注册中心)。
参考https://my.oschina.net/huangyong/blog/361751实现了RPC框架
github代码：https://github.com/hu1991die/netty-rpc
原文参考：
1、https://www.zhihu.com/question/25536695
2、http://www.importnew.com/22003.html
3、http://blog.jobbole.com/92290/
作者：hu1991die
链接：https://www.jianshu.com/p/78f72ccf0377
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
解释二
RPC采用客户机/服务器模式（C/S）。
RPC框架实现的架构原理：
Client Code ：客户端调用方代码实现，负责发起RPC调用，为调用方用户提供使用API。
Seriallzation/Deseraillzation：负责对RPC调用通过网络传输的内容进行序列化与反序列化，不同的RPC框架有不同的实现机制。主要分为文本与二进制两大类。文本类别的序列化机制主要有XML与JSON两种格式。二级制类别的序列化机制常见的有看Java原生的序列化机制，以及Hession、protobuf、Thrift、Avro、Kryo、MessagePack等，不同的序列化方式在可读性、码流大小、支持的数据类型及性能等方面都存在较大的差异，需要用户根据自己的实际情况进行甄别与筛选。
Stub Proxy：可以看作是一种代理对象，屏蔽RPC调用过程中复杂的网络处理逻辑，使得RPC调用透明化，能够保持与本地调用一样的代码风格。
Transport：作为RPC框架底层的通信传输模块，一般通过Socket在客户端与服务端之间传递请求与应答消息。
Server Code：服务端服务业务逻辑具体的实现。
常见RPC框架：SpringCloud、Dubbo、RMI、CXF/Axis2、Thrift、gRPC、HTTP Client等。
RPC解决了什么问题：
1.将业务拆分成几个互不关联的应用，分别部署在各自机器上，以划清逻辑并减小压力。
2.当业务/应用越来越多就不是简单的拆分能够解决，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用 交互，以此来完成完整的业务功能。
RPC框架与分布式服务框架的区别：
RPC实现了服务消费者调用方Client与服务提供实现方Server之间的点对点调用流程，包括stub、通信、数据的序列化/反序列化。调用方与服务提供方一般采用直连的调用方式。
而分布式服务框架，除了RPC的特性，还包括了Server提供服务的负载均衡策略及实现，服务的注册、发布与引入，以及服务的高可用策略、服务治理等特性。
RPC原理实例分析：http://www.importnew.com/22003.html
文章大部分摘自：https://blog.csdn.net/kingcat666/article/details/78577079
RPC原理：
Nelson 的论文中指出实现 RPC 的程序包括 5 个部分：
1. User
2. User-stub
3. RPCRuntime
4. Server-stub
5. Server
这 5 个部分的关系如下图所示
这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用user-stub。user-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。远端 RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。
粗粒度的 RPC 实现概念结构，这里我们进一步细化它应该由哪些组件构成，如下图所示。
RPC 服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过 RpcClient 去引入（import）远程接口方法。客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理RpcProxy 。代理封装调用信息并将调用转交给RpcInvoker 去实际执行。在客户端的RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道RpcChannel，并使用RpcProtocol 执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。
RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用RpcProtocol 执行协议解码（decode）。解码后的调用信息传递给RpcProcessor 去控制处理调用过程，最后再委托调用给RpcInvoker 去实际执行并返回调用结果。如下是各个部分的详细职责：
1. RpcServer 负责导出（export）远程接口
2. RpcClient 负责导入（import）远程接口的代理实现
3. RpcProxy 远程接口的代理实现
4. RpcInvoker
客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回
服务方实现：负责调用服务端接口的具体实现并返回调用结果
5. RpcProtocol 负责协议编/解码
6. RpcConnector 负责维持客户方和服务方的连接通道和发送数据到服务方
7. RpcAcceptor 负责接收客户方请求并返回请求结果
8. RpcProcessor 负责在服务方控制调用过程，包括管理调用线程池、超时时间等
9. RpcChannel 数据传输通道
RPC核心技术：
（1）服务暴露：
远程提供者需要以某种形式提供服务调用相关的信息，包括但不限于服务接口定义、数据结构、或者中间态的服务定义文件。例如Facebook的Thrift的IDL文件，Web service的WSDL文件；服务的调用者需要通过一定的途径获取远程服务调用相关的信息。
目前，大部分跨语言平台 RPC 框架采用根据 IDL 定义通过 code generator 去生成 stub 代码，这种方式下实际导入的过程就是通过代码生成器在编译期完成的。代码生成的方式对跨语言平台 RPC 框架而言是必然的选择，而对于同一语言平台的 RPC 则可以通过共享接口定义来实现。这里的导入方式本质也是一种代码生成技术，只不过是在运行时生成，比静态编译期的代码生成看起来更简洁些。
java 中还有一种比较特殊的调用就是多态，也就是一个接口可能有多个实现，那么远程调用时到底调用哪个？这个本地调用的语义是通过 jvm 提供的引用多态性隐式实现的，那么对于 RPC 来说跨进程的调用就没法隐式实现了。如果前面DemoService 接口有 2 个实现，那么在导出接口时就需要特殊标记不同的实现需要，那么远程调用时也需要传递该标记才能调用到正确的实现类，这样就解决了多态调用的语义问题。
（2）远程代理对象：
服务调用者用的服务实际是远程服务的本地代理。说白了就是通过动态代理来实现。
java 里至少提供了两种技术来提供动态代码生成，一种是 jdk 动态代理，另外一种是字节码生成。动态代理相比字节码生成使用起来更方便，但动态代理方式在性能上是要逊色于直接的字节码生成的，而字节码生成在代码可读性上要差很多。两者权衡起来，个人认为牺牲一些性能来获得代码可读性和可维护性显得更重要。
（3）通信：
RPC框架与具体的协议无关。RPC 可基于 HTTP 或 TCP 协议，Web Service 就是基于 HTTP 协议的 RPC，它具有良好的跨平台性，但其性能却不如基于 TCP 协议的 RPC。
1. TCP/HTTP：众所周知，TCP 是传输层协议，HTTP 是应用层协议，而传输层较应用层更加底层，在数据传输方面，越底层越快，因此，在一般情况下，TCP 一定比 HTTP 快。
2. 消息ID：RPC 的应用场景实质是一种可靠的请求应答消息流，和 HTTP 类似。因此选择长连接方式的 TCP 协议会更高效，与 HTTP 不同的是在协议层面我们定义了每个消息的唯一 id，因此可以更容易的复用连接。
3. IO方式：为了支持高并发，传统的阻塞式 IO 显然不太合适，因此我们需要异步的 IO，即 NIO。Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。
4. 多连接：既然使用长连接，那么第一个问题是到底 client 和 server 之间需要多少根连接？实际上单连接和多连接在使用上没有区别，对于数据传输量较小的应用类型，单连接基本足够。单连接和多连接最大的区别在于，每根连接都有自己私有的发送和接收缓冲区，因此大数据量传输时分散在不同的连接缓冲区会得到更好的吞吐效率。所以，如果你的数据传输量不足以让单连接的缓冲区一直处于饱和状态的话，那么使用多连接并不会产生任何明显的提升，反而会增加连接管理的开销。
5. 心跳：连接是由 client 端发起建立并维持。如果 client 和 server 之间是直连的，那么连接一般不会中断（当然物理链路故障除外）。如果 client 和 server 连接经过一些负载中转设备，有可能连接一段时间不活跃时会被这些中间设备中断。为了保持连接有必要定时为每个连接发送心跳数据以维持连接不中断。心跳消息是 RPC 框架库使用的内部消息，在前文协议头结构中也有一个专门的心跳位，就是用来标记心跳消息的，它对业务应用透明。
（4）序列化：
两方面会直接影响 RPC 的性能，一是传输方式，二是序列化。
1. 序列化方式：毕竟是远程通信，需要将对象转化成二进制流进行传输。不同的RPC框架应用的场景不同，在序列化上也会采取不同的技术。 就序列化而言，Java 提供了默认的序列化方式，但在高并发的情况下，这种方式将会带来一些性能上的瓶颈，于是市面上出现了一系列优秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，它们可以取代 Java 默认的序列化，从而提供更高效的性能。
2. 编码内容：出于效率考虑，编码的信息越少越好（传输数据少），编码的规则越简单越好（执行效率高）。如下是编码需要具备的信息：
-- 调用编码 --
1. 接口方法
包括接口名、方法名
2. 方法参数
包括参数类型、参数值
3. 调用属性
包括调用属性信息，例如调用附件隐式参数、调用超时时间等
-- 返回编码 --
1. 返回结果
接口方法中定义的返回值
2. 返回码
异常返回码
3. 返回异常信息
调用异常信息
除了以上这些必须的调用信息，我们可能还需要一些元信息以方便程序编解码以及未来可能的扩展。这样我们的编码消息里面就分成了两部分，一部分是元信息、另一部分是调用的必要信息。如果设计一种 RPC 协议消息的话，元信息我们把它放在协议消息头中，而必要信息放在协议消息体中。下面给出一种概念上的 RPC 协议消息设计格式：
-- 消息头 --
magic : 协议魔数，为解码设计
header size: 协议头长度，为扩展设计
version : 协议版本，为兼容设计
st : 消息体序列化类型
hb : 心跳消息标记，为长连接传输层心跳设计
ow : 单向消息标记，
rp : 响应消息标记，不置位默认是请求消息
status code: 响应消息状态码
reserved : 为字节对齐保留
message id : 消息 id
body size : 消息体长度
-- 消息体 --
采用序列化编码，常见有以下格式
xml : 如 webservie soap
json : 如 JSON-RPC
binary: 如 thrift; hession; kryo 等
————————————————
版权声明：本文为CSDN博主「不要停止思考」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41723615/article/details/90178604
