一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第28天，点击查看活动详情。

GPRC简介

gRPC 是Google开源的高性能、通用的RPC框架。客户端与服务端约定接口调用， 可以在各种环境中运行，具有跨语言特性， 适合构建分布式、微服务应用。

GPRC 特性

• 性能优异：

  0. 采用Proto Buffer作序列化传输， 对比JSON与XML有数倍提升。
  1. 采用HTTP2协议， 头部信息压缩， 对连接进行复用， 减少TCP连接次数。
  2. gRPC底层采用Netty作为NIO处理框架， 提升性能。

• 多语言支持，多客户端接入， 支持C++/GO/Ruby等语言。

• 支持负载均衡、跟踪、健康检查和认证。

GPRC线程模型

gRPC 的线程模型遵循 Netty 的线程分工原则，协议层消息的接收和编解码由 Netty 的 I/O(NioEventLoop) 线程负责, 应用层的处理由应用线程负责，防止由于应用处理耗时而阻塞 Netty 的 I/O 线程。

BIO线程模型采用了线程池，但是后端的应用处理线程仍然采用同步阻塞的模型，阻塞的时间取决对方I/O处理的速度和网络I/O传输的速度。

采用线程池模式的BIO:

NIO 线程模型(Reactor模式):

客户端调用流程

1. 客户端 Stub 调用 发起 RPC 调用 远程服务。
2. 获取服务端的地址信息（列表），使用默认的 LoadBalancer 策略，选择一个具体的 gRPC 服务端。
3. 如果与服务端之间没有可用的连接，则创建 NettyClientTransport 和 NettyClientHandler，建立 HTTP/2 连接。
4. 对请求使用 PB（Protobuf）序列化，通过 HTTP/2 Stream 发送给 gRPC 服务端。
5. 服务端接收到响应之后，使用 PB（Protobuf）做反序列化。
6. 回调 GrpcFuture 的 set(Response) 方法，唤醒阻塞的客户端调用线程，获取 RPC 响应数据。

GRpc vs Rest 性能对比

GRpc与Rest性能对比

在不同操作系统平台, 不同请求数的对比:

GRpc + ProtoBuf 与Rest(Http+Json)性能对比

Go项目测试地址

实测结果显示GRpc的通讯方案, 性能有32%的提升, 资源占用降低30%左右。

服务设计

重点

GRPC的特性， 性能优势， 客户端的调用处理流程。

GRPC服务的集成与配置， 实现服务端的配置与客户端的调用。