目录
1、什么是 gRPC
在 gRPC 中，客户端应用程序可以直接调用服务器应用程序上的方法 在不同的计算机上，就好像它是本地对象一样，使您可以更轻松地 创建分布式应用程序和服务。与许多 RPC 系统一样，gRPC 是 基于定义服务的思想，指定可以 使用其参数和返回类型远程调用。
在服务器端， 服务器实现此接口并运行 gRPC 服务器来处理客户端调用。 在客户端，客户端有一个存根（在某些中称为客户端 语言），提供与服务器相同的方法。
gRPC 客户端和服务器可以在各种 环境 - 从 Google 内部的服务器到您自己的桌面 - 并且可以 以任何 gRPC 支持的语言编写。因此，例如，您可以轻松地 在 Java 中创建 gRPC 服务器，并使用 Go、Python 或 Ruby 中的客户端。另外 最新的 Google API 将具有其接口的 gRPC 版本，让您 轻松将 Google 功能构建到您的应用程序中。
gRPC 是一个高性能、通用的开源 RPC 框架，其由 Google 2015 年主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf 序列化协议开发，且支持众多开发语言。
由于是开源框架，通信的双方可以进行二次开发，所以客户端和服务器端之间的通信会更加专注于业务层面的内容，减少了对由 gRPC 框架实现的底层通信的关注。
如下图，DATA 部分即业务层面内容，下面所有的信息都由 gRPC 进行封装。
2、gRPC 的特点
跨语言使用，支持 C++、Java、Go、Python、Ruby、C#、Node.js、Android Java、Objective-C、PHP 等编程语言；
基于 IDL 文件定义服务，通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub；
通信协议基于标准的 HTTP/2 设计，支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性，这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量；
序列化支持 PB（Protocol Buffer）和 JSON，PB 是一种语言无关的高性能序列化框架，基于 HTTP/2 + PB, 保障了 RPC 调用的高性能；
安装简单，扩展方便（用该框架每秒可达到百万个RPC）。
3、gRPC 交互过程
交换机在开启 gRPC 功能后充当 gRPC 客户端的角色，采集服务器充当 gRPC 服务器角色；
交换机会根据订阅的事件构建对应数据的格式（GPB/JSON），通过 Protocol Buffers 进行编写 proto 文件，交换机与服务器建立 gRPC 通道，通过 gRPC 协议向服务器发送请求消息；
服务器收到请求消息后，服务器会通过 Protocol Buffers 解译 proto 文件，还原出最先定义好格式的数据结构，进行业务处理；
数据处理完后，服务器需要使用 Protocol Buffers 重编译应答数据，通过 gRPC 协议向交换机发送应答消息；
交换机收到应答消息后，结束本次的 gRPC 交互。
简单地说，gRPC 就是在客户端和服务器端开启 gRPC 功能后建立连接，将设备上配置的订阅数据推送给服务器端。
我们可以看到整个过程是需要用到 Protocol Buffers 将所需要处理数据的结构化数据在 proto 文件中进行定义
4、Protocol Buffers
可以理解 ProtoBuf 是一种更加灵活、高效的数据格式，与 XML、JSON 类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。
ProtoBuf 在 gRPC 的框架中主要有三个作用：定义数据结构、定义服务接口，通过序列化和反序列化方式提升传输效率。
为什么 ProtoBuf 会提高传输效率呢？
我们知道使用 XML、JSON 进行数据编译时，数据文本格式更容易阅读，但进行数据交换时，设备就需要耗费大量的 CPU 在 I/O 动作上，自然会影响整个传输速率。
Protocol Buffers 不像前者，它会将字符串进行序列化后再进行传输，即二进制数据。
可以看到其实两者内容相差不大，并且内容非常直观，但是 Protocol Buffers 编码的内容只是提供给操作者阅读的，实际上传输的并不会以这种文本形式，而是序列化后的二进制数据，字节数会比 JSON、XML 的字节数少很多，速率更快。
gPRC 如何支撑跨平台，多语言呢 ？
Protocol Buffers 自带一个编译器也是一个优势点，前面提到的 proto 文件就是通过编译器进行编译的，proto 文件需要编译生成一个类似库文件，基于库文件才能真正开发数据应用。
具体用什么编程语言编译生成这个库文件呢？由于现网中负责网络设备和服务器设备的运维人员往往不是同一组人，运维人员可能会习惯使用不同的编程语言进行运维开发，那么 Protocol Buffers 其中一个优势就能发挥出来——跨语言。
从上面的介绍，我们得出在编码方面 Protocol Buffers 对比 JSON、XML 的优点：
- 标准的 IDL 和 IDL 编译器，这使得其对工程师非常友好；
- 序列化数据非常简洁，紧凑，与 XML 相比，其序列化之后的数据量约为 1/3 到 1/10；
- 解析速度非常快，比对应的 XML 快约 20-100 倍；
Protobuf 适用场景：
-
Protobuf 具有广泛的用户基础，空间开销小以及高解析性能是其亮点，非常适合于公司内部的对性能要求高的 RPC 调用；
-
由于 Protobuf 提供了标准的 IDL 以及对应的编译器，其 IDL 文件是参与各方的非常强的业务约束；
-
Protobuf 与传输层无关，采用 HTTP 具有良好的跨防火墙的访问属性，所以 Protobuf 也适用于公司间对性能要求比较高的场景；
-
由于其解析性能高，序列化后数据量相对少，非常适合应用层对象的持久化场景；
-
主要问题在于其所支持的语言相对较少，另外由于没有绑定的标准底层传输层协议，在公司间进行传输层协议的调试工作相对麻烦。
5、基于 HTTP 2.0 标准设计
除了 Protocol Buffers 之外，从交互图中和分层框架可以看到， gRPC 还有另外一个优势——它是基于 HTTP 2.0 协议的。
由于 gRPC 基于 HTTP 2.0 标准设计，带来了更多强大功能，如多路复用、二进制帧、头部压缩、推送机制。
这些功能给设备带来重大益处，如节省带宽、降低 TCP 连接次数、节省 CPU 使用等，gRPC 既能够在客户端应用，也能够在服务器端应用，从而以透明的方式实现两端的通信和简化通信系统的构建。
HTTP 1.X 定义了四种与服务器交互的方式，分别为 GET、POST、PUT、DELETE，这些在 HTTP 2.0 中均保留，我们看看 HTTP 2.0 的新特性：双向流、多路复用、二进制帧、头部压缩。
-
XML序列化（Xstream）无论在性能和简洁性上比较差。
-
Thrift 与 Protobuf 相比在时空开销方面都有一定的劣势。
-
Protobuf 和 Avro 在两方面表现都非常优越。
6、支持语言
以下是官方支持的 gRPC 语言、平台和操作系统版本：
