RPC 和 http 相比优势在哪里?

[chaleaochexist]

其实我的实际问题是:

http 比 RPC 开发更快速高效简单

为什么服务和服务内部的通信不能使用 http 而要用GRPC?

是因为高效? 高效在哪里? GRPC 是基于 HTTP2 的.

因为 SDK? 为什么一定要开发一套 SDK? 用通用的 http 库不行吗?

HTTP 难道不是跨语言的吗?

站内搜索遇到过类似的问题

https://www.v2ex.com/t/709864

https://v2ex.com/t/656766

还是理解不了.

1. RPC 出现比 http 早
2. RPC 和 http 不是同一概念无法比较 这两类观点楼主已经了解. 感谢.

大白话重新描述问题:
一个 api 可以用 restful api 表达 也可以用 GRPC 表达.
为什么要选择用 GRPC, 而不是 restful api?

1. protobuf 的优势 -- 其他 RPC 也可以自定义自己的二进制协议. 但是 http 是文本协议.
1.1 如果基于 http 做出了基于文本协议的二进制协议. 那其实也可以称之为另一种 RPC 实现.
2. RPC 可以基于 tcp 也可以基于 http. 无论基于什么, 最终的表现形式就是 调用一个 api(通过远程方式).
当然 restful api 也同样是通过远程方式调用一个 api. 只不过 http 协议本身支持的功能是有限的. 譬如:
1) protocol buffers
2) 连接池
3) 参数如何表达
4) 返回值如何表达
5) "服务发现"，"负载均衡"，"熔断降级"
如果将这些功能都加进来, 实际上就变成了 RPC
3. RPC 本身也有很多分类 譬如 简单的 json-RPC. 高效的 GPRC...

总之,RPC 有很多种表现形式,RPC 的裁剪能力是很强的.各种各样的 RPC 实现满足了各种各样的需求.
但是 http 协议本身的限制以及基于 http 的生态(nginx) 限制了 restful api 做为服务内部通信的发展.

我可以这么理解吗?

感谢楼下所有人的解答. 谢谢谢谢!!!!

[thinkershare]

HTTP 比 RPC(这里特指 GRPC) 开发更快速高效简单? 这个观念不知道你怎么有的，HTTP 现在一点也不简单。
HTTP 创建之初就是为纯文本通讯而设计的,它天然的通讯协议开销是无法通过技术手段消除的，HTTP2/HTTP3 都无法解决这个问题，虽然它们做了很多优化和压缩。
gRPC 这个设计最初就是为服务之间的相互通讯设计的，它一开始就采用了和语言无关的二进制通讯模式，这使得它天然更加适合服务通讯，HTTP 协议提供的很多功能在服务相互调用时根本不需要。

[chaleaochexist]

@thinkershare 总结一句话就是 GRPC 更高效
但问题是 GRPC 高效在哪里 除了 protobuf vs json?
我的理解 GRPC 本身是基于 http2 的那么无法规避 http2 的任何低效问题.

我可以这么理解吗?

[buaacss]

开发过一个分布式任务调度系统，我的理解是

1 、grpc 上带有 context ，可以双向超时+取消，只要长链接中断就可以各自执行中断处理。
2 、grpc 支持双向 stream ，这对于一些要求获取远程调用实时输出的程序很友好。
3 、对于一般业务来说和 http 相比没有优势

[chaleaochexist]

@thinkershare 我说的开发更快速高效简单是指开发效率而不是运行效率.

[chaleaochexist]

@buaacss 感谢.

[chaleaochexist]

@buaacss 不过
1. 双向超时和取消 http 也有办法做到啊. timeout 参数, 取消的话我不是很了解 GRPC 是如何实现的, 等我天亮了去学习一下.
2. 双向 stream 是不是 websocket 也可以实现.
3. 我认同 哈哈....

[wangnimabenma]

没在生产环境用过，但是我的理解是

[chaleaochexist]

@wangnimabenma 是啥?

[wangnimabenma]

没在生产环境用过，但是我的理解是
1. 基于 http2.0 比 1.1 传输高效（多路复用什么的）
2. Keepalive 机制
3. *.proto 的文件定义比看文档方便
4. 协议帧的二进制通讯，提高了 API 被爬的门槛

[thinkershare]

@chaleaochexist
1：protocol buffers 和任何基于文本的序列化性能差异是很大的，它是一个规范，只要最终大家都支持，那它就会成为 HTTP 那样的共识协议，这个共识在二进制序列化上要达成只要 google 这种全球化的公司才有可能完成。
2：HTTP 2 通过新的链接复用，在传输上已经解决了低效问题，然后就是对基于文本头的魔值定义再次压缩的通讯的协议头大小，基本上在传输上效率大大提高了，但它的核心问题还是 body 部分需要一个统一的二进制规范。
3. 最核心的是 HTTP 协议有很多功能是为服务器-浏览器模式定制的，这些功能在服务器-服务器的时候没啥作用，这部分功能在 gRPC 通讯层可以和直接屏蔽掉，不对最终消费 gRPC 的用户开放。

[wangnimabenma]

还有强类型定义说漏了

[haozibi]

个人理解

RPC ，client 像调用本地函数一样调用接口，语义更加明确，更加规范，无需关心连接、序列化等细节，这些都由 RPC 框架帮你做了

「通用的 HTTP 库」，如果这个库把连接池、编码等等功能都实现了，调用方每个接口的调用无须做重复性劳动，那么这个「通用的 HTTP 库」何尝不是一个 RPC

[leonshaw]

> 2. RPC 和 http 不是同一概念无法比较

既然你已经了解，为啥还会提出这个问题？你所说的 http 是特指 HTTP 1.x 还是包括 HTTP2 ？如果是前者，就 gRPC 而言，先了解一下 HTTP2 比 HTTP 1.1 的优势。如果是后者，就好像在问 HTTP 和 TCP 相比优势在哪里。

[Chingim]

@leonshaw 不懂就问，rpc 是不是基于 tcp 的上层封装？
如果是，那应当能跟 http 比较一番才对

[b1ghawk]

@Chingim rpc 在其协议内容里，直接支持"RPC"概念集里的各类元素，例如：过程、过程参数、参数类型、参数长度、返回类型等等...
而 http 的协议内容里并没有上述概念(面向资源)，需要在 http 协议之上，继续进行一些有关于 RPC 的封装，或者将 http 协议当中既有的某些元素映射成 rpc 里的某些元素。

其实用 ftp 当作 rpc 来用也可以吧……只是程序员面向的概念集不一样，ftp 里是 上传，下载，路径，要做一些额外的工作才可以当作 rpc 来用，但与 http 类似，均比原生 rpc 协议更加低效。

这种场景下，有什么理由不直接使用 rpc 的原生协议呢？合适的场景选择合适的工具，砍树用美工刀，切菜用老虎钳，拍蒜泥用枕头。能用，但不适合...

[leonshaw]

@Chingim 不是，RPC 可以基于任何通信方式（例如 UDP 、IP 甚至串口通信协议），基于 HTTP2 的 gRPC 显然和 HTTP 不在同一层。即使都是基于 TCP ，也未必有比较的意义，例如 HTTP 和 SSH 有啥好比较的呢？

[cassyfar]

我觉得 rpc 99% 的优势就是高效，其他都是添头。百万级 qps 以下服务用哪个都无所谓。

[yueji]

grpc 不能 cdn...

[chendy]

比较不了
RPC 是远程服务调用，强调可以像调用本地方法一样调用远程方法，具体是怎么调用的不管
HTTP 是一应用层协议
部分 RPC 的底层是 HTTP

http 手撸需要处理各种细节，rpc 通常就是写好 idl 生成代码，再把服务端逻辑写好就能用了

[buaacss]

楼上有补充强类型的，我也再来贡献各 case 。文本协议比特位翻转导致数据库更新了全表。

update xxx set a=1,b=2,c=3 where id=xxx;

被宇宙射线击中后，3 变成了#，导致后面的文本直接变成了注释

3 的二进制是 00110011
#的二进制是 00100011

第一次看到我都吓傻了

[swulling]

这两个无法比较。虽然大家都知道你比的其实是 GRPC 和 HTTP API 实现。但是你的标题就不正确，好比比较 大众汽车和米其林轮胎那个更好一样。

[sofukwird]

因为 grpc 反序列化比 json 节省资源，json 从头扫描到尾，而 grpc 精确打击(protobuf 标记了数据位置)，一次即可反序列化

[wanguorui123]

RPC 有标准的数据结构和映射描述文档而且是公开的可自动生成本地远程调用方法使用更容易
非标准的 HTTP 接口传参不统一调用麻烦点

[dearmymy]

rpc 是一种编程概念，就是远程调用。
http 只是一种实现而已。你单独 socket 实现也行。
http 本身不是为了 rpc 出生。但是适合绝大部分情况了。

[MakHoCheung]

你没搞清楚两者关系，#24 把关系说得很清楚了。
“为什么服务和服务内部的通信不能使用 http 而要用 GRPC?” 没说不行，Spring Cloud 推荐的 Feign 就是基于 HTTP 的 RPC

[ql562482472]

grpc 跨语言定义接口 不需要自行去写各自实现 这就是开发高效的体现啊

[gaozhy]

我认为 rpc 是跨程序或者系统调用的方法总称，http 只是一种协议，实现 rpc 过程的方法可以是 tcp 协议也可以是 http 协议，也就是数据是载体，协议是实现 rpc 的交通工具

[robin700]

在 op 所说的服务通信场景下，以 grpc 为例大致有这些优势
1. 基于 HTTP2 组帧压缩、TCP 连接多路复用等特性，提供了低延时高吞吐
2. Protobuf 序列化的消息始终小于等效的 JSON 消息
3. 出色的对双向流式传输可以实时推送接收消息，无需轮询
4. 多语言支持和代码生成，节约大量开发时间
5. http api 没有正式规范，站内的的争论也很多，gRpc 规范消除了争论，节省了开发时间

[zhangyq008]

成熟的 rpc 库相对 http 容器，更多的是封装了“服务发现”，"负载均衡"，“熔断降级”一类面向服务的高级特性。
rpc 框架是面向服务的更高级的封装，针对服务的可用性和效率等都做了优化。单纯使用 http 调用缺少了这些特性。
而且使用类似 grpc gateway 类似插件也可以提供外部 http 服务，也很方便。

[chaleaochexist]

@thinkershare #10
感谢回复.
1 和 2 我的理解 归根到底还是 protobuf 的优势.
3. GRPC 能屏蔽掉, 而 http 无法屏蔽说白了是因为基于 http 的服务器和 http 客户端没有屏蔽. 而 RPC(譬如 GRPC)的自定义能力比较强. 所以可以屏蔽 我这么理解对吗?

那我差不多理解了. 你说的我认同. 谢谢.
===============
最后一句话总结, RPC 运行效率高.

[chaleaochexist]

@haozibi 感谢我之前没想到这层.

[chaleaochexist]

@leonshaw # 13
因为我并不认可.
RPC 当然和 http 不是一个概念. 但是问的问题关键点不在这里.
用大白话描述就是:
一个 api 可以用 restful api( http)表达 也可以用 RPC(GRPC)表达.
为什么要选择用 GRPC, 而不是 restful api.

[chaleaochexist]

@b1ghawk #15 我的理解 RPC 是有一组协议的. rfc-xxxx 但是针对的都不是 RPC 而是 RPC 衍生出的具体协议.
只要是远程调用都算 RPC 范畴, RPC 是一个抽象概念.

譬如 GRPC 有具体协议吗?

[chaleaochexist]

@MakHoCheung #25
#24 的回答属于我在主贴中的第 2 点.
http 和 RPC 不是可以比较的概念.引用#33 我的回复.
我认为二者的关系我有一定的认识.

另外 GRPC 就是基于 http2 的.

重点不在这里. 可能是我没描述清楚问题.

我想表达的是
一个 api 可以用 restful api( http)表达 也可以用 RPC(GRPC)表达.
为什么要选择用 GRPC, 而不是 restful api.

[jeesk]

看领导说用啥就用啥。 自己的项目随便搞。

[chaleaochexist]

@zhangyq008 #29 GRPC 没这些功能但是还是超级流行. 原因是什么呢?

[leonshaw]

@chaleaochexist 那应该是 gRPC vs RESTful API 而不是认为 RPC = gRPC ，HTTP = RESTful API 。况且你主题通篇没有提到 REST 。

话说回来，gRPC 和 RESTful API 仍然是不同层面的东西。RPC 和 RESTful 最大区别是不同的 API 设计风格，这应该也不是你想问的问题。

所以你想问的可能类似 gRPC vs JSON-RPC over HTTP/1.1 ，这个看上面大概已经有答案了。

[IvanLi127]

优势就是省得重新做了一个只支持 http 作为传输方案的 grpc ，并且还得不到他人的认可？

而且还能避免返回的状态码到底放哪里的狗血问题。

[documentzhangx66]

1.RPC 全称是 Remote Procedure Call ，是程序通信的一种方法。

2.HTTP 是通信协议。

3.RPC 与 HTTP ，两者概念不同，不能放在一起比较。

4.RPC 可以使用 HTTP ，也可以直接使用 UDP 二进制数据包。

5.gRPC 是谷歌开发的通信框架，由语言无关的协议 PB （ Protocol Buffers ） 与一套已经有多语言实现的 Server 与 Client SDK 组成，可以拿来直接用。

其中，PB 相当于 HTTP 、JSON ，Server 相当于 jsp + Tomcat 。

另外，Facebook 也有一套与 gRPC 类似的，叫 Thrift 。

6.最后回答你的问题，如果要说开发效率最高的 RPC 框架，放眼整个太阳系，必须是微软的 WCF 。用这玩意，你只需要写 Server 端的方法，剩下的 Server 端接口、Server 端通信代码、Client 端通信代码，太阳系第一 IDE：VS （ Visual Studio ）会帮你全部自动生成。

但如果论通信效率最高的通用型 RPC 框架，应该就是谷歌 gRPC 这一套的。

[chaleaochexist]

@leonshaw 是的, 我的标题有问题, 我也是在看楼上的回答中 慢慢反应过来的.
感谢大佬回复, 我在看你回答的过程中才反应过来 其实我真正想问的是 gRPC vs JSON-RPC 的区别.

[jones2000]

1. http, RPC 项目报价一样，http 基本就白菜价了，利润少（如果上集群，赚个机器和设备的费用）， 用 RPC 的报价就可以很高，收费的点可能很多， 都是自定义协议，内容大小控制（字节及的控制），长连接稳定 等等。
2. 开发是团队不一样, http 的基本外包搞下就行了，RPC 一般专业的 c++搞，再不济也是 java.

[iyaozhen]

其实 RPC 更多的是一种“设计模式”

你要直接对比 restful （ http/2 版本） 和 grpc ，那 grpc 也有很多优势，但这些明面上的优势，HTTP 也能做，但这样就变成了基于 HTTP 协议的 RPC 了（比如 http JSON-RPC ）。而且改动很多，那还不如另起炉灶，更方便做一些底层优化。

再说回 grpc ，其实是综合了传统基于 tcp 的 rpc 和 http 的优势，是个比较通用的方案，但实际上性能不行（相对），很多公司都自己搞了，比如字节的： https://github.com/cloudwego/kitex

[chaleaochexist]

@iyaozhen 所以归根到底 服务内部采用 RPC 进行通信的最终目的是 -- 性能?

[statumer]

grpc/thrift 这些 RPC 和 restful 比主要是功能更多，比如说可以保证类型安全，如果你会造点轮子实际上 restful 完全可以取代 RPC 。至于什么 protobuf 性能更好的说法就是搞笑的，和 simdjson 这种用上 SIMD 的 JSON 库比性能根本没优势。

[chaleaochexist]

@statumer GPRC 功能也没多多少啊?
那为什么这么流行.

[abcbuzhiming]

@chaleaochexist 为什么流行？因为它背后是 google ，爹好就牛逼，这是开源界定律之一（并不完全绝对，但是至少是必要条件之一）。否则 RPC 这东西人月神话时代就已经有基本原理结构的东西，不会一直到 GRPC 才火起来

[9ine]

FYI: https://grpc.io/about/

[zagfai]

我理解只在极端情况下使用 RPC 有优势，情况在下列条件并行出现时，大量的整型，极高的 RPS ，接口固定 5 年内不变。

[xhinliang]

HTTP 可以认为是 RPC 的一种。
传统意义上的 RPC 框架，包括 gRPC 、Dubbo 之类的，都会包含服务发现和服务治理，而这个是普通的 HTTP 所不具备的。
HTTP 做负载均衡更多是通过 Nginx 之类的反向代理实现，而 gRPC 在调用方就有路由表，是直连的。

再者，gRPC 框架附带了一些比如桩代码生成、Stream 等特性，这些传统的 HTTP Request/Response 模型可能要费点劲自己搞吧？

[lanlanye]

我认为 Google 的压缩算法是 gRPC 的优势，其他诸如强类型和一些额外的功能支撑之类的都不是重点。
另外因为不是纯文本协议，传输过程中不透明，不可读，通用性也明显不足，就我个人的意见来说一般场景使用纯文本应该更好。

[centralpark]

能问出这个问题，说明你至少现阶段完全不需要 rpc 。你这个比较严格来说是不成立的，http 也可以是 rpc 的一种通信方式，当然我理解你问的肯定是 http + json 和狭义的 rpc ，也就是 grpc/thrift 等的区别。

gRPC 无非就是 protobuf3 + http2 之上做了一些优化，而这些优化几乎只有在大厂才能体现出价值。比如说，大厂内部团队之间要撕逼，没有个 pb 定义的结构，到时候可有得扯皮。虽然 http+json 也有 swagger 和 jsonschema 等工具，但是远不如 pb 或者 thrift 类型丰富且成熟。在大厂里，序列化都可能会成为一个性能瓶颈，我记得之前公司从 thrift 转 pb ，还是 pb 转 thrift 来着，折腾了好久，性能也有很大提升。在这方面，json 序列化的性能就根本不在考虑范围内了。

对于小厂来说，真没必要上什么 rpc ，http + json 撑到上市都没问题。重要的是产品，而不是炫技。rpc 解决了大厂的问题，但是也是有代价的。举例来说，rpc 所谓的跨语言几乎都只是理论上的跨语言而已，gRPC 的 python 支持就没那么好，经常会和 multiprocessing 打架，大厂自然有框架组专门的人来解决，至少规避这个问题，小公司有吗？

最后，技术选型选的不只是某一个技术，更是一个公司的人员组织结构选型。小公司没那么多人，就别给自己找点没用的事儿干，除非你是面向简历编程。

[byte10]

http 有一个天然的缺点，就是一问一答，这样连接数的数量就有点小问题。HTTP2 应该算是解决了，可以双向通信了。至于 RPC 和 HTTP 区别 一楼描述差不多了。楼主说的他们是否存在开发效率这个是不太正确，RPC 也有基于 HTTP 的封装，主要是跟运行效率有些关系。

[fregie]

特性和优缺点讨论起来总是难舍难分,各有千秋,不如溯其根源
HTTP 根本上是文本传输协议,用来传输文本的
RPC 是远程调用,调用一个接口
在微服务时代,明显 RPC 更适合服务间相互通信和调用,接口名称和参数都是已经在数据结构上定义好的.而 HTTP 则更像是口头约定的.
说简单点就是: 使用 RPC 能像调用一个函数一样访问接口,更方便更健壮不容易出错,在工程学上能让整体软件更稳定

[lizy0329]

一样的，http 也是 RPC 的一种，只不过狭义上的 RPC 采用二进制数据包，速度快，更倾向于在内部服务通讯使用。如果有人封装了一个 SDK 给你，内部使用 http 还是 gRPC ，你光从外表上看是无法分辨的。

[NeoZephyr]

我觉得问题是，gRPC 多大程度上使用了 HTTP2 。按理说，HTTP2 跟 HTTP1.1 都是在 TCP 之上的，也就是 TCP 层面的开销都是一样免不了，只是在应用层做了优化

个人觉得，gRPC 这种基于 HTTP2 的，应该在性能上是比不上那种直接基于 TCP 甚至 UDP 的 RPC

[wangritian]

个人理解只有 2 种情况 gRPC 优于 restful

[wangritian]

按习惯 ctrl+回车换行发出去了
1.接口流量非常大
2.你需要快速实现一个双向通讯

[julyclyde]

1 写起来语义不同，一个是 call ，一个是 communication
2 评职称