了解gRPC技术，这一篇就够了

【gRPC技术】本文将从gRPC背景及业务流程、gRPC简介等对gRPC的框架进行详细的探讨。

发布时间：2019-05-13
点击量：
点赞：

分享至

我想评论

未来的数据中心基本都是软件定义，利用云计算、大数据、人工智能等创新技术，实现传统网络资源、服务器资源及存储资源的整合；同时，越来越多的GPU、HPC业务在数据中心网络中进行传输，对网络的带宽和时延提出更高的要求。从运维角度，可以通过自动化平台收集信息，快速对网络进行适配，提升运维效率，从而打造更加可用、可靠、可控的网络来服务好业务。

在上一期《技术盛宴》（数据中心网络运维的"巨人之剑"）中，对传统运维技术和gRPC（Google Remote Procedure Call，Google远程过程调用）做了简单的介绍和对比，大家对gRPC技术有了大概的了解，本文将对gRPC的框架进行详细的探讨。

gRPC背景及业务流程

前面提到由于GPU、HPC等这类业务容易出现微突发的现象，运维人员需要快速检测到微突发的情况并且进行定位、调整。而传统的CLI、SNMP等网管手段不能很好满足自动化运维需求，这时需要有一种技术在不影响设备的性能和功能的情况下实现更高精度的数据监控。

在往期的《技术盛宴》中有文章提到通过INT（In-band Network Telemetry）技术可以实现流量端到端转发路径的可视化，如图1，但是无法对交换机的Buffer进行全面的管理，包括出、入端口/队列缓存等实时监控，显得有些无力，若是采用基于gRPC + Protocol Buffers的运维接口设计，可以很好地满足运维对单个网络网元全面的可视化和实时性要求。

▲图1：INT交互过程

我们都知道对于设备侧：Telemetry=原始数据+数据模型+编码格式+传输协议，如图2。这里用到的传输协议就是gRPC，下面将对gRPC进行一个简单的分析。

▲图2：Telemetry分层模型

gRPC简介

gRPC是Google发布的基于HTTP 2.0传输层协议承载的高性能开源软件框架，提供了支持多种编程语言的、对网络设备进行配置和纳管的方法。由于是开源框架，通信的双方可以进行二次开发，所以客户端和服务器端之间的通信会更加专注于业务层面的内容，减少了对由gRPC框架实现的底层通信的关注。如图3，DATA部分即业务层面内容，下面所有的信息都由gRPC进行封装。

▲图3：gRPC分层框架

关于具体gRPC报文的结构，可以参考图4：

▲图4：gRPC报文的结构

下面展示一下gRPC的交互过程，如图5

▲图5：gRPC交互过程

●交换机在开启gRPC功能后充当gRPC客户端的角色，采集服务器充当gRPC服务器角色；

●交换机会根据订阅的事件构建对应数据的格式（GPB/JSON），通过Protocol Buffers进行编写proto文件，交换机与服务器建立gRPC通道，通过gRPC协议向服务器发送请求消息；

●服务器收到请求消息后，服务器会通过Protocol Buffers解译proto文件，还原出最先定义好格式的数据结构，进行业务处理；

●数据梳理完后，服务器需要使用Protocol Buffers重编译应答数据，通过gRPC协议向交换机发送应答消息；

●交换机收到应答消息后，结束本次的gRPC交互。

上图展示的是gRPC交互过程的具体流程，这也是Telemetry触发方式其中之一，称为Dial-out模式。简单地说，gRPC就是在客户端和服务器端开启gRPC功能后建立连接，将设备上配置的订阅数据推送给服务器端。我们可以看到整个过程是需要用到Protocol Buffers将所需要处理数据的结构化数据在proto文件中进行定义。

什么是Protocol Buffers？

你可以理解Protocol Buffers是一种更加灵活、高效的数据格式，与XML、JSON类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。

Protoco Buffers在gRPC的框架中主要有三个作用：

定义数据结构

定义服务接口

通过序列化和反序列化，提升传输效率

更快的传输速度——序列化的成果

我们知道使用XML、JSON进行数据编译时，数据文本格式更容易阅读，但进行数据交换时，设备就需要耗费大量的CPU在I/O动作上，自然会影响整个传输速率。Protocol Buffers不像前者，它会将字符串进行序列化后再进行传输，即二进制数据。

▲表1：ProtocolBuffers和对应的JSON编码格式

可以看到其实两者内容相差不大，并且内容非常直观，但是Protocol Buffers编码的内容只是提供给操作者阅读的，实际上传输的并不会以这种文本形式，而是序列化后的二进制数据。字节数会比JSON、XML的字节数少很多，速率更快。

在目前或者说未来信息数据爆炸的时代，因为Protocol Buffers是以二进制的形式进行传输的，传输效率相比XML、JSON是有天然的优势，而数据采集效率必然是架构设计、运维建设考虑的重点之一。

跨平台多语言

Protocol Buffers自带一个编译器也是一个优势点。前面提到的proto文件就是通过编译器进行编译的，proto文件需要编译生成一个类似库文件，基于库文件才能真正开发数据应用。具体用什么编程语言编译生成这个库文件呢？由于现网中负责网络设备和服务器设备的运维人员往往不是同一组人，运维人员可能会习惯使用不同的编程语言进行运维开发，那么Protocol Buffers其中一个优势就能发挥出来——跨语言。

例如在数据中心网络中，服务器端会使用Python语言，而客户端，即交换机侧更多是使用C++，但这些毫不影响两者之间的交互。如图6。

▲图6：跨平台多语言传输

从上面的介绍，我们得出在编码方面Protocol Buffers对比JSON、XML的优点：

●简单，体积小，数据描述文件大小只有1/10至1/3；

●传输和解析的速率快，相比XML等，解析速度提升20倍甚至更高；

●可编译性强。

除了Protocol Buffers之外，从交互图中和分层框架可以看到， gRPC还有另外一个优势——它是基于HTTP 2.0协议的。

基于HTTP 2.0标准设计

由于gRPC基于HTTP 2.0标准设计，带来了更多强大功能，如多路复用、二进制帧、头部压缩、推送机制。这些功能给设备带来重大益处，如节省带宽、降低TCP连接次数、节省CPU使用等。gRPC既能够在客户端应用，也能够在服务器端应用，从而以透明的方式实现两端的通信和简化通信系统的构建。

HTTP 版本分为HTTP 1.X、 HTTP 2.0，其中HTTP 1.X是当前使用最广泛的HTTP协议，HTTP 2.0称为超文本传输协议第二代。HTTP 1.X定义了四种与服务器交互的方式，分别为：GET、POST、PUT、DELETE，这些在HTTP 2.0中均保留。我们再来看看HTTP 2.0的新特性：

双向流、多路复用

在HTTP 1.X协议中，客户端在同一时间访问同一域名的请求数量是有限制的，当超过阈值时请求会被阻断，但是这种情况在HTTP 2.0中将被忽略。由于HTTP 1.X传输的是纯文本数据，传输体积较大，而HTTP 2.0传输的基本单元为帧，每个帧都包含消息，并且由于HTTP 2.0允许同时通过一条连接发起多个“请求-响应”消息，无需建立多个TCP链接的同时实现多条流并行，提高吞吐性能，并且在一个连接内对多个消息进行优先级的管理和流控。如图7。

▲图7：双向流、多路复用特性

二进制帧

相对于HTTP 1.X的纯文本传输来，HTTP 2.0传输的是二进制数据，与Protocol Buffers相辅相成。使得传输数据体积小、负载低，保持更加紧凑和高效。

头部压缩

因为HTTP是无状态协议，对于业务的处理没有记忆能力，每一次请求都需要携带设备的所有细节，特别是在头部都会包含大量的重复数据，对于设备来说就是在不断地做无意义的重复性工作。HTTP 2.0中使用“头表”来跟踪之前发送的数据，对于相同的数据将不再使用重复请求和发送，进而减少数据的体积。

总结

随着AI、HPC等高性能业务对网络的依赖度逐渐增强，那么网络从设计开始就需要考虑到后期运维时如何能够快速、精准地掌握全网设备、链路的实时状态，用于支撑业务的平稳运行。目前gRPC在数据中心交换机上已经实现了部分的应用，并且在一些互联网公司的部分场景中得到了部署，并探索全面替代SNMP协议，作为唯一的南向运维接口。

基于gRPC的通信，客户端和服务端肯定要定义proto文件，需要通过proto文件定义服务接口，具体就是一些原子操作，比如Get、Set、Notification、Subscribe等，但是具体的数据模型，到底是基于JSON模型还是YANG模型，从简单维护和易扩展的角度，更加推荐YANG模型，但关键的难点，如之前文章描述，如何统一YANG模型，这个还需要进一步探索。

本期作者：李宇炫

锐捷网络互联网系统部行业咨询