作者：易哥
链接：https://www.zhihu.com/questio...
起源：知乎
著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。
首先，实名投诉题主的问题。这个问题十分好。
其次，实名拥护各个上来就讲RPC好而HTTP不好的答案。因为，题主的观点十分对。
HTTP协定，以其中的Restful标准为代表，其劣势很大。它可读性好，且能够失去防火墙的反对、跨语言的反对。而且，在去年的报告中，Restful大有超过RPC的趋势。
本想援用下报告内容，无奈最近因为某些起因，KeXueShangWang被Qiang了。等我日后出墙时，再做补充。
然而HTTP也有其毛病，这是与其长处绝对应的。首先是有用信息占比少，毕竟HTTP工作在第七层，蕴含了大量的HTTP头等信息。其次是效率低，还是因为第七层的缘故。还有，其可读性仿佛没有必要，因为咱们能够引入网关减少可读性。此外，应用HTTP协定调用近程办法比较复杂，要封装各种参数名和参数值。
而RPC则与HTTP互补，咱们具体介绍下。看完这篇答复，能让你对RPC的产生、原理、实现代码都有着清晰的理解。这样，也能在业务零碎中，在RPC和HTTP之间做好抉择。
但须要再说一句，不是说RPC好，也不是说HTTP好，两者各有千秋，还在比拼中。
要问我站谁？我依据业务场景，灵便站位……
评论区产生了一些争执，我在这里对立进行阐明。争执次要产生在两点：
1、HTTP和RPC同一级别，还是被RPC蕴含？
2、Restful也属于RPC么？
对于以上两点，我画图来一一阐明。
上图是一个比拟残缺的关系图，这时咱们发现HTTP（图中蓝色框）呈现了两次。其中一个是和RPC并列的，都是跨利用调用办法的解决方案；另一个则是被RPC蕴含的，是RPC通信过程的可选协定之一。
因而，第一个问题的答案是都对。看指的是哪一个蓝色框。从题主的发问看，既然题主在纠结这两者，应该是指与RPC并列的蓝色框。
第二个问题是在问近程过程调用（红色框）是不是蕴含了Restful（黄色框），这种了解的关键在于对RPC的了解。
RPC字面了解是近程过程调用，即在一个利用中调用另一个利用的办法。那Restful是满足的，通过它能够实现在一个利用中调用另一个利用的办法。
然而，上述了解使得RPC的定义过于宽泛。RPC通常特指在一个利用中调用另一个利用的接口而实现的近程调用，即红色框所指的范畴。这样，RPC是不蕴含Restful的。
因而，第二个问题的答案是Restful不属于RPC，除非对RPC有着非常规的宽泛了解。
RPC的英文全称是Remote Procedure Call，翻译为中文叫“近程过程调用”。其中稍显艰涩的其实就是“过程”，过程其实就是办法。所以，能够把RPC了解为“近程办法调用”。
要理解近程过程调用，那先了解过程调用。非常简单，如下图，就是调用一个办法。这太常见了，不多解释。
而在分布式系统中，因为每个服务的边界都很小，很有可能调用别的服务提供的办法。这就呈现了服务A调用服务B中办法的需要，即近程过程调用。
要想让服务A调用服务B中的办法，最先想到的就是通过HTTP申请实现。是的，这是很常见的，例如服务B裸露Restful接口，而后让服务A调用它的接口。基于Restful的调用形式因为可读性好（服务B暴露出的是Restful接口，可读性当然好）而且HTTP申请能够通过各种防火墙，因而十分不错。
然而，如后面所述，基于Restful的近程过程调用有着显著的毛病，次要是效率低、封装调用简单。当存在大量的服务间调用时，这些毛病变得更为突出。
服务A调用服务B的过程是利用间的外部过程，就义可读性晋升效率、易用性是可取的。基于这种思路，RPC产生了。
通常，RPC要求在调用方中搁置被调用的办法的接口。调用方只有调用了这些接口，就相当于调用了被调用方的理论办法，非常易用。于是，调用方能够像调用外部接口一样调用近程的办法，而不必封装参数名和参数值等操作。
那要想实现这个过程该怎么办呢？别急，咱们一步一步来。
首先，调用方调用的是接口，必须得为接口结构一个假的实现。显然，要应用动静代理。这样，调用方的调用就被动静代理接管到了。
第二，动静代理接管到调用后，应该想方法调用近程的理论实现。这包含上面几步：
- 辨认具体要调用的近程办法的IP、端口
- 将调用办法的入参进行序列化
- 通过通信将申请发送到近程的办法中
这样，近程的服务就接管到了调用方的申请。它应该：
- 反序列化各个调用参数
- 定位到理论要调用的办法，而后输出参数，执行办法
- 依照调用的门路返回调用的后果
整个过程如下所示。
这样，RPC操作就实现了。
调用方调用外部的一个办法，然而被RPC框架移花接木为近程的一个办法。之间的通信数据可读性不须要好，只须要RPC框架能读懂即可，因而效率能够更高。通常应用UDP或者TCP作为通信协定，当然也能够应用HTTP。例如上面的示例中，为了保障实现最简略，就用了HTTP进行通信。
讲到这里，RPC的产生起因、原理应该分明了。为了让大家真的明确，我写了一个真的是最最简略的RPC实现。把它放到了：
https://github.com/yeecode/EasyRPCgithub.com
它蕴含一个客户端，一个服务端。客户端只有调用本身外部的接口，就通过这个小的RPC实现调用到了服务端的办法。
上面是客户端的代码，看着类有点多，其实代码不长。其中的RPC代码实现实现动静代理、近程调用参数序列化、近程调用发动、近程调用后果反序列化的工作。
RPC客户端
上面是服务端的代码，代码更少，实现近程调用接管、调用参数反序列化、调用理论触发、调用后果序列化的工作。
RPC服务端
这样，一个RPC小框架就做完了，并不简单。
所以，不要被RPC吓到，它就是让一个利用调用另一个利用中办法的一种实现形式。与调用近程接口区别不大，条条大路通罗马。
再说一次，不是说RPC好，也不是说HTTP好，两者各有千秋。实质上，两者是可读性和效率之间的抉择，通用性和易用性之间的抉择。最终谁能倒退更好，很难说。
要问我站谁？我依据业务场景，灵便站位……
如果还有什么没说分明，能够留言探讨。