Go 語言實作 gRPC 的釋出訂閱模式，REST 接口和逾時控制

原文連結： 測試小姐姐問我 gRPC 怎麼用，我直接把這篇文章甩給了她

上篇文章 gRPC，爆贊 直接爆了，内容主要包括：簡單的 gRPC 服務，流處理模式，驗證器，Token 認證和證書認證。

在多個平台的閱讀量都創了新高，在 oschina 更是獲得了首頁推薦，閱讀量到了 1w+，這已經是我單篇閱讀的高峰了。

看來隻要用心寫還是有收獲的。

這篇咱們還是從實戰出發，主要介紹 gRPC 的釋出訂閱模式，REST 接口和逾時控制。

相關代碼我會都上傳到 GitHub，感興趣的小夥伴可以去檢視或下載下傳。

釋出訂閱是一個常見的設計模式，開源社群中已經存在很多該模式的實作。其中 docker 項目中提供了一個 pubsub 的極簡實作，下面是基于 pubsub 包實作的本地釋出訂閱代碼：

這段代碼首先通過 <code>pubsub.NewPublisher</code> 建立了一個對象，然後通過 <code>p.SubscribeTopic</code> 實作訂閱，<code>p.Publish</code> 來釋出消息。

執行效果如下：

訂閱消息可以正常列印。

但有一個死鎖報錯，是因為這條語句 <code>&lt;-make(chan bool)</code> 引起的。但是如果沒有這條語句就不能正常列印訂閱消息。

這裡就不是很懂了，有沒有大佬知道，歡迎留言，求指導。

接下來就用 gRPC 和 pubsub 包實作釋出訂閱模式。

需要實作四個部分：

proto 檔案；

服務端： 用于接收訂閱請求，同時也接收釋出請求，并将釋出請求轉發給訂閱者；

訂閱用戶端： 用于從服務端訂閱消息，處理消息；

釋出用戶端： 用于向服務端發送消息。

首先定義 proto 檔案：

定義三個方法，分别是一個釋出 <code>Publish</code> 和兩個訂閱 <code>Subscribe</code> 和 <code>SubscribeTopic</code>。

<code>Subscribe</code> 方法接收全部消息，而 <code>SubscribeTopic</code> 根據特定的 <code>Topic</code> 接收消息。

對比之前的釋出訂閱程式，其實這裡是将 <code>*pubsub.Publisher</code> 作為了 gRPC 的結構體 <code>PubsubService</code> 的一個成員。

然後還是按照 gRPC 的開發流程，實作結構體對應的三個方法。

最後，在注冊服務時，将 <code>NewPubsubService()</code> 服務注入，實作本地釋出訂閱功能。

建立一個 <code>NewPubsubServiceClient</code> 對象，然後分别實作 <code>client.Subscribe</code> 和 <code>client.SubscribeTopic</code> 方法，再通過 goroutine 不停接收消息。

建立一個 <code>NewPubsubServiceClient</code> 對象，然後通過 <code>client.Publish</code> 方法釋出消息。

當代碼全部寫好之後，我們開三個終端來測試一下：

終端1 上啟動服務端：

終端2 上啟動訂閱用戶端：

終端3 上執行釋出用戶端：

這樣，在 終端2 上就有對應的輸出了：

也可以再多開幾個訂閱終端，那麼每一個訂閱終端上都會有相同的内容輸出。

源碼位址： GitHub

gRPC 一般用于叢集内部通信，如果需要對外提供服務，大部分都是通過 REST 接口的方式。開源項目 grpc-gateway 提供了将 gRPC 服務轉換成 REST 服務的能力，通過這種方式，就可以直接通路 gRPC API 了。

但我覺得，實際上這麼用的應該還是比較少的。如果提供 REST 接口的話，直接寫一個 HTTP 服務會友善很多。

第一步還是建立一個 proto 檔案：

定義一個 REST 服務 <code>RestService</code>，分别實作 <code>GET</code> 和 <code>POST</code> 方法。

安裝插件：

生成對應代碼：

<code>--grpc-gateway_out</code> 參數可生成對應的 gw 檔案，<code>--swagger_out</code> 參數可生成對應的 API 文檔。

在我這裡生成的兩個檔案如下：

這裡主要是通過實作 gw 檔案中的 <code>RegisterRestServiceHandlerFromEndpoint</code> 方法來連接配接 gRPC 服務。

gRPC 服務的實作方式還是和以前一樣。

以上就是全部代碼，現在來測試一下：

啟動三個終端：

終端1 啟動 gRPC 服務：

終端2 啟動 REST 服務：

終端3 來請求 REST 服務：

最後一部分介紹一下逾時控制，這部分内容是非常重要的。

一般的 WEB 服務 API，或者是 Nginx 都會設定一個逾時時間，超過這個時間，如果還沒有資料傳回，服務端可能直接傳回一個逾時錯誤，或者用戶端也可能結束這個連接配接。

如果沒有這個逾時時間，那是相當危險的。所有請求都阻塞在服務端，會消耗大量資源，比如記憶體。如果資源耗盡的話，甚至可能會導緻整個服務崩潰。

那麼，在 gRPC 中怎麼設定逾時時間呢？主要是通過上下文 <code>context.Context</code> 參數，具體來說就是 <code>context.WithDeadline</code> 函數。

建立最簡單的 proto 檔案，這個不多說。

通過下面的函數設定一個 3s 的逾時時間：

然後在響應錯誤中對逾時錯誤進行檢測。

服務端增加一個 <code>handle</code> 函數，其中 <code>case &lt;-time.After(4 * time.Second)</code> 表示 4s 之後才會執行其對應代碼，用來模拟逾時請求。

如果用戶端逾時時間超過 4s 的話，就會産生逾時報錯。

下面來模拟一下：

服務端：

用戶端：

本文主要介紹了 gRPC 的三部分實戰内容，分别是：

釋出訂閱模式

REST 接口

逾時控制

個人感覺，逾時控制還是最重要的，在平時的開發過程中需要多多注意。

結合上篇文章，gRPC 的實戰内容就寫完了，代碼全部可以執行，也都上傳到了 GitHub。

大家如果有任何疑問，歡迎給我留言，如果感覺不錯的話，也歡迎關注和轉發。

源碼位址：

https://github.com/yongxinz/go-example

https://github.com/yongxinz/gopher

推薦閱讀：

gRPC，爆贊

使用 grpcurl 通過指令行通路 gRPC 服務

聽說，99% 的 Go 程式員都被 defer 坑過

參考：

https://chai2010.cn/advanced-go-programming-book/ch4-rpc/readme.html

https://codeleading.com/article/94674952433/

https://juejin.cn/post/6844904017017962504

https://www.cnblogs.com/FireworksEasyCool/p/12702959.html