RPC 和 http 相比优势在哪里?

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

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

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

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

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

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

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

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

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

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

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

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

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

能问出这个问题，说明你至少现阶段完全不需要 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 打架，大厂自然有框架组专门的人来解决，至少规避这个问题，小公司有吗？

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

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

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

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

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

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

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

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

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