既然有http 请求,为什么还要用rpc调用?

该提问也确实有点问题:HTTP和RPC不是对等的概念。

RPC是一个完整的远程调用方案,它包括了:接口规范+序列化反序列化规范+通信协议等。

而HTTP只是一个通信协议,工作在OSI的第七层,不是一个完整的远程调用方案。


所以,要想回答这个问题,应该拉平为一个对等的概念。例如,HTTP+Restful规范+序列化与反序列化,构成一个完整的远程调用方案,再和RPC进行比较。而单纯的HTTP,只是一个通信协议,自然无法和RPC比较。

这就像是牛(HTTP)不能和马车(RPC)比较。要想比较,就应该将牛补齐为牛车,然后和马车比较。

感觉题主应该是问:基于HTTP的远程调用方案(包含了接口规范、序列化反序列化等) 和 使用RPC的远程调用方案 有什么不同。有了前者,为什么还要有后者。

首先:

http 和 rpc 并不是一个并行概念。

http是超文本传输协议,应用层网络协议。

rpc不是协议,是指remote procedure call 远程过程调用,对不同应用间相互调用的一种描述。其调用协议通常包含传输协议和编码协议;支持http和tcp;

其次:

rpc调用是面向服务的封装,针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

例如rpc框架提供的负载均衡,服务治理,自动熔断/降级,实现二进制传输等;

如果把一个http server容器上封装一层服务发现和函数代理调用,那它就已经可以做一个rpc框架了。

总结:

RPC是一种编程模式,把对服务器的调用抽象为过程调用,通常伴随着框架代码自动生成等功能。使用RPC做网络服务开发时,通常只需要实现服务器端的一个处理函数,其余的客户端调用,序列化反序列化,方法派发等都由框架或者生成的代码来完成,较大地减轻了网络服务开发和调用的复杂性。RPC框架更多的在内网中应用间调用使用,http 除了内网传输,更习惯用在跨网间,跨语言间调用。

我们先介绍基于HTTP的远程调用方案。

HTTP+Restful,其优势很大。它可读性好,且可以得到防火墙的支持、跨语言的支持。而且,在近几年的报告中,Restful大有超过RPC的趋势。

但是使用该方案也有其缺点,这是与其优点相对应的:

首先是有用信息占比少,毕竟HTTP工作在第七层,包含了大量的HTTP头等信息。
其次是效率低,还是因为第七层的缘故,必须按照HTTP协议进行层层封装。
还有,其可读性似乎没有必要,因为我们可以引入网关增加可读性。
此外,使用HTTP协议调用远程方法比较复杂,要封装各种参数名和参数值。
而RPC则与HTTP互补,我们详细介绍下。

看完这篇回答,能让你对RPC的产生、原理、实现代码都有着清晰的了解。这样,也能在业务系统中,在RPC和HTTP之间做好抉择。

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

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

版权声明:本文为作者原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原创文章,作者:老C,如若转载,请注明出处:https://www.code404.icu/523.html

发表评论

登录后才能评论