[TOC]
# 優缺點
## protoBuf的優點
Protobuf 有如 XML,不過它更小、更快、也更簡單。你可以定義自己的數據結構,然后使用代碼生成器生成的代 碼來讀寫這個數據結構。你甚至可以在無需重新部署程序的情況下更新數據結構。只需使用 Protobuf 對數據結構 進行一次描述,即可利用各種不同語言或從各種不同數據流中對你的結構化數據輕松讀寫。
它有一個非常棒的特性,即“向后”兼容性好,人們不必破壞已部署的、依靠“老”數據格式的程序就可以對數據結構 進行升級。
Protobuf 語義更清晰,無需類似 XML 解析器的東西(因為 Protobuf 編譯器會將 .proto 文件編譯生成對應的數據 訪問類以對 Protobuf 數據進行序列化、反序列化操作)。使用 Protobuf 無需學習復雜的文檔對象模型, Protobuf 的編程模式比較友好,簡單易學,同時它擁有良好的文檔和示例,對于喜歡簡單事物的人們而言, Protobuf 比其他的技術更加有吸引力。
## ProtoBuf 的不足
Protobuf 與 XML 相比也有不足之處。它功能簡單,無法用來表示復雜的概念。
XML 已經成為多種行業標準的編寫工具,Protobuf 只是 Google 公司內部使用的工具,在通用性上還差很多。 由 于文本并不適合用來描述數據結構,所以 Protobuf 也不適合用來對基于文本的標記文檔(如 HTML)建模。另 外,由于 XML 具有某種程度上的自解釋性,它可以被人直接讀取編輯,在這一點上 Protobuf 不行,它以二進制的 方式存儲,除非你有 .proto 定義,否則你沒法直接讀出 Protobuf 的任何內容
# 安裝
~~~
#下載 protoBuf:
$ git clone https://github.com/protocolbuffers/protobuf.git
#或者直接將壓縮包拖入后解壓 unzip protobuf.zip
#安裝依賴庫
$ sudo apt-get install autoconf automake libtool curl make g++ unzip libffi- dev -y
#安裝
$ cd protobuf/
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo ldconfig # 刷新共享庫 很重要的一步啊
#安裝的時候會比較卡
#成功后需要使用命令測試
$ protoc –h
~~~
**獲取proto包**
~~~
#Go語言的proto API接口
go get -u github.com/golang/protobuf/proto
~~~
**安裝protoc-gen-go插件**
它是一個 go程序,編譯它之后將可執行文件復制到\\bin目錄
~~~
#安裝
$ go get -v -u github.com/golang/protobuf/protoc-gen-go #編譯
$ cd $GOPATH/src/github.com/golang/protobuf/protoc-gen-go/ $ go build
#將生成的 protoc-gen-go可執行文件,放在/bin目錄下
$ sudo cp protoc-gen-go /bin/
~~~
# protobuf的語法
要想使用 protobuf必須得先定義 proto文件。
所以得先熟悉 protobuf的消息定義的相關語法。
定義一個消息類型
~~~
syntax = "proto3";
message PandaRequest {
string name = 1;
int32 shengao = 2;
repeated int32 tizhong = 3;
}
~~~
PandaRequest消息格式有3個字段,在消息中承載的數據分別對應于每一個字段。其中每個字段都有一個名字和 一種類型。
文件的第一行指定了你正在使用proto3語法:如果你沒有指定這個,編譯器會使用proto2。這個指定語法行必須 是文件的非空非注釋的第一個行。
在上面的例子中,所有字段都是標量類型:兩個整型(shengao和tizhong),一個string類型(name)。
**Repeated** 關鍵字表示重復的那么在go語言中用切片進行代表 正如上述文件格式,在消息定義中,每個字段都有唯一的一個標識符
**添加更多消息類型**
在一個.proto文件中可以定義多個消息類型。在定義多個相關的消息的時候,這一點特別有用——例如,如果想定義與SearchResponse消息類型對應的回復消息格式的話,你可以將它添加到相同的.proto文件中
~~~
syntax = "proto3";
message PandaRequest {
string name = 1;
int32 shengao = 2;
int32 tizhong = 3;
}
message PandaResponse {
...
}
~~~
# 從.proto文件生成了什么?
當用protocol buffer編譯器來運行.proto文件時,編譯器將生成所選擇語言的代碼,這些代碼可以操作在.proto文件中定義的消息類型,包括獲取、設置字段值,將消息序列化到一個輸出流中,以及從一個輸入流中解析消息。
對C++來說,編譯器會為每個.proto文件生成一個.h文件和一個.cc文件,.proto文件中的每一個消息有一個對應的 類。
對Python來說,有點不太一樣——Python編譯器為.proto文件中的每個消息類型生成一個含有靜態描述符的模 塊,,該模塊與一個元類(metaclass)在運行時(runtime)被用來創建所需的Python數據訪問類。
對go來說,編譯器會為每個消息類型生成了一個.pd.go文件
# 標準數據類型
一個標量消息字段可以含有一個如下的類型——該表格展示了定義于.proto文件中的類型,以及與之對應的、在自 動生成的訪問類中定義的類型:

# 默認值
~~~
當一個消息被解析的時候,如果被編碼的信息不包含一個特定的元素,被解析的對象鎖對應的域被設置位一個默認
值,對于不同類型指定如下:
~~~
對于strings,默認是一個空string
對于bytes,默認是一個空的bytes
對于bools,默認是false
對于數值類型,默認是0
# 使用其他消息類型
你可以將其他消息類型用作字段類型。
例如,假設在每一個PersonInfo消息中包含Person消息,此時可以在相同 的.proto文件中定義一個Result消息類型,然后在PersonInfo消息中指定一個Person類型的字段
~~~
message PersonInfo {
repeated Person info = 1;
}
message Person {
string name = 1;
int32 shengao = 2;
repeated int32 tizhong = 3;
}
~~~
# 使用proto2消息類型
在你的proto3消息中導入proto2的消息類型也是可以的,反之亦然,然后proto2枚舉不可以直接在proto3的標識
符中使用(如果僅僅在proto2消息中使用是可以的)。
嵌套類型 你可以在其他消息類型中定義、使用消息類型,在下面的例子中,Person消息就定義在PersonInfo消息內,如:
~~~
message PersonInfo {
message Person {
string name = 1;
int32 shengao = 2;
repeated int32 tizhong = 3;
}
repeated Person info = 1;
}
~~~
如果你想在它的父消息類型的外部重用這個消息類型,你需要以PersonInfo.Person的形式使用它,如:
~~~
message PersonMessage {
PersonInfo.Person info = 1;
}
~~~
當然,你也可以將消息嵌套任意多層,如:
~~~
message Grandpa {
message Father { // Level 1
message son { // Level 2
string name = 1;
int32 age = 2;
} }
message Uncle { // Level 1
message Son { // Level 2
string name = 1;
int32 age = 2;
}
}
}
~~~
# 定義服務(Service)
如果想要將消息類型用在RPC(遠程方法調用)系統中,可以在.proto文件中定義一個RPC服務接口,protocol buffer 編譯器將會根據所選擇的不同語言生成服務接口代碼及存根。如,想要定義一個RPC服務并具有一個方法,該方法 能夠接收 SearchRequest并返回一個SearchResponse,此時可以在.proto文件中進行如下定義:
~~~
service SearchService {
//rpc 服務的函數名 (傳入參數)返回(返回參數)
rpc Search (SearchRequest) returns (SearchResponse);
}
~~~
最直觀的使用protocol buffer的RPC系統是gRPC一個由谷歌開發的語言和平臺中的開源的RPC系統,gRPC在使用 protocl buffer時非常有效,如果使用特殊的protocol buffer插件可以直接為您從.proto文件中產生相關的RPC代 碼。
如果你不想使用gRPC,也可以使用protocol buffer用于自己的RPC實現,你可以從proto2語言指南中找到更多信息
# 生成訪問類
可以通過定義好的.proto文件來生成Java,Python,C++, Ruby, JavaNano, Objective-C,或者C# 代碼,需要基 于.proto文件運行protocol buffer編譯器protoc。如果你沒有安裝編譯器,下載安裝包并遵照README安裝。對于 Go,你還需要安裝一個特殊的代碼生成器插件。你可以通過GitHub上的protobuf庫找到安裝過程
通過如下方式調用protocol編譯器:
~~~
protoc --proto_path=IMPORT_PATH --cpp_out=DST_DIR --python_out=DST_DIR --go_out=DST_DIR path/to/file.proto
~~~
~~~
protoc --go_out=./ *.proto
~~~
IMPORT\_PATH聲明了一個.proto文件所在的解析import具體目錄。如果忽略該值,則使用當前目錄。如果有多個 目錄則可以多次調用\--proto\_path,它們將會順序的被訪問并執行導入。\-I=IMPORT\_PATH是\--proto\_path的簡化 形式。
當然也可以提供一個或多個輸出路徑:
`--cpp_out` 在目標目錄`DST_DIR`中產生C++代碼,可以在C++代碼生成參考中查看更多。 `--python_out` 在目標目錄 `DST_DIR` 中產生Python代碼,可以在Python代碼生成參考中查看更多。
`--go_out` 在目標目錄 `DST_DIR` 中產生Go代碼,可以在GO代碼生成參考中查看更多。 作為一個方便的拓展,如 果DST_DIR以.zip或者.jar結尾,編譯器會將輸出寫到一個ZIP格式文件或者符合JAR標準的.jar文件中。注意如果輸 出已經存在則會被覆蓋,編譯器還沒有智能到可以追加文件
\- 你必須提議一個或多個.proto文件作為輸入,多個.proto文件可以只指定一次。雖然文件路徑是相對于當前目錄 的,每個文件必須位于其IMPORT\_PATH下,以便每個文件可以確定其規范的名稱。
# 測試下
在這個prototext包下創建text.proto文件
~~~
syntax = "proto3";
package prototext;
message Test {
//姓名
string name = 1;
//體重
repeated int32 tizhing = 2;
//身高
repeated int64 shengao = 3;
//格言
string motto = 4;
}
~~~
生成下
~~~
protoc --go_out=./ *.proto
~~~
寫個測試文件,對protoBuf進行編碼解碼
~~~
package main
import (
"fmt"
"github.com/gogo/protobuf/proto"
"studygo/prototext"
)
func main() {
text := &prototext.Test{
//里面寫我們的東西
Name: "panda",
Tizhing: []int32{120, 125, 198, 150},
Shengao: []int64{1, 44, 555},
Motto: "我的 hello world",
}
fmt.Println(text)
//proto編碼 ([]byte, error)
bytes, err := proto.Marshal(text)
if err != nil {
fmt.Println("編碼失敗")
}
//編碼后打印
fmt.Println(bytes)
//解碼,解碼后會放到這里
newText := &prototext.Test{}
//proto的解碼
e := proto.Unmarshal(bytes, newText)
if e != nil {
fmt.Println("解碼失敗")
}
//打印解碼的結果 newText.String()
fmt.Println(newText)
fmt.Println(newText.Motto)
}
~~~
# GRPC使用protobuf
gRPC默認使用protoBuf,這是 Google開源的一套成熟的結構數據序列化機制(當然也可以使用其他數據格式如 JSON)。正如你將在下方例子里所看到的,你用 proto files創建 gRPC服務,用 protoBuf消息類型來定義方法參 數和返回類型

## protobuf協議定義
創建一個 protobuf package,
如: my\_rpc\_proto; 在$GOPATH/src/下創建 /my\_grpc\_proto/文件夾
里面創建 protobuf協議文件 helloServer.proto
- 基礎
- 簡介
- 主要特征
- 變量和常量
- 編碼轉換
- 數組
- byte與rune
- big
- sort接口
- 和mysql類型對應
- 函數
- 閉包
- 工作區
- 復合類型
- 指針
- 切片
- map
- 結構體
- sync.Map
- 隨機數
- 面向對象
- 匿名組合
- 方法
- 接口
- 權限
- 類型查詢
- 異常處理
- error
- panic
- recover
- 自定義錯誤
- 字符串處理
- 正則表達式
- json
- 文件操作
- os
- 文件讀寫
- 目錄
- bufio
- ioutil
- gob
- 棧幀的內存布局
- shell
- 時間處理
- time詳情
- time使用
- new和make的區別
- container
- list
- heap
- ring
- 測試
- 單元測試
- Mock依賴
- delve
- 命令
- TestMain
- path和filepath包
- log日志
- 反射
- 詳解
- plugin包
- 信號
- goto
- 協程
- 簡介
- 創建
- 協程退出
- runtime
- channel
- select
- 死鎖
- 互斥鎖
- 讀寫鎖
- 條件變量
- 嵌套
- 計算單個協程占用內存
- 執行規則
- 原子操作
- WaitGroup
- 定時器
- 對象池
- sync.once
- 網絡編程
- 分層模型
- socket
- tcp
- udp
- 服務端
- 客戶端
- 并發服務器
- Http
- 簡介
- http服務器
- http客戶端
- 爬蟲
- 平滑重啟
- context
- httptest
- 優雅中止
- web服務平滑重啟
- beego
- 安裝
- 路由器
- orm
- 單表增刪改查
- 多級表
- orm使用
- 高級查詢
- 關系查詢
- SQL查詢
- 元數據二次定義
- 控制器
- 參數解析
- 過濾器
- 數據輸出
- 表單數據驗證
- 錯誤處理
- 日志
- 模塊
- cache
- task
- 調試模塊
- config
- 部署
- 一些包
- gjson
- goredis
- collection
- sjson
- redigo
- aliyunoss
- 密碼
- 對稱加密
- 非對稱加密
- 單向散列函數
- 消息認證
- 數字簽名
- mysql優化
- 常見錯誤
- go run的錯誤
- 新手常見錯誤
- 中級錯誤
- 高級錯誤
- 常用工具
- 協程-泄露
- go env
- gometalinter代碼檢查
- go build
- go clean
- go test
- 包管理器
- go mod
- gopm
- go fmt
- pprof
- 提高編譯
- go get
- 代理
- 其他的知識
- go內存對齊
- 細節總結
- nginx路由匹配
- 一些博客
- redis為什么快
- cpu高速緩存
- 常用命令
- Go 永久阻塞的方法
- 常用技巧
- 密碼加密解密
- for 循環迭代變量
- 備注
- 垃圾回收
- 協程和纖程
- tar-gz
- 紅包算法
- 解決golang.org/x 下載失敗
- 逃逸分析
- docker
- 鏡像
- 容器
- 數據卷
- 網絡管理
- 網絡模式
- dockerfile
- docker-composer
- 微服務
- protoBuf
- GRPC
- tls
- consul
- micro
- crontab
- shell調用
- gorhill/cronexpr
- raft
- go操作etcd
- mongodb