本期作者：李宇炫
銳捷網絡網際網路系統部行業咨詢
“打通gRPC的最後一公裡！”
未來的資料中心基本都是軟體定義，利用雲計算、大資料、人工智能等創新技術，實作傳統網絡資源、伺服器資源及存儲資源的整合；同時，越來越多的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互動過程
1
交換機在開啟gRPC功能後充當gRPC用戶端的角色，采集伺服器充當gRPC伺服器角色；
2
交換機會根據訂閱的事件建構對應資料的格式(GPB/JSON)，通過Protocol Buffers進行編寫proto檔案，交換機與伺服器建立gRPC通道，通過gRPC協定向伺服器發送請求消息；
3
伺服器收到請求消息後，伺服器會通過Protocol Buffers解譯proto檔案，還原出最先定義好格式的資料結構，進行業務處理；
4
資料梳理完後，伺服器需要使用Protocol Buffers重編譯應答資料，通過gRPC協定向交換機發送應答消息；
5
交換機收到應答消息後，結束本次的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
簡單，體積小，資料描述檔案大小隻有1/10至1/3；
2
傳輸和解析的速率快，相比XML等，解析速度提升20倍甚至更高；
3
可編譯性強。
除了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模型，這個還需要進一步探索。
往期精彩回顧
▌ 【第二十二期】IPv6系列安全篇——SAVI技術解析
▌ 【第二十三期】IPv6系列安全篇——園區網IPv6的接入安全政策
【技術盛宴】專欄
銳捷網絡自2018年起精心打造《技術盛宴》專欄，圍繞熱點技術、行業趨勢定期分享網絡通信領域的技術幹貨。
從前沿理論到應用實踐，從知識科普到深度解析，為您帶來網絡技術的饕餮盛宴。
點選“閱讀原文”，了解更多網際網路行業解決方案