今日要闻gRPC - 了解gRPC技术，这一篇就够了
未来的数据中心基本都是软件定义，利用云计算、大数据、人工智能等创新技术，现传统络资源、服务器资源及存储资源的整合；同时，越来越多的GPU、HPC业务在数据中心络中进行传输，对络的带宽和时延提出更高的要求。从运维角度，可以通过自动化平台收集信息，速对络进行适配，提升运维效率，从而打造更加可用、可靠、可控的络来服务好业务。
在上一期《技术盛宴》（数据中心络运维的"巨人之剑"）中，对传统运维技术和gRPC（GoogleRemoteProcedureCall，Google远程过程调用）做了简单的介绍和对比，大家对gRPC技术有了大概的了解，本文将对gRPC的框架进行详细的探讨。
gRPC背景及业务流程
前面提到由于GPU、HPC等这类业务容易出现微突发的现象，运维人员需要速检测到微突发的情况并且进行定位、调整。而传统的CLI、SNMP等管手段不能很好满足自动化运维需求，这时需要有一种技术在不影响设备的性能和功能的情况下现更高精度的数据监控。
在往期的《技术盛宴》中有文章提到通过INT（In-bandNetworkTelemetry）技术可以现流量端到端转发路径的可视化，如图1，但是法对交换机的Buffer进行全面的管理，包括出、入端口队列缓存等时监控，显得有些力，若是采用基于gRPC+ProtocolBuffers的运维接口设计，可以很好地满足运维对单个络元全面的可视化和时性要求。
▲图1：INT交互过程
我们都知道对于设备侧：Telemetry=原始数据+数据模型+编码格式+传输协议，如图2。这里用到的传输协议就是gRPC，下面将对gRPC进行一个简单的分析。
▲图2：Telemetry分层模型
gRPC简介
gRPC是Google发布的基于HTTP20传输层协议承载的高性能开源软件框架，提供了支持多种编程语言的、对络设备进行配置和纳管的方法。由于是开源框架，通信的双方可以进行二次开发，所以客户端和服务器端之间的通信会更加专注于业务层面的内容，减少了对由gRPC框架现的底层通信的关注。如图3，DATA部分即业务层面内容，下面所有的信息都由gRPC进行封装。
▲图3：gRPC分层框架
关于具体gRPC报文的结构，可以参考图4：
▲图4：gRPC报文的结构
下面展示一下gRPC的交互过程，如图5
▲图5：gRPC交互过程
●交换机在开启gRPC功能后充当gRPC客户端的角色，采集服务器充当gRPC服务器角色；
●交换机会根据订阅的事件构建对应数据的格式（GPBJSON），通过ProtocolBuffers进行编写proto文件，交换机与服务器建立gRPC通道，通过gRPC协议向服务器发送请求消息；
●服务器收到请求消息后，服务器会通过ProtocolBuffers解译proto文件，还原出比较先定义好格式的数据结构，进行业务处理；
●数据梳理完后，服务器需要使用ProtocolBuffers重编译应答数据，通过gRPC协议向交换机发送应答消息；
●交换机收到应答消息后，结束本次的gRPC交互。
上图展示的是gRPC交互过程的具体流程，这也是Telemetry触发方式其中之一，称为Dial-out模式。简单地说，gRPC就是在客户端和服务器端开启gRPC功能后建立连接，将设备上配置的订阅数据推送给服务器端。我们可以看到整个过程是需要用到ProtocolBuffers将所需要处理数据的结构化数据在proto文件中进行定义。
什么是ProtocolBuffers
你可以理解ProtocolBuffers是一种更加灵活、高效的数据格式，与外汇L、JSON类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。
ProtocoBuffers在gRPC的框架中主要有个作用：
定义数据结构
定义服务接口
通过序列化和反序列化，提升传输效率
更的传输速度序列化的成果
我们知道使用外汇L、JSON进行数据编译时，数据文本格式更容易阅读，但进行数据交换时，设备就需要耗费大量的CPU在IO动作上，自然会影响整个传输速率。ProtocolBuffers不像前者，它会将字符串进行序列化后再进行传输，即二进制数据。
▲表1：ProtocolBuffers和对应的JSON编码格式
可以看到其两者内容相差不大，并且内容非常直观，但是ProtocolBuffers编码的内容只是提供给操作者阅读的，际上传输的并不会以这种文本形式，而是序列化后的二进制数据。字节数会比JSON、外汇L的字节数少很多，速率更。
在目前或者说未来信息数据爆炸的时代，因为ProtocolBuffers是以二进制的形式进行传输的，传输效率相比外汇L、JSON是有天然的势，而数据采集效率必然是架构设计、运维建设考虑的重点之一。
跨平台多语言
ProtocolBuffers自带一个编译器也是一个势点。前面提到的proto文件就是通过编译器进行编译的，proto文件需要编译生成一个类似库文件，基于库文件才能真正开发数据应用。具体用什么编程语言编译生成这个库文件呢由于现中负责络设备和服务器设备的运维人员往往不是同一组人，运维人员可能会习惯使用不同的编程语言进行运维开发，那么ProtocolBuffers其中一个势就能发挥出来跨语言。
例如在数据中心络中，服务器端会使用Python语言，而客户端，即交换机侧更多是使用C++，但这些毫不影响两者之间的交互。如图6。
▲图6：跨平台多语言传输
从上面的介绍，我们得出在编码方面ProtocolBuffers对比JSON、外汇L的点：
●简单，体积小，数据描述文件大小只有110至13；
●传输和解析的速率，相比外汇L等，解析速度提升20倍甚至更高；
●可编译性强。
除了ProtocolBuffers之外，从交互图中和分层框架可以看到，gRPC还有另外一个势它是基于HTTP20协议的。
基于HTTP20标准设计
由于gRPC基于HTTP20标准设计，带来了更多强大功能，如多路复用、二进制帧、头部压缩、推送机制。这些功能给设备带来重大益处，如节省带宽、降低TCP连接次数、节省CPU使用等。gRPC既能够在客户端应用，也能够在服务器端应用，从而以透明的方式现两端的通信和简化通信系统的构建。
HTTP版本分为HTTP1X、HTTP20，其中HTTP1X是当前使用比较广泛的HTTP协议，HTTP20称为超文本传输协议第二代。HTTP1X定义了四种与服务器交互的方式，分别为：GET、POST、PUT、DELETE，这些在HTTP20中均保留。我们再来看看HTTP20的新特性：
双向流、多路复用
在HTTP1X协议中，客户端在同一时间访问同一域的请求数量是有限制的，当超过阈值时请求会被阻断，但是这种情况在HTTP20中将被忽略。由于HTTP1X传输的是纯文本数据，传输体积较大，而HTTP20传输的基本单元为帧，每个帧都包含消息，并且由于HTTP20允许同时通过一条连接发起多个请求-响应消息，需建立多个TCP链接的同时现多条流并行，提高吞吐性能，并且在一个连接内对多个消息进行先级的管理和流控。如图7。
▲图7：双向流、多路复用特性
二进制帧
相对于HTTP1X的纯文本传输来，HTTP20传输的是二进制数据，与ProtocolBuffers相辅相成。使得传输数据体积小、负载低，保持更加紧凑和高效。
头部压缩
因为HTTP是状态协议，对于业务的处理没有记忆能力，每一次请求都需要携带设备的所有细节，特别是在头部都会包含大量的重复数据，对于设备来说就是在不断地做意义的重复性工作。HTTP20中使用头表来跟踪之前发送的数据，对于相同的数据将不再使用重复请求和发送，进而减少数据的体积。
总结
随着AI、HPC等高性能业务对络的依赖度逐渐增强，那么络从设计开始就需要考虑到后期运维时如何能够速、精准地掌握全设备、链路的时状态，用于支撑业务的平稳运行。目前gRPC在数据中心交换机上已经现了部分的应用，并且在一些互联的部分场景中得到了部署，并探索全面替代SNMP协议，作为仅有的南向运维接口。
基于gRPC的通信，客户端和服务端肯定要定义proto文件，需要通过proto文件定义服务接口，具体就是一些原子操作，比如Get、Set、Notification、Subscribe等，但是具体的数据模型，到底是基于JSON模型还是YANG模型，从简单维护和易扩展的角度，更加推荐YANG模型，但关键的难点，如之前文章描述，如何统一YANG模型，这个还需要进一步探索。
本期作者：李宇炫
锐捷络互联系统部行业咨询
往期精彩回顾
•【第二期】如何通过络遥测（NetworkTelemetry）技术现精细化络运维
•【第期】畅谈数据中心络运维自动化
•【第五期】流量可视化之ERSPAN的前世今生
•【第七期】运维可视化之INT功能详解
•【第八期】浅析RDMA络下MMU水线设置
•【第十期】数据中心自动化运维技术探索之交换机零配置上线
•【第十一期】浅谈数据中心100G光模块
•【第十五期】数据中心自动化运维技术探索之NETCONF
•【第十期】数据中心络运维的"巨人之剑"
相关推荐：
流量可视化之ERSPAN的前世今生
运维可视化之INT功能详解
数据中心络运维的"巨人之剑"
另一方面，国产数据库也给大家带来切实的好处，倍感受用，实属行业的典范。OceanBase 完全自主研发，已连续 10 余年稳定支撑双 11 ，创新推出“三地五中心”城市级容灾新标准，是全球唯一在 TPC-C 和 TPC-H 测试上都刷新了世界纪录的原生分布式数据库。https://www.oceanbase.com/topic/techwiki-guochanshujukuhttps://obcommunityprod.oss-cn-shanghai.aliyuncs.com/prod/blog/2024-12/00e6997b-8bc7-423f-a0f1-7c7a284aa47b.png
页:
[1]