段勇宾
本文介绍了gRPC服务与HTTP API（包括ASP.NET Core Web API）在微服务调用下的比较。为您的应用程序提供API的技术是一个重要的选择，与HTTP API相比，gRPC具有独特的优势。本文讨论了gRPC的优点和缺点，并建议了将gRPC应用于其他技术的方案。
高层比较
下表对gRPC和带有JSON的HTTP API之间的功能进行了高级比较。
gRPC的优势性能
gRPC消息使用Protobuf（一种有效的二进制消息格式）进行序列化。Protobuf在服务器和客户端上非常快速地序列化。Protobuf序列化可产生较小的消息负载，这在移动应用程序等带宽有限的情况下很重要。
gRPC专为HTTP / 2（HTTP的主要版本）而设计，与HTTP
1.x
相比，它提供了显着的性能优势：- 二进制成帧和压缩。HTTP / 2协议在发送和接收方面都是紧凑高效的。
- 在单个TCP连接上多个HTTP / 2调用的复用。多路复用消除了行头阻塞。
代码生成
所有gRPC框架都为代码生成提供了一流的支持。gpro开发的核心文件是.proto文件，该文件定义gRPC服务和消息的约定。gRPC框架将从该文件中代码生成服务基类，消息和完整的客户端。
通过在服务器和客户端之间共享.proto文件，可以从头到尾生成消息和客户端代码。客户端的代码生成消除了客户端和服务器上消息的重复，并为您创建了一个强类型的客户端。无需编写客户端，可以在具有许多服务的应用程序中节省大量的开发时间。
严格规格
带有JSON的HTTP API的正式规范不存在。开发人员在争论URL，HTTP动词和响应代码的最佳格式。
该GRPC规范是规定有关GRPC服务必须遵循的格式。gRPC消除了争论，并节省了开发人员时间，因为gRPC在各个平台和实现中都是一致的。
流媒体
HTTP / 2为长期的实时通信流提供了基础。gRPC为通过HTTP / 2进行流传输提供了一流的支持。
gRPC服务支持所有流组合：
- 无串流；
- 服务器到客户端流；
- 客户端到服务器流；
- 双向流。
截止日期/超时和取消
gRPC允许客户端指定他们愿意等待RPC完成多长时间。该期限被发送到服务器，服务器可以决定它是否超出了限期采取什么行动。例如，服务器可能会在超时时取消正在进行的gRPC / HTTP /数据库请求。
通过子gRPC调用传播截止日期和取消，有助于强制执行资源使用限制。
gRPC建议方案
gRPC非常适合以下情况：
- 微服务。gRPC专为低延迟和高吞吐量通信而设计。gRPC对于效率至关重要的轻量级微服务非常有用。
- 点对点实时通信。gRPC对双向流具有出色的支持。gRPC服务可以实时推送消息而无需轮询。
- 多种语言环境。gRPC工具支持所有流行的开发语言，因此gRPC是多语言环境的理想选择。
- 网络受限的环境。gRPC消息使用Protobuf（一种轻量级消息格式）进行了序列化。gRPC消息始终小于等效的JSON消息。
gRPC的弱点
有限的浏览器支持
今天，不可能从浏览器直接调用gRPC服务。gRPC大量使用HTTP / 2功能，并且没有浏览器提供支持gRPC客户端的Web请求所需的控制级别。例如，浏览器不允许调用者要求使用HTTP / 2，或提供对基础HTTP / 2框架的访问。
gRPC-Web是gRPC团队的另一项技术，可在浏览器中提供有限的gRPC支持。gRPC-Web由两部分组成：一个支持所有现代浏览器的JavaScript客户端，以及服务器上的一个gRPC-Web代理。gRPC-Web客户端调用代理，代理将根据gRPC请求转发到gRPC服务器。
gRPC-Web并非支持所有gRPC的功能。不支持客户端和双向流，并且对服务器流的支持有限。
不可读
HTTP API请求以文本形式发送，并且可以由人类读取和创建。
默认情况下，gRPC消息使用Protobuf编码。尽管Protobuf可以高效地发送和接收，但其二进制格式不是人类可读的。Protobuf要求在.proto文件中指定的消息接口描述才能正确反序列化。需要额外的工具来分析网上的Protobuf有效载荷并手动撰写请求。
存在诸如服务器反射和gRPC命令行工具之类的功能来辅助二进制Protobuf消息。另外，Protobuf消息支持与JSON之间的转换。内置的JSON转换提供了一种在调试时将Protobuf消息与人类可读格式之间相互转换的有效方法。
替代框架方案
在以下情况下，建议在gRPC上使用其他框架：
- 浏览器可访问的API。浏览器不完全支持gRPC。gRPC-Web可以提供浏览器支持，但是它有局限性并引入了服务器代理。
- 广播实时通信 。gRPC支持通过流传输进行实时通信，但是不存在将消息广播到注册的连接的概念。例如，在聊天室场景中，应将新的聊天消息发送到聊天室中的所有客户端，要求每个gRPC调用将新的聊天消息单独流式传输到客户端。SignalR是此方案的有用框架。SignalR具有持久连接的概念，并内置了对广播消息的支持。
- 进程间通信。进程必须托管HTTP / 2服务器才能接受传入的gRPC调用。对于Windows，进程间通信管道是一种快速，轻便的通信方法。
你看我独角兽吗
简单点，HTTP是协议，RPC是概念！实现RPC可以基于HTTP协议（Feign），TCP协议(Netty)，RMI协议（Soap），WebService（XML—RPC）框架。传输过程中，也因为序列化方式的不同，又有一些框架和协议，比如Dubbo中的Dubbo协议，gRpc—Protobuf序列化协议等等。其实，都是基于远程调用的概念，何为远程调用？
重点是，RPC就是远程调用，远程调用就是客户端把调用的接口，参数，参数类型，方法，返回值，返回值类型等（这些称为方法签名），通过如上的协议，发送给服务端，告知服务端需要调用的接口方法，这个过程就是RPC的实现过程！HTTP和RPC是不同层面的两个东西！
性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中就会占用大量的资源（内存，带宽等），性能上肯定没有通过TCP直接实现RPC协议快，不管HTTP如何优化肯定的是不如TCP的！而TCP则是依靠字节码，现在普遍采用的是将客户端调用的接口信息，序列化的方式发送给服务端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字节码最小的是Protobuf），序列化后的字节码越小，占用带宽越少，序列化时间越短，线程IO等待时间就会越小。所以，在具体应用层面有很多可探讨的技术，可以根据自己的硬件能力来选择相应的技术就可以了！
欢迎热爱技术的人来探讨！
人生路誰主沉浮
基本都是复制黏贴，全是一个答案，没看到有真正深入思考过的答案，还是我来说说吧。
前言：其实计算机里面的很多概念都是来源于现实世界的，通过现实里面具体的例子来理解RPC。A：代表一栋大楼（相当于一个大的服务端内网集群），B：代表大楼内的一个个房间（每个房间相当于一个应用框架)，C：代表人员管理机构（相当于楼管处或者各级人口管理部门）。首先，在项目架构比较简单的时候，可能一个项目就一个统一的框架，一种语言，这时候我们程序里面的一个方法里面可能会调用N个其他的方法，但因为都是在同一个框架内，都属于框架级的内部调用，这个时候自然用不到RPC，RESTful足以满足当前场景。 但是当你的项目架构越来越复杂，访问量越来越多的时候，可能上了N多框架，N个语言，当你在业务里面调用其他框架的方法或者调用其他独立部署的服务的时候，自然没法像最初那样直接在框架/容器的内部去调用，当这种框架和容器间的这种调用量不是很大的时候依然可以选择用RESTful方式去调用，但是当这种调用量很大，服务很多的时候，RESTful显然是无法满足需求的。
打个比方，最初的内部调用相当于你要找的人和你在同一个房间内，直接就可以找到。但当要找的人分散在大楼的各个房间的时候，你怎么找他呢？你可以去区里人口部门查，查不到去市里 - 省里 - 国家人口管理部门查，最终肯定总能找到他，但这样的方式是不是效率很低，路径很长？所以这个时候就来了RPC解决了这个问题，我们在该大楼一楼建立了统一的楼管处（服务注册中心），该出记录了大楼里面每个人的详细信息，每个人要先去登记（服务注册），要查的时候直接去楼管处查（服务发现）就可以了。当然你可以直接走路（HTTP协议）去查，也可以直接打电话（TCP协议）去楼管处查，也可以微信群（自定义协议）去查。 首先该楼管处记录的信息量非常小（只记录你们大楼的人），非常垂直和精确，所以你去查的速度会非常快，路径会非常短。 如果你还用传统RESTful的方式，首先查找范围会非常大，因为你根本不知道这个人到底在哪里，他可能在你们大楼内，也可能在本市某个角落的大楼里面，还可能在几千公里外的另一个城市，你查找的目标范围会非常大，路径会非常长，不确定性非常大。所以最终的效率肯定是非常低的。
完整的 RPC 框架
在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。
图完整 RPC 架构图
RPC和RESTful的区别
RPC的优势：
- 是查找的精确性，快速性，短路径，和确定性，因为属于内网查询，独立的注册中心，所以查找的速度更快。
- 而且由于做了精简和优化，删去了RESTful方式里面很多多余的信息，比如Header，而且做了压缩和序列化，通过二进制方式传输，传输的内容更少，传输的速度也更快。
- 环节和流程更少，因为RESTful需要经过路由，负载均衡，网关，防火墙和一系列的身份识别和校验，就像大楼内来了个不认识的人，楼管大叔肯定要查你的身份证等等信息核实你的信息。 而且RPC就省去了这些环节，就像你天天出来进去，楼管大妈早就对你很熟了，不需要每次核实你的信息，RPC省去了很多环节。
RESTful的优势：
- 通用性更好，RESTful可以供任何接入互联网的终端调用，各种平台，各种终端都可以用RESTful传输和交换数据，而且有一套标准和规范的传输格式，所以格式更加标准化和通用化。
- 调用及测试都很方便。RPC 实现需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。
- 移植性更好，从一个服务器迁移到另一个服务器，从一个节点迁移到另一个节点，从一个架构移植到另一种架构，都可以轻松完成。
RPC的应用场景：当你的框架和语言种类也比较多，内部子系统较多、接口非常多的情况下，RPC是最佳的选择。RPC更多是内网之间的数据传输，性能消耗低，传输效率高，实现复杂。一般是部署在服务层的分布式系统里面，或者微服务系统。有服务治理，服务限流、服务降级、服务熔断、服务监控等等，类似于大楼里面配了治安处，物业处、后勤处、监控中心等。
- 长链接。不必每次通信都要像 HTTP 一样去 3 次握手，减少了网络开销。
- 注册发布机制。RPC 框架一般都有注册中心，有丰富的监控管理;发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
- 安全性，没有暴露资源操作。
- 微服务支持。就是最近流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。
RESTful的应用场景：数据更多是公网上的传输，主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。
