簡介

服務端

Grpc.AspNetCore

客戶端

Google.Protobuf Protobuf 序列化協(xié)議的包

Grpc.Net.Client 客戶端的包

Grpc.Net.ClientFactory HTTPClientFactory集成的包

Grpc.Tools 命令行工具

.proto文件

定義包、庫名

定義服務 “service”

定義輸入輸出模型 “message”

異常

使用 Grpc.Core.RpcException
使用 Grpc.Core.Interceptors.Interceptor

HTTPS證書

使用自制證書

使用非加密 HTTP2

Protocol Buffer

.proto文件

.proto文件包括兩部分：

gRPC服務的定義
服務端和客戶端傳的消息

標量類型

數(shù)值型，數(shù)值型有很多種形式: double, float, int32, int64, uint32, uint64, sint32,sint64,fixed32,fixed64, sfixed32, sfixed64。
根據(jù)需要選擇對應的數(shù)值類型。
布爾型, bool型可以有True和False兩個值。
字符串，string表示任意長度的文本，但是它必須包含的是UTF-8編碼或7位ASCII的文本，長度不可超過232。
字節(jié)型，bytes可表示任意的byte數(shù)組序列，但是長度也不可以超過232，最后是由你來決定如何解釋這些bytes。例如你可以使用這個類型來表示一個圖片。

字段的數(shù)值(Tag)

在Protocol Buffers里面，字段的名其實沒那么重要，但是寫C#代碼的時候，字段名還是很重要的。
對于protobuf來說，這個tag是更為重要的。
可以使用的最小的tag數(shù)值是1，最大值是2²⁹-1,或者536,870,911。但是你不可以使用19000到19999之間的數(shù)，這部分數(shù)是保留的。
還有一點值得注意的是:
從1到15的Tag數(shù)只占用1個字節(jié)的空間，所以它們應該被用在頻繁使用的字段上。而從16到2047，則占用兩個字節(jié)，它們可以用在不頻繁使用的字段上。

字段規(guī)則

protobuf 的字段必須滿足以下兩個規(guī)則之一:

單數(shù)字段(Singular)
大概意思就是指這個字段只能出現(xiàn)0或1次（不能超過一次），這也是proto3的默認字段規(guī)則。
重復字段（Repeated)
與singular相對的就是repeated。如果你想做一個list或數(shù)組的話，你可以使用重復字段這個概念。這個list可以有任何數(shù)量（包括0）的元素。它里面的值的順序將會得到保留

保留的字段

如果你對你定義的消息類型進行了更新，例如刪除某個字段或者注釋掉某個字段，那么其它開發(fā)者在以后更新這個消息類型的時候可能會重新使用被你刪除/注釋掉的字段的數(shù)值(tag)。如果以后還需要使用這個消息類型的老版本的proto文件，那么這將會引起嚴重的問題，例如數(shù)據(jù)損壞、隱私漏洞等等。
那么一種避免此類事情發(fā)生的解決辦法就是將你刪除/注釋掉的這些字段的數(shù)值（或/并且包括字段名，因為字段名可引起JSON序列化的問題）標記為reserved，如果其他人再使用這個數(shù)值作為字段標識符，那么編譯器就會有錯誤提示

message Person {
    int32 id = 1;
    string name = 2;
    float height = 3;
    float weight = 4;
    bytes avatar = 5;
    string email = 6;
    bool email_verified = 7;
    repeated string phone_numbers = 8; // packed
    reserved 9，10，20 to 100，200 to max; //保留9，10，20-100，200以上
    reserved "foo","bar"; //保留字段名
}

字段的默認值

當消息被解析的時候，如果編碼的消息里不含有特定的一個singular元素，那么在被解析對象里相應的字段就會被設為默認值。
常用類型的默認值如下:

string:空字符串
bytes:空的byte數(shù)組。
bool: false
數(shù)值型: 0
枚舉enum:枚舉里定義的第一個枚舉值，值必須是0
repeated:通常是相應開發(fā)語言里的空list
還有個消息類型的字段，它的默認值和開發(fā)語言有關。

默認值在更新Protocol Buffer消息定義的時候有很重要的作用，它可以防止對現(xiàn)有代碼/新代碼造成破壞性影響。它們也可以保證字段永遠不會有null值。

但是，默認值還是非常危險的:
你無法區(qū)分這個默認值到底是來自一個丟失的字段還是字段的實際值正好等于默認值。

需要保證這個默認值對于業(yè)務來說是一個毫無意義的值。例如 Int32 pop (人口）默認值就可以設置為 -1。
再就是，可能需要在你的代碼里來做一些對默認值的判斷，從而進行處理。

枚舉

枚舉里面的常量的值必須不能超過32位整型的數(shù)值，不建議使用負數(shù)。
枚舉可以定義在 message 里面，也可以在外邊單獨定義以便復用。如果另一個消息想使用 Person 里面這個 Gender 枚舉，那么可以使用 Person.Gender 這種形式。

但是如果代碼不知道它接收到的值對應哪個enum值，那么enum的默認值將會被采用。默認值 = 0。

為枚舉值起別名

枚舉值是可以起別名的，起別名的作用就是允許兩個枚舉值擁有同一個數(shù)值。
要想起別名，首先需要設置 allow_alias 這個 option 為 true。
然后我們?yōu)?FEMALE 這個枚舉值起了一個別名叫做 WOMAN，它們的數(shù)值是一樣的。同樣的 MAN 是 MALE 的數(shù)值也是一樣的。

enum Gender {
    option allow_alias = true;
    NOT_SPECIFIED = 0;
    FEMALE = 1;
    MALE = 2;
    WOMAN = 1;
    MAN = 2;
}

import 引用

引用其他文件的 massage 的方法

import "date.Persion"

Packege 命名空間

如果出現(xiàn)兩個文件的 message 都叫 Person，避免沖突

package "my.project"

option csharp_namspace = "My.WebApis" //C#生成指定的命名空間

設置Protocol Buffers編譯器

protoc編譯器主要就是用來生成代碼的，它的下載地址目前是:

https://github.com/protocolbuffers/protobuf/releases/

下載相應的編輯器，這里使用protoc-3.17.3-win64.zip，先設置WINDOWS環(huán)境變量，在使用CMD命令

--csharp_out=OUT_DIR @<filename> 生成文件夾
-IPATH, --proto_path=PATH 指定了要去哪個目錄中搜索import中導入的和要編譯為.cs的proto文件，可以定義多個，
D:Projectspb>protoc --csharp_out=csharp *.proto

更新消息類型的規(guī)則

不要修改任何現(xiàn)有字段的數(shù)字(tag)
你可以添加新的字段，那些使用舊的消息格式的代碼仍然可以將消息序列化，您應該注意這些元素的默認值，以便新代碼可以與舊代碼生成的消息正確交互。類似的，新代碼所創(chuàng)建的消息也可以被舊代碼解析:舊的二進制在解析的時候會忽略新的字段。

字段可以被刪除，只要它們的數(shù)字(tag)在更新后的消息類型中不再使用即可。你也可以把字段名改為使用“OBSOLETE_"前綴而不是刪除字段，或者把這些字段的數(shù)字(tag)進行保留( reserved)，以免未來其它開發(fā)者不消息使用了刪除字段的數(shù)字。

對于數(shù)據(jù)類型的變化，例如int32到int64，string到bytes等等，可以參考官方文檔:
https://developers.google.com/protocol-buffers/docs/proto3#updating。但是建議還是盡量不要去修改字段的數(shù)據(jù)類型。

message Person {
    int32 id = 1;
    string name = 2;
    float height = 3;
    float weight = 4;
    bytes avatar = 5;
    string email = 6;
    bool email_verified = 7;
    repeated string phone_numbers = 8; 
    //（1）刪除字段，要reserved 9，reserved "foo"
    //string foo = 9; 
    reserved 9; 
    reserved "foo"; //保留字段名
    //（2）廢棄字段，加前綴OBSELETE_，就不需要
    string OBSELETE_bar = 10; 
}

gRPC原理

生命周期

身份認證

這里指的不是用戶的身份認證，而是指多個server和client之間，它們?nèi)绾巫R別出來誰是誰，并且能安全的進行消息傳輸。
在身份認證這方面，gRPC一共有4種身份認證的機制:

不采取任何措施的連接，也就是不安全的連接。
TLS/SSL連接。
基于Google Token的身份認證。
自定義的身份認證提供商。

消息傳輸類型

gRPC的消息傳輸類型有4種:

第一種是一元的消息，就是簡單的請求--響應。
第二種是server streaming（流），server會把數(shù)據(jù)streaming回給client。
第三種是client streaming，也就是client會把數(shù)據(jù)streaming給server。
最后是雙向streaming。

一元消息

server streaming

client streaming

雙向streaming

總結

以上是生活随笔為你收集整理的grpc的基础知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。