一. 简介
1.什么是RPC
RPC指远程调用(即要像调用本地方法一样调用远程方法). eg: 两台机器，A 机器上的程序要调用 B 机器上某程序提供的函数或方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
常见的有：Thrift、gRPC
2.什么是gRPC
gRPC 是一种与语言无关的高性能远程过程调用 (RPC) 框架。
GitHub地址：https://github.com/grpc
3.gRPC的优点
(1).现代高性能轻量级 RPC 框架。
(2).协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。
(3).可用于多种语言的工具，以生成强类型服务器和客户端。
(4).支持客户端、服务器和双向流式处理调用。
(5).使用 Protobuf 二进制序列化减少对网络的使用。
4.gRPC的适用范围
(1).效率至关重要的轻量级微服务。
(2).需要多种语言用于开发的 Polyglot 系统。
(3).需要处理流式处理请求或响应的点对点实时服务。
注：Azure 应用服务或 IIS 当前不支持 ASP.NET Core gRPC。 Http.Sys 的 HTTP/2 实现不支持 gRPC 依赖的 HTTP 响应尾随标头。
二. 详解
1. gRPC和WebApi对比
2. gRPC的优势
(1). 性能
gRPC 消息使用 Protobuf（一种高效的二进制消息格式）进行序列化。 Protobuf 在服务器和客户端上可以非常快速地序列化。 Protobuf 序列化产生的有效负载较小，这在移动应用等带宽有限的方案中很重要。
gRPC 专为 HTTP/2（HTTP 的主要版本）而设计，与 HTTP 1.x 相比，HTTP/2 具有巨大性能优势：
A. 二进制组帧和压缩。 HTTP/2 协议在发送和接收方面均紧凑且高效。
B. 在单个 TCP 连接上多路复用多个 HTTP/2 调用。 多路复用可消除队头阻塞。
HTTP/2 不是 gRPC 独占的。 许多请求类型（包括使用 JSON 的 HTTP API）都可以使用 HTTP/2，并受益于其性能改进。
(2). 代码生成
所有 gRPC 框架都为代码生成提供一流支持。 .proto 文件是 gRPC 开发的核心文件，它定义 gRPC 服务和消息的协定。 通过此文件，gRPC 框架编码生成服务基类、消息和完整的客户端。
通过在服务器和客户端之间共享 .proto 文件，可以端到端生成消息和客户端代码。 客户端的代码生成消除了客户端和服务器上的消息重复，并为你创建强类型客户端。 无需编写客户端可在具有许多服务的应用程序中节省大量开发时间。
(3). 严格规范
具有 JSON 的 HTTP API 没有正式规范。 开发人员为 URL、HTTP 谓词和响应代码的最佳格式争论不休。
gRPC 规范对 gRPC 服务必须遵循的格式进行了规定。 gRPC 消除了争论并为开发人员节省了时间，因为 gRPC 在各个平台和实现中都是一致的。
(4). 流式处理
HTTP/2 为长期实时通信流提供基础。 gRPC 为通过 HTTP/2 进行流式传输提供一流支持。gRPC 服务支持所有流式传输组合：
A. 一元（无流式传输）
B. 服务器到客户端流式传输
C. 客户端到服务器流式传输
D. 双向流式传输
(5). 截止时间、超时和取消
gRPC 允许客户端指定其愿意等待 RPC 完成的时间期限。 截止时间会发送到服务器，如果超过截止时间，服务器可以决定要执行的操作。 例如，服务器可能会在超时后取消正在进行的 gRPC/HTTP/数据库请求。
通过 gRPC 子调用传播截止时间和取消有助于强制执行资源使用限制。
3. gRPC的劣势
当前无法通过浏览器直接调用 gRPC 服务。 gRPC 大量使用 HTTP/2 功能，且没有浏览器在 Web 请求中提供支持 gRPC 客户端所需的控制级别。 例如，浏览器不允许调用方要求使用 HTTP/2，也不提供对 HTTP/2 基础框架的访问。
gRPC-Web是 gRPC 团队的另一项技术，可在浏览器中提供有限的 gRPC 支持。 gRPC-Web 由两部分组成：支持所有现代浏览器的 JavaScript 客户端，以及服务器上的 gRPC-Web 代理。 gRPC-Web 客户端调用代理，代理将根据 gRPC 请求转发到 gRPC 服务器。
gRPC-Web 并不支持所有 gRPC 功能。 不支持客户端和双向流式传输，并且对服务器流式传输的支持有限。
4. gRPC适用场景
(1). 微服务：gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。
(2). 点对点实时通信：gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。
(3). 多语言环境：gRPC 工具支持所有常用的开发语言，因此，gRPC 是多语言环境的理想选择。
(4). 网络受限环境：gRPC 消息使用 Protobuf（一种轻量级消息格式）进行序列化。 gRPC 消息始终小于等效的 JSON 消息。
5. gRPC备用方案
在以下方案中，建议使用其他框架取代 gRPC：
(1). 浏览器可访问的 API：gRPC 在浏览器中未受到完全支持。 gRPC-Web 可以提供浏览器支持，但它具有局限性并引入了服务器代理。
(2). 广播实时通信：gRPC 支持通过流式传输进行实时通信，但不存在将消息广播到注册连接的概念。 例如，在聊天室方案中，应将新的聊天消息发送到聊天室中的所有客户端，这要求每个 gRPC 调用将新的聊天消息单独流式传输到客户端。 SignalR 是适用于此方案的框架。 SignalR 具有持久性连接的概念，并内置对广播消息的支持。
(3). 进程间通信：进程必须托管 HTTP/2 服务器才能接受传入的 gRPC 调用。 对于 Windows，进程间通信管道是一种快速、轻便的通信方法。
!
- 作 者 : Yaopengfei(姚鹏飞)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 声 明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
- 声 明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。