Java手写RPC框架资料推荐

最新推荐文章于 2024-10-11 17:30:36 发布

a javaer

最新推荐文章于 2024-10-11 17:30:36 发布

阅读量713

点赞数 18

文章标签： java rpc 开发语言

本文链接：https://blog.csdn.net/qq_42939279/article/details/140997952

版权

什么是RPC，及其发展历程

PS：本段是对RPC发展历程的介绍，基本引自《凤凰架构》博客中的内容

RPC全称为Remote Procedure Call，远程服务调用。

它的最初目的是为了让计算机能够跟调用本地方法一样去调用远程方法。

最开始关于RPC的研究，往往将RPC视为一种进程间通信的特例。为什么呢？因为我们考虑java中调用一个本地方法时的几个步骤：

传递方法参数
确定方法版本
执行被调方法
返回执行结果

这是调用的方法就在当前进程的内存空间中的情况。如果方法本身不在当前进程的内存空间呢？会发生什么问题？

首先，第一步和第四步所做的传递参数、传回结果都依赖于栈内存的帮助，如果Caller与Callee分属不同的进程，就不会拥有相同的栈内存，将参数在Caller进程的内存中压栈，对于 Callee 进程的执行毫无意义。其次，第二步的方法版本选择依赖于语言规则的定义，如果Caller与Callee不是同一种语言实现的程序，方法版本选择就将是一项模糊的不可知行为。（本段摘自凤凰架构）

忽略第二个问题，我们考虑语言相同的情况。那么对于第一个问题，我们需要进程间通信的手段来交换数据。

进程间通信手段很多包括：管道，信号，信号量，消息队列，共享内存，socket通信等
我们更进一步，方法不仅不在当前进程的内存空间，还与当前进程不在同一机器上。这不就十分接近我们所说的RPC了吗。
其中socket通信似乎正好可以满足远程调用这一需求。且socket是操作系统都有的标准接口，最终实现RPC可以隐匿于底层。

所以最初的RPC构想，基本将RPC的实现层次降低到了操作系统层次，完完全全的符合所谓“跟调用本地方法一样去调用远程方法”。然而这种设计带来了调用上的不可感知，造成了程序员误以为通信是无成本的假象，因而其被滥用以致于显著降低了分布式系统的性能。

在后面一些学者提出了这样做的问题，最终有了对RPC的共识：RPC应该是一种高层次的、语言级别的特性，而不是低层次的、系统级别的特性。这意味着RPC的设计和实现应该更加注重抽象和封装，以便开发者能够更加方便地调用远程服务，而无需关心底层的通信细节。

1987 年，在“透明的 RPC 调用”一度成为主流范式的时候，Andrew Tanenbaum 教授曾发表了论文《A Critique of The Remote Procedure Call Paradigm》，对这种透明的 RPC 范式提出了一系列质问：
两个进程通信，谁作为服务端，谁作为客户端？
怎样进行异常处理？异常该如何让调用者获知？
服务端出现多线程竞争之后怎么办？
如何提高网络利用的效率，譬如连接是否可被多个请求复用以减少开销？是否支持多播？
参数、返回值如何表示？应该有怎样的字节序？
如何保证网络的可靠性？譬如调用期间某个链接忽然断开了怎么办？
发送的请求服务端收不到回复该怎么办？
……
1994 年至 1997 年间，由 ACM 和 Sun 院士Peter Deutsch、套接字接口发明者Bill Joy、Java 之父James Gosling等一众在 Sun Microsystems 工作的大佬们共同总结了通过网络进行分布式运算的八宗罪（8 Fallacies of Distributed Computing）：
The network is reliable —— 网络是可靠的。
Latency is zero —— 延迟是不存在的。
Bandwidth is infinite —— 带宽是无限的。
The network is secure —— 网络是安全的。
Topology doesn’t change —— 拓扑结构是一成不变的。
There is one administrator —— 总会有一个管理员。
Transport cost is zero —— 不必考虑传输成本。
The network is homogeneous —— 网络是同质化的。
以上这八条反话被认为是程序员在网络编程中经常被忽略的八大问题，潜台词就是如果远程服务调用要弄透明化的话，就必须为这些罪过埋单，这算是给 RPC 是否能等同于 IPC 来实现暂时定下了一个具有公信力的结论。至此，RPC 应该是一种高层次的或者说语言层次的特征，而不是像 IPC 那样，是低层次的或者说系统层次的特征成为工业界、学术界的主流观点。
引自《凤凰架构》