白呼白呼 gRPC，INT，和数据中心交换机（1）

被人问了几个gRPC和INT的问题，没答上来，尴尬。学习还是不能偷懒走捷径。回来补课之后写到这里，希望以后不要忘记了。

Broadcom推出新一代的可编程芯片之后，数据中心交换机具备了全新的可视化能力，依靠的技术手段是gRPC、In-band Network Telemetry和ERSPAN。

先来白呼一下gRPC。

gRPC是什么东东？

网上有很多写gRPC的文章，我就不搬运过来了。gRPC其实是一种API。之前我在《

应该选用哪种 API 来实现网络自动化？

》里面提到，数据中心交换机已经具备了很多种API——Netconf，Openconfig，REST。另外还有古老的SNMP。

那gRPC有什么特别的？

gRPC的特别之处在于它传输的数据格式不一样，是Protocol Buffer。

Protocol Buffer又是什么？

Protocal Buffer是一种数据格式，和JSON、XML差不多。下面是XML的一个例子（取自Google开发者网站），定义一个person，有2个key，分别是name和email：

下面是Protocol Buffer的数据格式：

虽然看上去和XML/JSON差不多，但是请看代码的注释，这只是给人类阅读的 text format。数据在网络中被传输之前，会先被序列化。

什么是序列化？

根据百度百科，序列化 (Serialization)就是将对象的状态信息转换为可以存储或传输的形式的过程。

Protocol Buffer可以传输的形式并不是“文本”，而是二进制。例如下面红色的部分（通常以16进制来表达）就是字符串testing编码之后的结果。具体的编码规则我就不白呼了，因为白呼不明白。大家可以去看Encoding Guide。

12 0774 65 73 74 69 6e 67

回到上面person的例子。

序列化之后的Protocol Buffer数据只有28字节长，并且，因为是二进制原始数据，所以只需要100-200纳秒就可以解析完成。

而XML数据即使不考虑空白字符，也至少有69字节长，虽然长度只有Protocol Buffer的2倍多，但是解析过程更复杂：

需要利用getElementsByTagName()方法返回带有name的所有元素的一个节点列表

因为name只有一个 value，所以用item(0)返回索引 0 的节点

利用innerText()方法取出 value，结果是 "John Doe"

对email重复上述三个步骤

所以XML数据的解析过程需要耗时5,000-10,000纳秒，大概是Protocol Buffer的50倍！

所以，为什么要使用Protocol Buffer？

因为Protocol Buffer是序列化结构的二进制数据，所以相比于XML/JSON，它有以下优点：

更简单

数据体积小3-10倍

传输和解析速度快20-100倍

更不容易产生歧义

可编程性更强

为什么要使用gRPC？

知道了为什么要使用Protocol Buffer，就知道了为什么要使用gRPC。虽然可以利用Netconf、Openconfig、REST API对数据中心交换机进行配置管理和状态查询，但如果要对交换机的buffer水线进行监控，这些API就无法胜任了。这种数据量少，但对于实时性要求非常高的应用，只有Protocol Buffer才能胜任。

除了Protocol Buffer之外，gRPC还有另外一个优势——它是基于HTTP/2协议的。

HTTP/2

HTTP/2是一个二进制协议，和Protocol Buffer是绝配。

HTTP/2的一个连接可以有多个stream，能够多路复用。这和802.11无线网络的空间多路复用有点类似，可以提升吞吐性能。多个stream还可以进行优先级管理和流量控制。

HTTP/2还具备Header压缩功能，可以进一步减少数据体积。

此外，它有Push机制。这样gRPC就可以实现client stream和server stream，使得交换机能够主动Push Message给可视化系统平台。