rpc框架的实现原理（漫谈gRPCGoogle自研的rpc框架）

简介

gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持 C, C , Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持.

gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。

2 gRPC介绍

gRPC是一个现代的开源高性能RPC框架，可以在任何环境中运行。它可以有效地连接数据中心内和跨数据中心的服务，并提供可插拔的支持，以实现负载平衡(load balancing)，调用链追踪(tracing)，健康检查(health checking)和身份验证(authentication)。它还适用于分布式计算的最后一英里，用于将设备，移动应用程序和浏览器连接到后端服务。

gRPC的四个核心特性，使得其对开发者有着极大的吸引力：

• 简单的服务定义
• 跨平台跨语言
• 基于http/2双向流传输
• 可插拔的插件机制

2.1 服务定义

与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根(Stub)，它提供与服务器相同的方法。客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，其背后会通过RPC通信给服务端发送请求，并获得响应。如下图：

要完成这样的功能，我们首先要进行服务定义(Service Definition)，一些框架中，将定义服务的语法称之为IDL(Interface Definition Language，接口定义语言)。

gRPC 默认使用 Protocol Buffer进行服务定义，这是 Google 开源的一套成熟的结构数据序列化机制（当然也可以使用其他数据格式如 JSON)。

目前Protocol Buffer已经发展到proto3，相对于proto2，它拥有轻量简化的语法、一些有用的新功能，并且支持更多新语言。通常建议在 gRPC 里使用 proto3，因为这样你可以使用 gRPC 支持全部范围的的语言，并且能避免 proto2 客户端与 proto3 服务端交互时出现的兼容性问题，反之亦然。

使用Protocol Buffer进行服务定义非常简单明了，我们可以创建一个.proto文件，按照Protocol Buffer语法编写此文件，如：

​

说明如下：

1. 定义一个表示请求的HelloRequest，其包含一个message字段表示请求内容
2. 定义一个表示响应的HelloResponse，其包含一个message字段表示响应内容
3. 定义服务HelloService，其提供一个hello方法，以HelloRequest作为方法参数，并返回HelloResponse

考虑为什么要在一个文件中进行服务定义？

这主要是为了跨语言。gRPC提供了工具，可以根据服务定义文件，来为不同的平台和语言生成server端和client端的代码，意味着你的服务端和客户端，可以使用不同的语言。例如，笔者最近开发的一个服务，服务端使用go编写，客户端需要支持go、python、java。此时笔者就可以根据这个配置文件，分别生成不同语言的代码。

2.2 跨语言跨平台工作

gRPC提供了工具，可以为不同的平台、语言，生成对应的client和server代码，使得彼此之间可以通过gRPC进行通信。

通常一个规模较大的公司，技术栈往往不统一，可能会使用多种语言。通过gRPC，服务端我们可以使用一种语言编写，而客户端可以支持多种语言。

下图演示了服务端使用C ，客户端使用Java和Ruby的交互案例：

​

截止笔者撰写此文(2019年6月28日)，官方支持10种语言，以及linux、mac、windows三种平台，具体如下：

​

2.3 插件机制

grpc提供了可插拔的插件机制，或者说是拦截器机制，以对每一次RPC请求进行拦截。基于此，我们可以实现一些RPC通信过程中的高级功能。如：

身份验证：

gRPC内置了两种验证机制，基于连接层面的SSL/TLS，以及基于Google Token的身份认证机制。如果不满足需求，你也很容易的进行扩展自己验证机制。

负载均衡：

在微服务架构中，为了实现容灾、高可用或者水平扩展等目的，通常一个服务都会部署多个节点。客户端在调用时，尽量的将请求分散在不同的节点上，以实现负载均衡。通常负载均衡有两种模式：1)通过代理，即请求先发送给一个中间代理服务器，例如nginx，由代理按照负载均衡策略选择一个后端节点进行处理；2) 客户端路由：客户端按照负载均衡选择某个后端服务节点，进行调用。gRPC提供了一套完善的机制，支持客户端发现服务端有哪些节点，以及自定义负载均衡策略。

健康检查：

健康检查用于探测服务端是否可以处理RPC请求。检查检查可以由客户端直接发起，或者通过其他系统(如consul)。服务端可以选择回复”unhealthy"来表明自己还没准备好处理请求，或者服务端已经宕机。客户端根据服务端回复的响应信息，或者指定时间内是否收到响应，来判断服务端是否健康。

2.4 基于HTTP/2双向流传输

gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。

​

gRPC利用HTTP/2进行消息传输，但是其只是本身定义了HTTP2中的传输单元中帧(Frame)的格式。至于HTTP/2协议本身的解析，gRPC尽量复用已有的组件。例如，在Java中，Netty本身支持HTTP/2协议协议，因此gRPC默认是支持与netty进行整合的。又或者，如果你希望移动设备(如安卓)，可以直接与服务端进行交互，那么在安卓客户端，你可以选择将gRPC与okHttp进行整合。

3 gRPC生态体系

gRPC有着丰富的生态系统，这些组件是由不是官方提供。以下介绍部分组件：

• grpc-opentracing
• grpc-gateway
• grpc-prometheus
• 其他组件

3.1 grpc-opentracing

在RPC调用过程中，可能会出现A调动B，B又调用C等情况，此时我们希望对完整的调用链路进行追踪。

grpc生态系统中有一个grpc-opentracing组件，我们可以使用其对接zipkin，进行调用链路展示，查看整个调用链路中每个环节的耗时，以发现系统的瓶颈。下

图来源自zipkin官网，我们可以看到链路追踪的最终展示效果：

​

3.2 grpc-promethus

grpc-prometheus来对gRPC服务进行监控，并将监控数据存储到prometheus中。

​

目前有2种语言的实现：

• java-grpc-prometheus
• go-grpc-prometheus

监控指标服务端与客户端分别统计，统计的指标包括：发起了多少个请求，接收到了多少个响应，响应延迟等。

3.3 grpc-gateway

​

gRPC已经支持了绝大部分主流语言，对于一些小众语言可能不支持，此时你可以使用grpc-gateway来进行反向代理。

grpc-gateway本质是一个protoc插件，我们在编写gRPC服务定义proto文件，通过指定一些自定义选项，在编译时，在生成gRPC代码时，额外指定生成grpc-gateway反向代理相关代码，其作用是将RESTful JSON API请求转换为gRPC请求。

之后，我们对反向代理代码进行改造，对于不支持gRPC的语言，让其发送HTTP RESTful JSON 请求，通过反向代理将其转换成grpc请求，下图演示了其工作原理：

​

3.4 其他支持

上述提到的几个组件gRPC生态体系中的组件，围绕着gRPC来开发的。一些其他的著名开源软件，如nginx、haproxy等，也提供了对gRPC的支持。

3.4.1 nginx对gRPC的支持

nginx从1.13.10开始提供对grpc的支持，client端和server端都可以使用gRPC实现，通过nginx进行代理，如下图：

​

nginx使用grpc_pass指令代理流量。下面的nginx代理配置，演示了在端口80上侦听未加密的gRPC流量并将请求转发到端口50051上的服务器。

​

更完整的介绍和配置，点击这里：

https://www.nginx.com/blog/nginx-1-13-10-grpc/

3.4.2 HAProxy对gRPC的支持

HAProxy 从1.9.2 添加了对gRPC的支持。完整介绍，点击以下链接：

https://www.haproxy.com/blog/haproxy-1-9-2-adds-grpc-support/

​

,