前面的兩篇文章已經(jīng)基本講述了 gRPC 的使用方法，相信已經(jīng)能夠應(yīng)對大多數(shù)開發(fā)場景了，只不過我們有時候需要針對業(yè)務(wù)作出一些定制，這時候就必須要更加了解 gRPC 的一些特性了，比如：

• 攔截器

• 截止時間

• 取消

攔截器

我把前一篇文章的訂單 Order 服務(wù)的代碼文件拷貝了一份，用來演示這一節(jié)的內(nèi)容。

gRPC 在服務(wù)端和客戶端均可以實現(xiàn)攔截器，首先來看一下服務(wù)端的攔截器。

服務(wù)端攔截器

針對一元通信模式，有對應(yīng)的一元攔截器，攔截器的方法定義如下：

然后需要在服務(wù)端的 main 方法中注冊一下這個攔截器：

實現(xiàn)完成之后，所有服務(wù)端的一元通信模式的方法，都會被這個方法所攔截。

針對服務(wù)端流模式，也有對應(yīng)的流攔截器，方法的定義稍微有一些區(qū)別了。

在接收和發(fā)送消息時，都可以進行攔截，這樣可以根據(jù)業(yè)務(wù)所需定制化。

在服務(wù)端的 main 方法中，還是需要注冊一下這個攔截器：

客戶端攔截器

和服務(wù)端類似，客戶端攔截器也分為了一元攔截器和流攔截器，分別對應(yīng)不同的通信模式。

首先來看看一元攔截器。

然后也需要在監(jiān)聽服務(wù)端的時候注冊攔截器：

然后再來看下客戶端流攔截器，先看下攔截器方法定義：

最后也需要在客戶端的 main 方法中注冊攔截器：

截止時間

再來看一下另一個常用的模式截止時間，gRPC 常用于微服務(wù)之間的通信，而微服務(wù)中，服務(wù)之間的調(diào)用往往存在不確定性，比如網(wǎng)絡(luò)環(huán)境差，數(shù)據(jù)聚合量太大等等，都有可能會導(dǎo)致服務(wù)調(diào)用者長時間等待響應(yīng)結(jié)果。

這樣對于用戶體驗來說非常的不好，并且也很浪費資源，所以微服務(wù)之間需要采用快速失敗的模式，及時釋放資源，不堆積請求，這樣對系統(tǒng)的壓力也會更小。

在 Go 語言中，對 gRPC 截止時間的控制，主要是使用 context 來實現(xiàn)的。下面是一個簡單的 demo：

這里使用了帶有截止時間的 context，如果?AddOrder?方法的調(diào)用超過了截止時間，那么調(diào)用就會被取消。

取消

在某些情況下，我們可能需要取消 RPC 請求，這和設(shè)置截止時間有些類似，都是為了避免請求掛起讓客戶端一直等待，在 Go 語言中，取消的操作仍然借助于 context 來實現(xiàn)。

以一個簡單的例子來說明取消 RPC 的操作：

如果對你有幫助的話，記得點個贊再走哦！

demo 示例代碼放到了我的 GitHub 上：https://github.com/roseduan/grpc-demo