RPC要解决的两个问题
解决分布式系统中，服务之间的调用问题。
远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
RPC核心功能
客户端(Client)：服务调用方。
客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
服务端存根(Server Stub)：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
服务端(Server)：服务的真正提供者。
Network Service：底层传输，可以是 TCP 或 HTTP。
实现三个技术点，分别是：服务寻址、数据流的序列化和反序列化、网络传输。
服务寻址
服务寻址可以使用 Call ID 映射。在本地调用中，函数体是直接通过函数指针来指定的，但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。
所以在 RPC 中，所有的函数都必须有自己的一个 ID。这个 ID 在所有进程中都是唯一确定的。
客户端在做远程过程调用时，必须附上这个 ID。然后我们还需要在客户端和服务端分别维护一个函数和Call ID的对应表。
当客户端需要进行远程调用时，它就查一下这个表，找出相应的 Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
实现方式：服务注册中心。
要调用服务，首先你需要一个服务注册中心去查询对方服务都有哪些实例。Dubbo 的服务注册中心是可以配置的，官方推荐使用 Zookeeper。
序列化和反序列化
客户端怎么把参数值传给远程的函数呢?在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。
但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。
这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。
只有二进制数据才能在网络中传输，序列化和反序列化的定义是：
将对象转换成二进制流的过程叫做序列化
将二进制流转换成对象的过程叫做反序列化
这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
网络传输
网络传输：远程调用往往用在网络上，客户端和服务端是通过网络连接的。
所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把 Call ID 和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。
只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。
尽管大部分 RPC 框架都使用 TCP 协议，但其实 UDP 也可以，而 gRPC 干脆就用了 HTTP2。
TCP 的连接是最常见的，简要分析基于 TCP 的连接：通常 TCP 连接可以是按需连接(需要调用的时候就先建立连接，调用结束后就立马断掉)，也可以是长连接(客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效)，多个远程过程调用共享同一个连接。
网络方式：基于TCP、基于HTTP、基于MQ。
RPC vs Restful
RPC是面向过程，Restful是面向资源，并且使用了Http动词。从这个维度上看，Restful风格的url在表述的精简性、可读性上都要更好。
面对对象不同：
RPC 更侧重于动作。
REST 的主体是资源。
RESTful 是面向资源的设计架构，但在系统中有很多对象不能抽象成资源，比如登录，修改密码等而 RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 RESTful。
传输效率：
RPC 效率更高。RPC，使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率。
复杂度：
RPC 实现复杂，流程繁琐。
REST 调用及测试都很方便。
RPC 实现(参见***节)需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。
灵活性：
HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议。
RPC 可以实现跨语言调用，但整体灵活性不如 RESTful。
摘自https://developer.51cto.com/art/201906/597963.htm
RPC原理
RPC 是指计算机 A 上的进程，调用另外一台计算机 B 上的进程，其中 A 上的调用进程被挂起，而 B 上的被调用进程开始执行，当值返回给 A 时，A 进程继续执行。调用方可以通过使用参数将信息传送给被调用方，而后可以通过传回的结果得到信息。
远程过程调用包含如下步骤：
- 客户过程以正常的方式调用客户存根；
- 客户存根生成一个消息，然后调用本地操作系统；
- 客户端操作系统将消息发送给远程操作系统；
- 远程操作系统将消息交给服务器存根；
- 服务器存根调将参数提取出来，而后调用服务器；
- 服务器执行要求的操作，操作完成后将结果返回给服务器存根；
- 服务器存根将结果打包成一个消息，而后调用本地操作系统；
- 服务器操作系统将含有结果的消息发送给客户端操作系统；
- 客户端操作系统将消息交给客户存根；
- 客户存根将结果从消息中提取出来，返回给调用它的客户存根。
以上步骤就是将客户过程对客户存根发出的本地调用转换成对服务器过程的本地调用，而客户端和服务器都不会意识到中间步骤的存在。
摘自https://waylau.com/remote-procedure-calls/
总结
RPC 主要用于公司内部的服务调用，性能消耗低，传输效率高，实现复杂。
HTTP 主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。
RPC 使用场景(大型的网站，内部子系统较多、接口非常多的情况下适合使用 RPC)：
长链接。不必每次通信都要像 HTTP 一样去 3 次握手，减少了网络开销。
注册发布机制。RPC 框架一般都有注册中心，有丰富的监控管理;发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
安全性，没有暴露资源操作。
微服务支持。就是最近流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。