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 不是同一概念无法比较 这两类观点楼主已经了解. 感谢.

[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 的区别.