“打通gRPC的最后一公里！”
未來(lái)的數(shù)據(jù)中心基本都是軟件定義，利用云計(jì)算、大數(shù)據(jù)、人工智能等創(chuàng)新技術(shù)，實(shí)現(xiàn)傳統(tǒng)網(wǎng)絡(luò)資源、服務(wù)器資源及存儲(chǔ)資源的整合；同時(shí)，越來(lái)越多的GPU、HPC業(yè)務(wù)在數(shù)據(jù)中心網(wǎng)絡(luò)中進(jìn)行傳輸，對(duì)網(wǎng)絡(luò)的帶寬和時(shí)延提出更高的要求。從運(yùn)維角度，可以通過(guò)自動(dòng)化平臺(tái)收集信息，快速對(duì)網(wǎng)絡(luò)進(jìn)行適配，提升運(yùn)維效率，從而打造更加可用、可靠、可控的網(wǎng)絡(luò)來(lái)服務(wù)好業(yè)務(wù)。
在上一期《技術(shù)盛宴》（數(shù)據(jù)中心網(wǎng)絡(luò)運(yùn)維的“巨人之劍”）中，對(duì)傳統(tǒng)運(yùn)維技術(shù)和gRPC（Google Remote Procedure Call，Google遠(yuǎn)程過(guò)程調(diào)用）做了簡(jiǎn)單的介紹和對(duì)比，大家對(duì)gRPC技術(shù)有了大概的了解，本文將對(duì)gRPC的框架進(jìn)行詳細(xì)的探討。
gRPC背景及業(yè)務(wù)流程
前面提到由于GPU、HPC等這類(lèi)業(yè)務(wù)容易出現(xiàn)微突發(fā)的現(xiàn)象，運(yùn)維人員需要快速檢測(cè)到微突發(fā)的情況并且進(jìn)行定位、調(diào)整。而傳統(tǒng)的CLI、SNMP等網(wǎng)管手段不能很好滿足自動(dòng)化運(yùn)維需求，這時(shí)需要有一種技術(shù)在不影響設(shè)備的性能和功能的情況下實(shí)現(xiàn)更高精度的數(shù)據(jù)監(jiān)控。
在往期的《技術(shù)盛宴》中有文章提到通過(guò)INT（In-band Network Telemetry）技術(shù)可以實(shí)現(xiàn)流量端到端轉(zhuǎn)發(fā)路徑的可視化，如圖1，但是無(wú)法對(duì)交換機(jī)的Buffer進(jìn)行全面的管理，包括出、入端口/隊(duì)列緩存等實(shí)時(shí)監(jiān)控，顯得有些無(wú)力，若是采用基于gRPC + Protocol Buffers的運(yùn)維接口設(shè)計(jì)，可以很好地滿足運(yùn)維對(duì)單個(gè)網(wǎng)絡(luò)網(wǎng)元全面的可視化和實(shí)時(shí)性要求。
▲圖1：INT交互過(guò)程
我們都知道對(duì)于設(shè)備側(cè)：Telemetry=原始數(shù)據(jù)+數(shù)據(jù)模型+編碼格式+傳輸協(xié)議，如圖2。這里用到的傳輸協(xié)議就是gRPC，下面將對(duì)gRPC進(jìn)行一個(gè)簡(jiǎn)單的分析。
▲圖2：Telemetry分層模型
gRPC簡(jiǎn)介
gRPC是Google發(fā)布的基于HTTP 2.0傳輸層協(xié)議承載的高性能開(kāi)源軟件框架，提供了支持多種編程語(yǔ)言的、對(duì)網(wǎng)絡(luò)設(shè)備進(jìn)行配置和納管的方法。由于是開(kāi)源框架，通信的雙方可以進(jìn)行二次開(kāi)發(fā)，所以客戶端和服務(wù)器端之間的通信會(huì)更加專(zhuān)注于業(yè)務(wù)層面的內(nèi)容，減少了對(duì)由gRPC框架實(shí)現(xiàn)的底層通信的關(guān)注。如圖3，DATA部分即業(yè)務(wù)層面內(nèi)容，下面所有的信息都由gRPC進(jìn)行封裝。
▲圖3：gRPC分層框架
關(guān)于具體gRPC報(bào)文的結(jié)構(gòu)，可以參考圖4：
▲圖4：gRPC報(bào)文的結(jié)構(gòu)
下面展示一下gRPC的交互過(guò)程，如圖5
▲圖5：gRPC交互過(guò)程
1
交換機(jī)在開(kāi)啟gRPC功能后充當(dāng)gRPC客戶端的角色，采集服務(wù)器充當(dāng)gRPC服務(wù)器角色；
2
交換機(jī)會(huì)根據(jù)訂閱的事件構(gòu)建對(duì)應(yīng)數(shù)據(jù)的格式（GPB/JSON），通過(guò)Protocol Buffers進(jìn)行編寫(xiě)proto文件，交換機(jī)與服務(wù)器建立gRPC通道，通過(guò)gRPC協(xié)議向服務(wù)器發(fā)送請(qǐng)求消息；
3
服務(wù)器收到請(qǐng)求消息后，服務(wù)器會(huì)通過(guò)Protocol Buffers解譯proto文件，還原出最先定義好格式的數(shù)據(jù)結(jié)構(gòu)，進(jìn)行業(yè)務(wù)處理；
4
數(shù)據(jù)梳理完后，服務(wù)器需要使用Protocol Buffers重編譯應(yīng)答數(shù)據(jù)，通過(guò)gRPC協(xié)議向交換機(jī)發(fā)送應(yīng)答消息；
5
交換機(jī)收到應(yīng)答消息后，結(jié)束本次的gRPC交互。
上圖展示的是gRPC交互過(guò)程的具體流程，這也是Telemetry觸發(fā)方式其中之一，稱(chēng)為Dial-out模式。簡(jiǎn)單地說(shuō)，gRPC就是在客戶端和服務(wù)器端開(kāi)啟gRPC功能后建立連接，將設(shè)備上配置的訂閱數(shù)據(jù)推送給服務(wù)器端。我們可以看到整個(gè)過(guò)程是需要用到Protocol Buffers將所需要處理數(shù)據(jù)的結(jié)構(gòu)化數(shù)據(jù)在proto文件中進(jìn)行定義。
什么是Protocol Buffers？
你可以理解Protocol Buffers是一種更加靈活、高效的數(shù)據(jù)格式，與XML、JSON類(lèi)似，在一些高性能且對(duì)響應(yīng)速度有要求的數(shù)據(jù)傳輸場(chǎng)景非常適用。
Protoco Buffers在gRPC的框架中主要有三個(gè)作用：
定義數(shù)據(jù)結(jié)構(gòu)
定義服務(wù)接口
通過(guò)序列化和反序列化，提升傳輸效率
更快的傳輸速度——序列化的成果
我們知道使用XML、JSON進(jìn)行數(shù)據(jù)編譯時(shí)，數(shù)據(jù)文本格式更容易閱讀，但進(jìn)行數(shù)據(jù)交換時(shí)，設(shè)備就需要耗費(fèi)大量的CPU在I/O動(dòng)作上，自然會(huì)影響整個(gè)傳輸速率。Protocol Buffers不像前者，它會(huì)將字符串進(jìn)行序列化后再進(jìn)行傳輸，即二進(jìn)制數(shù)據(jù)。
▲表1：ProtocolBuffers和對(duì)應(yīng)的JSON編碼格式
可以看到其實(shí)兩者內(nèi)容相差不大，并且內(nèi)容非常直觀，但是Protocol Buffers編碼的內(nèi)容只是提供給操作者閱讀的，實(shí)際上傳輸?shù)牟⒉粫?huì)以這種文本形式，而是序列化后的二進(jìn)制數(shù)據(jù)。字節(jié)數(shù)會(huì)比JSON、XML的字節(jié)數(shù)少很多，速率更快。
在目前或者說(shuō)未來(lái)信息數(shù)據(jù)爆炸的時(shí)代，因?yàn)镻rotocol Buffers是以二進(jìn)制的形式進(jìn)行傳輸?shù)?，傳輸效率相比XML、JSON是有天然的優(yōu)勢(shì)，而數(shù)據(jù)采集效率必然是架構(gòu)設(shè)計(jì)、運(yùn)維建設(shè)考慮的重點(diǎn)之一。
跨平臺(tái)多語(yǔ)言
Protocol Buffers自帶一個(gè)編譯器也是一個(gè)優(yōu)勢(shì)點(diǎn)。前面提到的proto文件就是通過(guò)編譯器進(jìn)行編譯的，proto文件需要編譯生成一個(gè)類(lèi)似庫(kù)文件，基于庫(kù)文件才能真正開(kāi)發(fā)數(shù)據(jù)應(yīng)用。具體用什么編程語(yǔ)言編譯生成這個(gè)庫(kù)文件呢？由于現(xiàn)網(wǎng)中負(fù)責(zé)網(wǎng)絡(luò)設(shè)備和服務(wù)器設(shè)備的運(yùn)維人員往往不是同一組人，運(yùn)維人員可能會(huì)習(xí)慣使用不同的編程語(yǔ)言進(jìn)行運(yùn)維開(kāi)發(fā)，那么Protocol Buffers其中一個(gè)優(yōu)勢(shì)就能發(fā)揮出來(lái)——跨語(yǔ)言。
例如在數(shù)據(jù)中心網(wǎng)絡(luò)中，服務(wù)器端會(huì)使用Python語(yǔ)言，而客戶端，即交換機(jī)側(cè)更多是使用C++，但這些毫不影響兩者之間的交互。如圖6。
▲圖6：跨平臺(tái)多語(yǔ)言傳輸
從上面的介紹，我們得出在編碼方面Protocol Buffers對(duì)比JSON、XML的優(yōu)點(diǎn)：
1
簡(jiǎn)單，體積小，數(shù)據(jù)描述文件大小只有1/10至1/3；
2
傳輸和解析的速率快，相比XML等，解析速度提升20倍甚至更高；
3
可編譯性強(qiáng)。
除了Protocol Buffers之外，從交互圖中和分層框架可以看到， gRPC還有另外一個(gè)優(yōu)勢(shì)——它是基于HTTP 2.0協(xié)議的。
基于HTTP 2.0標(biāo)準(zhǔn)設(shè)計(jì)
由于gRPC基于HTTP 2.0標(biāo)準(zhǔn)設(shè)計(jì)，帶來(lái)了更多強(qiáng)大功能，如多路復(fù)用、二進(jìn)制幀、頭部壓縮、推送機(jī)制。這些功能給設(shè)備帶來(lái)重大益處，如節(jié)省帶寬、降低TCP連接次數(shù)、節(jié)省CPU使用等。gRPC既能夠在客戶端應(yīng)用，也能夠在服務(wù)器端應(yīng)用，從而以透明的方式實(shí)現(xiàn)兩端的通信和簡(jiǎn)化通信系統(tǒng)的構(gòu)建。
HTTP 版本分為HTTP 1.X、 HTTP 2.0，其中HTTP 1.X是當(dāng)前使用最廣泛的HTTP協(xié)議，HTTP 2.0稱(chēng)為超文本傳輸協(xié)議第二代。HTTP 1.X定義了四種與服務(wù)器交互的方式，分別為：GET、POST、PUT、DELETE，這些在HTTP 2.0中均保留。我們?cè)賮?lái)看看HTTP 2.0的新特性：
雙向流、多路復(fù)用
在HTTP 1.X協(xié)議中，客戶端在同一時(shí)間訪問(wèn)同一域名的請(qǐng)求數(shù)量是有限制的，當(dāng)超過(guò)閾值時(shí)請(qǐng)求會(huì)被阻斷，但是這種情況在HTTP 2.0中將被忽略。由于HTTP 1.X傳輸?shù)氖羌兾谋緮?shù)據(jù)，傳輸體積較大，而HTTP 2.0傳輸?shù)幕締卧獮閹?，每個(gè)幀都包含消息，并且由于HTTP 2.0允許同時(shí)通過(guò)一條連接發(fā)起多個(gè)“請(qǐng)求-響應(yīng)”消息，無(wú)需建立多個(gè)TCP鏈接的同時(shí)實(shí)現(xiàn)多條流并行，提高吞吐性能，并且在一個(gè)連接內(nèi)對(duì)多個(gè)消息進(jìn)行優(yōu)先級(jí)的管理和流控。如圖7。
圖7：雙向流、多路復(fù)用特性
二進(jìn)制幀
相對(duì)于HTTP 1.X的純文本傳輸來(lái)，HTTP 2.0傳輸?shù)氖嵌M(jìn)制數(shù)據(jù)，與Protocol Buffers相輔相成。使得傳輸數(shù)據(jù)體積小、負(fù)載低，保持更加緊湊和高效。
頭部壓縮
因?yàn)镠TTP是無(wú)狀態(tài)協(xié)議，對(duì)于業(yè)務(wù)的處理沒(méi)有記憶能力，每一次請(qǐng)求都需要攜帶設(shè)備的所有細(xì)節(jié)，特別是在頭部都會(huì)包含大量的重復(fù)數(shù)據(jù)，對(duì)于設(shè)備來(lái)說(shuō)就是在不斷地做無(wú)意義的重復(fù)性工作。HTTP 2.0中使用“頭表”來(lái)跟蹤之前發(fā)送的數(shù)據(jù)，對(duì)于相同的數(shù)據(jù)將不再使用重復(fù)請(qǐng)求和發(fā)送，進(jìn)而減少數(shù)據(jù)的體積。
總結(jié)
隨著AI、HPC等高性能業(yè)務(wù)對(duì)網(wǎng)絡(luò)的依賴(lài)度逐漸增強(qiáng)，那么網(wǎng)絡(luò)從設(shè)計(jì)開(kāi)始就需要考慮到后期運(yùn)維時(shí)如何能夠快速、精準(zhǔn)地掌握全網(wǎng)設(shè)備、鏈路的實(shí)時(shí)狀態(tài)，用于支撐業(yè)務(wù)的平穩(wěn)運(yùn)行。目前gRPC在數(shù)據(jù)中心交換機(jī)上已經(jīng)實(shí)現(xiàn)了部分的應(yīng)用，并且在一些互聯(lián)網(wǎng)公司的部分場(chǎng)景中得到了部署，并探索全面替代SNMP協(xié)議，作為唯一的南向運(yùn)維接口。
基于gRPC的通信，客戶端和服務(wù)端肯定要定義proto文件，需要通過(guò)proto文件定義服務(wù)接口，具體就是一些原子操作，比如Get、Set、Notification、Subscribe等，但是具體的數(shù)據(jù)模型，到底是基于JSON模型還是YANG模型，從簡(jiǎn)單維護(hù)和易擴(kuò)展的角度，更加推薦YANG模型，但關(guān)鍵的難點(diǎn)，如之前文章描述，如何統(tǒng)一YANG模型，這個(gè)還需要進(jìn)一步探索。
聯(lián)系客服
