微服務架構上篇：1- grpc 技術介紹

1. 微服務架構上篇 ==========

2. grpc 技術介紹

1. grpc 介紹

gRPC是 Google 開源的基於 Protobuf 和 Http2.0 協議的通信框架，Google 深度學習框架 tensorflow 底層的 RPC 通信就完全依賴於 gRPC 庫。Google 的開源影響力很大，目前已經有非常多的大型互聯網公司在使用 gRPC 了。比如國產開源數據庫影響力最大的 Tidb 就選擇了 gRPC 作爲底層通訊庫。

2. grpc 基於 Http2.0 原因

gRPC 之所以選擇 Http2.0 作爲基礎開源協議，是考慮到 Http 協議在互聯網應用的廣泛性。同時因爲 Http2.0 支持的 Streaming 和 Duplexing 可以將請求和響應消息進行分片交叉傳送，可以大幅提升傳輸效率，GRPC 特色的 Stream 消息正是使用了 Http2.0 的 Streaming 特性。

關於HTTP2.0大家下來自行研究哈，這不是本文重點內容。

3. grpc 架構圖

首先定義服務，指定其能夠被遠程調用的方法，包括參數和返回類型，這裏使用 protobuf 來定義服務。在服務端實現定義的服務接口，並運行一個 gRPC 服務器來處理客戶端調用。

4. grpc 原理

1. gRPC 消息由 netty /http/2 協議負責接入，通過 grpc 註冊的 Http2Framelister 將解碼後的 Http header 和 Http body 發送到 gRPC 的 NettyServerHandler ，實現 netty http/2 的消息接入

2. gRPC 的線程模型遵循 Netty 的線程分工原則，即：協議層消息的接收和編解碼由 Netty 的 I/O(NioEventLoop) 線程負責；後續應用層的處理由應用線程負責，防止由於應用處理耗時而阻塞 Netty 的 I/O 線程 (因爲分工原則，grpc 之間會做頻繁的線程切換，如果在一次 grpc 調用過程中，做了多次 I/O 線程到應用線程之間的切換，會導致性能的下降 所以一些私有協議不太友好)

5. grpc 模型

異步非阻塞的線程模型

服務端線程模型主要包括

1. 服務端的寫入，客戶端的接入線程（HTTP/2 Acceptor）

2. 網絡 I/O 的讀寫線程

3. 服務接口調用線程

客戶端線程模型主要包含

1. 客戶端的鏈接 （HTTP/2 Connector）

2. 網絡 I/O 讀寫線程

3. 接口調用線程

4. 響應回調通知線程

6. grpc 優勢

• 多語言 Grpc 的多語言是他做的很牛逼的地方，特別是在設備端，客戶端支持 ios，android，而基於 http2.0 的多路複用也的確讓設備真正的省了流量，省了電，也省了空間

• 基於 Http2.0 採用 HTTP2 的好處在於, 因爲添加了頭信息, 可以方便在框架層面對調用做攔截和控制 (比如說限流, 調用鏈分析, 安全認證等) 而且 http2 爲標準協議, 也方便以後擴展兼容其它調用端。

7. 小結

這篇文章主要是對原理和概念介紹，下篇文章我們以實戰爲主，重點講解 golang+grpc+protobuf+gateway 的技術應用，歡迎大家轉發關注和分享哈。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5cvujhvkVNFG3uG2IKgypg