RPC应该是一种高层次的，语言层次的，而不是像IPC（ 本地套接字接口（IPC Socket） ）那种低层次，系统层次的东西，我来为大家科普一下关于rpc远程调用原理?以下内容希望对你有帮助!
rpc远程调用原理
1.远程服务调用（Remote Procedure Call，RPC）RPC应该是一种高层次的，语言层次的，而不是像IPC（ 本地套接字接口（IPC Socket） ）那种低层次，系统层次的东西
2.RPC协议框架- RMI（Sun/Oracle）、Thrift（Facebook/Apache）、Dubbo（阿里巴巴 /Apache）、gRPC（Google）、Motan2（新浪）、Finagle（Twitter）、brpc（百度）、.NET Remoting（微软）、Arvo（Hadoop）、JSON-RPC 2.0（公开规范，JSON-RPC 工作组）
- RPC 出现的最初目的，就是为了让计算机能够跟调用本地方法一样，去调用远程方法。
- 进程间值如何进行通讯
第一，管道（Pipe）或具名管道（Named Pipe ）
- 管道其实类似于两个进程间的桥梁，用于进程间传递少量的字符流或字节流。
- 普通管道可用于有亲缘关系进程间的通信（由一个进程启动的另外一个进程）；
- 而具名管道摆脱了普通管道没有名字的限制，除了具有普通管道所具有的功能以外，它还允许无亲缘关系进程间的通信。
- 管道典型的应用就是命令行中的“ | ”操作符，比如说，命令“ps -ef | grep java” ，就是管道操作符“ | ”将 ps 命令的标准输出通过管道，连接到 grep 命令的标准输入上。
第二，信号（Signal）
- 信号是用来通知目标进程有某种事件发生的。除了用于进程间通信外，信号还可以被进程发送给进程自身。信号的典型应用是 kill 命令，比如“kill -9 pid”，意思就是由 Shell 进程向指定 PID 的进程发送 SIGKILL 信号。
第三，信号量（Semaphore）
- 信号量是用于两个进程之间同步协作的手段，相当于操作系统提供的一个特殊变量。我们可以在信号量上，进行 wait() 和 notify() 操作
第四，消息队列（Message Queue）
- 也就是说，进程可以向队列中添加消息，而被赋予读权限的进程则可以从队列中消费消息。消息队列就克服了信号承载信息量少、管道只能用于无格式字节流，以及缓冲区大小受限等缺点 ，但实时性相对受限。
第五，共享内存（Shared Memory）
- 允许多个进程可以访问同一块内存空间，这是效率最高的进程间通讯形式。
- 进程的内存地址空间是独立隔离的，但操作系统提供了让进程主动创建、映射、分离、控制某一块内存的接口。
- 由于内存是多进程共享的，所以往往会与其它通信机制，如信号量等结合使用，来达到进程间的同步及互斥。
第六，本地套接字接口（IPC Socket）
- 消息队列和共享内存这两种方式，只适合单机多进程间的通讯。而套接字接口，是更为普适的进程间通信机制，可用于不同机器之间的进程通信。
- 基于效率考虑，当仅限于本机进程间通讯的时候，套接字接口是被优化过的，不会经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等操作，只是简单地将应用层数据从一个进程拷贝到另一个进程，这种进程间通讯方式有个专有的名称：Unix Domain Socket，又叫做 IPC Socket。
- 表示数据
- 传递数据
- 表示方法
面向对象发展
- 在分布式系统中，开发者们不再满足于 RPC 带来的面向过程的编码方式，而是希望能够进行跨进程的面向对象编程
- 这条线有一个别名叫作分布式对象（Distributed Object），它的代表有 RMI、.NET Remoting
向性能发展
- 代表为 gRPC 和 Thrift。决
- 定 RPC 性能主要就两个因素：序列化效率和信息密度。
- 序列化输出结果的容量越小，速度越快，效率自然越高
- 信息密度则取决于协议中，有效荷载（Payload）所占总传输数据的比例大小
向简化发展
- 代表为 JSON-RPC
- 它牺牲了功能和效率，换来的是协议的简单
- JSON-RPC 的接口与格式的通用性很好，尤其适合用在 Web 浏览器这类一般不会有额外协议、客户端支持的应用场合
RPC 框架有明显朝着更高层次（不仅仅负责调用远程服务，还管理远程服务）与插件化方向发展的趋势，不再选择自己去解决表示数据、传递数据和表示方法这三个问题，而是将全部或者一部分问题设计为扩展点，实现核心能力的可配置，再辅以外围功能，如负载均衡、服务注册、可观察性等方面的支持。这一类框架的代表，有 Facebook 的 Thrift 和阿里的 Dubbo（现在两者都是 Apache 的）
,
