Golang gRPC微服務01: 介紹

gRPC 是什麼

gRPC是goole開源的一個RPC框架和庫，支持多語言之間的通訊。底層通訊採用的是 HTTP2 協議。gRPC在設計上使用了 ProtoBuf 這種接口描述語言。這種IDL語言能夠定義各類服務，google還提供了一種工具 protoc 來編譯這種IDL語言，生成各類各樣的語言來操做服務。

gPRC特色

• 定義服務簡單，能夠很快的搭建出一個RPC調度的服務
• gRPC是與語言無關，平臺無關的。你定義好了一個protobuf協議，就能夠用protoc生成不一樣語言的協議框架
• 使用HTTP2協議，支持雙向流。客戶端和服務端能夠雙向通訊

gRPC爲了解決什麼問題

gRPC其實就是一種RPC，解決服務的遠程過程調用問題。
它使得咱們遠程調用就像調用本地函數同樣，程序員無需關心交互的細節。

RPC與RESTful區別是什麼

• 在客戶端和服務端通訊還有一種基於http協議的 RESTful 架構模式，RESTful通常是對於資源的操做，它是名詞（資源地址），而後添加一些動做對這些資源進行操做。
  而RPC是基於函數，它是動詞。

• RPC通常基於TCP協議，固然gRPC是基於HTTP2，但它也是比HTTP協議更加有效率和更多特性。
  RESTful通常都是基於HTTP協議

• 傳輸方面：自定義的TCP協議或者使用HTTP2協議，報文體積更小，因此傳輸效率更高
                  RESTful通常基於http協議，報文體積大

• gRPC用的是protobuf的IDL語言，會編碼爲二進制協議的數據，而RESTful通常是用json的數據格式，因此json格式的編解碼更耗時

爲何仍是有不少公司用RESTful

以函數爲基礎的模式（RPC），若是服務端添加了一個函數，那麼客戶端也必須添加一個函數。
而以資源爲操做基礎的RESTful，URI對應的服務變化了，客戶端通常是不須要關心和更新的，它對客戶端是透明的。
因此RPC的操做變動，有時比RESTful的複雜，由於RCP須要2邊都要添加代碼，也就增長了工做量。

而且json格式是可閱讀的格式，gRPC編碼後是二進制格式，對人不友好，不利於閱讀.
調試排錯RPC也比RESTful難，畢竟HTTP你們都很熟悉，而RPC協議通常是自定義協議，須要程序員本身去研究。

那怎麼選擇呢？RPC OR RESTful

通常公司內部服務併發大，效率要求比較高的，能夠用RPC。因此通常大公司內部用RPC比較多。不過大公司對外提供的api不少都是基於http的RESTful，爲何？由於這個簡單、易懂，你們都熟悉，使用就方便。

而業務量比較小，併發小，能夠直接用RESTful，json，不論是公司內部服務間通訊，仍是對外提供api服務。

因此選擇：都是根據本身公司業務需求來判斷，適合使用哪一種，就選擇哪一種，不要盲目跟風，形成公司沒必要要的資源浪費。

golang中使用RESTful，用json傳輸數據，通常使用 https://github.com/gorilla/mux , https://github.com/gin-gonic/gin, https://github.com/labstack/echo，https://github.com/emicklei/go-restful 等
golang中的RPC如今通常使用g家的gRPC, https://grpc.io/, 畢竟你們都相信g家的技術實力 - -!

Protocol Buffers

這是google開源的而且很是成熟的用於數據結構序列化的框架。
使用protocol來序列化數據，須要編寫一個proto文件，在proto文件中定義你的服務，rpc操做，返回和請求數據格式。
protocol buffers的數據是一個結構化的消息，每一個消息都是一小的邏輯信息的記錄，消息中包含了一系列的鍵值對，稱之爲屬性，一個簡單的例子：

message Person {
   string name = 1;
   int32 age = 2;
   bool isPay = 3;       
}

定義了你傳輸的數據結構，就能夠用protoc來生成對應語言的代碼。這些代碼提供了方法，能夠操做每一個屬性，能夠將數據序列化爲元數據傳輸給對方，也能夠將對方發送過來的元數據進行解析。
例子：

// The greeter service definition.
service Greeter {
   //Sends a greeting
   rpc SayHello (HelloRequest) returns (HelloReply) {}
}
 
// The request message containing the user's name.
message HelloRequest {
   string name = 1;
}
 
//The response message containing the greetings
message HelloReply {
   string message = 1;
}

gRPC可使用帶插件的 protoc 命令，將你編寫的proto文件生成代碼。使用gRPC的插件的時候，你能夠生成gRPC的客戶端和服務端代碼，和通常的protocol buffers代碼同樣，
能夠構建，序列化，反序列化消息。

Protocol Buffer 官方文檔： https://developers.google.com/protocol-buffers/docs/overview
從這裏也能夠獲取 protoc 插件，從而生成你擅長語言的代碼。

gRPC的四種定義方式

gRPC容許用戶定義四種形式的rpc方法(原文參照：https://grpc.io/docs/guides/concepts.html)：

A.客戶端發送請求到服務端，而後服務端給出一個響應，就像一個普通的方法定義同樣，以下所示：

rpc SayHello(HelloRequest) returns (HelloResponse) {};

B.服務端的流式rpc：客戶端發送一個請求到服務端，而後獲得一個流用於讀取服務端的的消息，客戶端從返回的流中讀取全部的信息，以下所示：

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse) {};

C.客戶端流式rpc： 客戶端使用流將信息發送個服務端，只要客戶端發送完全部的信息給服務器，就開始等待服務端的響應，以下所示：

rpc LotsOfGreeting(stream HelloRequest) returns (HttpResponse) ;

D.雙向流式rpc：服務端與客戶端都是用讀寫流發送數據給對方。這兩個流式相互獨立的，因此他們的讀寫能夠是任意順序的，例如：服務端在接受到客戶的全部的信息以前就已經開始響應，
也能夠先讀取數據而後再寫數據，或者其餘任何組合，以下所示：

rpc SayHello(stream HelloRequest) returns (HelloResponse) ;