未来的数据中心基本都是软件界说
，使用云盘算、大数据、人工智能等立异手艺
，实现古板网络资源、效劳器资源及存储资源的整合
；同时
，越来越多的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模子
，这个还需要进一步探索。

本期作者：李宇炫

55世纪网络互联网系统部行业咨询

往期精彩回首

• 【第二期】怎样通过网络遥测（Network Telemetry）手艺实现细腻化网络运维？

• 【第三期】泛论数据中心网络运维自动化

• 【第五期】流量可视化之ERSPAN的宿世今生

• 【第七期】运维可视化之INT功效详解

• 【第八期】浅析RDMA网络下MMU水线设置

• 【第十期】数据中心自动化运维手艺探索之交流机零设置上线

• 【第十一期】浅谈数据中心100G光？

• 【第十五期】数据中心自动化运维手艺探索之NETCONF

• 【第三十期】数据中心网络运维的"巨人之剑"