共计 2511 个字符，预计需要花费 7 分钟才能阅读完成。
作者：易哥
链接：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 好，两者各有千秋。实质上，两者是 可读性和效率之间的抉择 ， 通用性和易用性之间的抉择。最终谁能倒退更好，很难说。
要问我站谁？我 依据业务场景，灵便站位……
如果还有什么没说分明，能够留言探讨。