这是我参与8月更文挑战的第16天，活动详情查看：8月更文挑战
gRPC的特性
基于HTTP/2
HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP连接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。
IDL使用ProtoBuf
gRPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
多语言支持
gRPC支持多种语言（C,C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java），并能够基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言，grpc-java已经支持Android开发。
gRPC 优点
-
protobuf是二进制消息，性能好/效率高（空间和时间效率都很不错） -
通过在服务器和客户端之间共享
.proto文件，可以端到端生成消息和客户端代码。 节约开发时间。并且有严格的规范。 -
基于
HTTP/2，与HTTP 1.x相比，HTTP/2具有巨大性能优势。 -
支持流式处理
-
截止时间/超时和取消,
gRPC允许客户端指定其愿意等待RPC完成的时间期限。
gRPC 缺点
-
浏览器支持受限，无法通过浏览器直接调用
grpc服务。可以通过grpc-web来做，但并不支持所有gRPC功能。 不支持客户端和双向流式传输，并且对服务器流式传输的支持有限。 -
默认情况下，
gRPC消息使用Protobuf进行编码。 尽管Protobuf可以高效地发送和接收，但其二进制格式人工不可读。 -
gRPC尚未提供连接池，需要自行实现 -
尚未提供“服务发现”、“负载均衡”机制
