了解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模型，這個還需要進一步探索。

本期作者：李宇炫

銳捷網絡互聯網系統部行業咨詢