既然有 HTTP 请求,为什么还要用 RPC 调用?

Posted 架构研究所

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了既然有 HTTP 请求,为什么还要用 RPC 调用?相关的知识,希望对你有一定的参考价值。

首先,实名赞扬题主的问题。这个问题非常好


其次,实名反对各个上来就讲RPC好而HTTP不好的答案。因为,题主的观点非常对


HTTP协议,以其中的Restful规范为代表,其优势很大。它可读性好,且可以得到防火墙的支持、跨语言的支持。而且,在去年的报告中,Restful大有超过RPC的趋势

本想引用下报告内容,无奈最近由于某些原因,KeXueShangWang被Qiang了。等我日后出墙时,再做补充。

但是HTTP也有其缺点,这是与其优点相对应的。首先是有用信息占比少,毕竟HTTP工作在第七层,包含了大量的HTTP头等信息。其次是效率低,还是因为第七层的缘故。还有,其可读性似乎没有必要,因为我们可以引入网关增加可读性。此外,使用HTTP协议调用远程方法比较复杂,要封装各种参数名和参数值。


而RPC则与HTTP互补,我们详细介绍下。看完这篇回答,能让你对RPC的产生、原理、实现代码都有着清晰的了解。这样,也能在业务系统中,在RPC和HTTP之间做好抉择。


但需要再说一句,不是说RPC好,也不是说HTTP好,两者各有千秋,还在比拼中


要问我站谁?我根据业务场景,灵活站位……



RPC的英文全称是Remote Procedure Call,翻译为中文叫“远程过程调用”。其中稍显晦涩的其实就是“过程”,过程其实就是方法。所以,可以把RPC理解为“远程方法调用”。


要了解远程过程调用,那先理解过程调用。非常简单,如下图,就是调用一个方法。这太常见了,不多解释。

而在分布式系统中,因为每个服务的边界都很小,很有可能调用别的服务提供的方法。这就出现了服务A调用服务B中方法的需求,即远程过程调用。


要想让服务A调用服务B中的方法,最先想到的就是通过HTTP请求实现。是的,这是很常见的,例如服务B暴露Restful接口,然后让服务A调用它的接口。基于Restful的调用方式因为可读性好(服务B暴露出的是Restful接口,可读性当然好)而且HTTP请求可以通过各种防火墙,因此非常不错。


然而,如前面所述,基于Restful的远程过程调用有着明显的缺点,主要是效率低、封装调用复杂。当存在大量的服务间调用时,这些缺点变得更为突出。


服务A调用服务B的过程是应用间的内部过程,牺牲可读性提升效率、易用性是可取的。基于这种思路,RPC产生了。


通常,RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口,就相当于调用了被调用方的实际方法,十分易用。于是,调用方可以像调用内部接口一样调用远程的方法,而不用封装参数名和参数值等操作。

既然有 HTTP 请求,为什么还要用 RPC 调用?

那要想实现这个过程该怎么办呢?别急,咱们一步一步来。


首先,调用方调用的是接口,必须得为接口构造一个假的实现。显然,要使用动态代理。这样,调用方的调用就被动态代理接收到了。


第二,动态代理接收到调用后,应该想办法调用远程的实际实现。这包括下面几步:


  • 识别具体要调用的远程方法的IP、端口

  • 将调用方法的入参进行序列化

  • 通过通信将请求发送到远程的方法中


这样,远程的服务就接收到了调用方的请求。它应该:

  • 反序列化各个调用参数

  • 定位到实际要调用的方法,然后输入参数,执行方法

  • 按照调用的路径返回调用的结果


整个过程如下所示。

既然有 HTTP 请求,为什么还要用 RPC 调用?

这样,RPC操作就完成了。


调用方调用内部的一个方法,但是被RPC框架偷梁换柱为远程的一个方法。之间的通信数据可读性不需要好,只需要RPC框架能读懂即可,因此效率可以更高。通常使用UDP或者TCP作为通讯协议,当然也可以使用HTTP。例如下面的示例中,为了保证实现最简单,就用了HTTP进行通信。


讲到这里,RPC的产生原因、原理应该清楚了。为了让大家真的明白,我写了一个真的是最最简单的RPC实现。把它放到了:


https://github.com/yeecode/EasyRPC


它包含一个客户端,一个服务端。客户端只要调用自身内部的接口,就通过这个小的RPC实现调用到了服务端的方法。


下面是客户端的代码,看着类有点多,其实代码不长。其中的RPC代码完成完成动态代理、远程调用参数序列化、远程调用发起、远程调用结果反序列化的工作。


RPC客户端


下面是服务端的代码,代码更少,完成远程调用接收、调用参数反序列化、调用实际触发、调用结果序列化的工作。


RPC服务端


这样,一个RPC小框架就做完了,并不复杂。


所以,不要被RPC吓到,它就是让一个应用调用另一个应用中方法的一种实现方式。与调用远程接口区别不大,条条大路通罗马。


再说一次,不是说RPC好,也不是说HTTP好,两者各有千秋。本质上,两者是可读性和效率之间的抉择通用性和易用性之间的抉择。最终谁能发展更好,很难说。


要问我站谁?我根据业务场景,灵活站位……



如果还有什么没说清楚了,可以留言再问。





该回答转载自我的知乎,欢迎前往知乎关注我.

易哥 https://www.zhihu.com/people/yeecode



以上是关于既然有 HTTP 请求,为什么还要用 RPC 调用?的主要内容,如果未能解决你的问题,请参考以下文章

既然有 HTTP 请求,为什么还要用 RPC 调用?

既然有HTTP协议,为什么还要有RPC

既然有HTTP协议,为什么还要有RPC

既然有HTTP协议,为什么还要有RPC

微服务http与RPC

微服务http与RPC