https://blog.csdn.net/why_2012_gogo/article/details/79425338（原文地址）
一、RPC是什么
RPC（Remote Procedure Call），是一种远程过程调用的协议方案，其本身是一种借助于网络来实现不同机子或应用之间跨进程通信的，不是一个实现框架，即并非是一个拿来即用的框架。目前，比较主流使用的RPC开源框架有谷歌的gRPC，Facebook的Thrift，阿里的Dubbo，开源SpringCloud，以及Spring的RMI等均基于RPC协议方案实现了远程过程功能的使用，虽实现方式不同，但原理却大同小异。接下来，介绍下RPC的工作流，RPC实现需要做的事情，以及几种常见RPC框架的主要异同点对比。
二、RPC工作流程
RPC是基于典型的C/S模式的远程调用方案，分为客户端（Caller）和服务端（Callee）。Caller负责调用远程的服务，而Callee则负责提供服务功能，并暴露给使用者Caller，这在现今的微服务架构中很常见，而RPC基本概念化工作流如下：
1、Client发起远程调用时，是通过Client-stub实现的；
2、Client-stub接受Client调用通知后，负责将调用的接口、方法及参数，按照约定的协议规范进行编码存根；
3、本地RPCRuntime负责远程传输在Client-stub中编码的数据包；
4、远程RPCRuntime接收到消息请求后，将其传递给Server-stub，由其负责解码处理，然后发起本地调用，完成具体服务功能并返回结果给Client。
从上面流程看，认为RPC的实现比较简单，其实不然。在整个RPC概念过程中，有很多事情要做，比如：是否跨语言支持，网络传输的性能与协议，数据包编解码以及异常恢复处理等，不简单了吧！具体请往下俯瞰。
三、RPC实现内容
通过上面的介绍，我们应该知道RPC是什么，以及它的工作流程是怎样的，那么有人问RPC是一个协议方案，该如何设计昵？答案在下面揭晓，我们需要实现下面几点内容：
1、两端的Stub生成策略，是手动还是自动生成，前者较麻烦，后者可借助使用生成工具生成，如：Thrift本身提供的工具；
2、是否支持跨语言平台，也就是不同语言的无缝兼容，一般都是通过IDL来声明接口文件实现跨语言；
3、网络传输协议格式约定，可采用消息头和消息体的方式，一般采用消息头存放元数据，消息体存放消息内容；
4、网络传输采用的协议类型，主流的RPC框架采用了Socket较多，而也有基于HTTP协议的RPC框架，如：谷歌的gRPC采用HTTP2.0；
5、在高并发时，两端交互时是否支持异步/同步多线程的通信机制；
6、异常处理要注意：本地执行一定会执行，但远程调用则不一定执行，可能因为网络问题未能送达到服务方。另外，本地调用只会抛出接口声明异常，而远程调用还会抛出RPC框架异常，同时本地和与远程调用的性能消耗可能差距较大，这取决于RPC固有消耗所占比重。
正如上面，既然有这么多工作要做，那么全部交给开发人员来完成，则需要若干天时间成本，即使跑通流程，也未必稳定，所以实际使用时，我们会借助于强大的开源框架来实现，正如在本章开头部分所描述的内容。
四、RPC结构分析
上面比较粗略地介绍了RPC的工作流程，接下来对RPC协议方案的结构进行拆分，更加清楚了解RPC的工作原理细节，这样在接触主流的RPC开源框架时，更加游刃有余，具体如下所示：
RPC服务方通过RpcServer导出(export)远程接口方法，供客户端通过RpcClient引入(import)该远程接口方法。这样客户端就可以调用引入的远程API了，然后调用该接口方法，跟调用远程接口方法一样，RPC框架提供接口的代理实现，实际的调用委托给了RpcProxy，而该代理封装调用信息并将调用转交给RpcInvoker实际执行调用。在客户端的RpcInvoker通过RpcConnector维持与服务端RpcChannel，并使用RpcChannel进行协议编码（encode），并将编码后的请求消息借助通道发送给服务方。
RPC服务端接收器RpcAcceptor接收客户端的调用请求，同时使用RpcProtocol进行协议解码（decode）。解码后的调用信息交给RpcProcessor来控制调用逻辑，最后将调用信息传递给RpcInvoker实际执行调用并返回结果给客户端。
--------------------- 作者：云水之路 来源：CSDN 原文：https://blog.csdn.net/why_2012_gogo/article/details/79425338?utm_source=copy 版权声明：本文为博主原创文章，转载请附上博文链接！