前言：隨着.Net6的發佈，Minimal API成了當下受人追捧的角兒。而這之前，程序之間通信效率的王者也許可以算得上是gRPC了。那麼以下咱們先通過開發一個gRPC服務的教程，然後順勢而為，再接着比拼一下minimal api服務和gRPC服務在通信上的效率。以下,Enjoy:

1、創建一個gRPC服務項目。開發模板選項如下圖所示。

 

 

2、新建項目MyFirstGRPCService，用來開發gRPC服務端使用。

 

 

 

 

3、選擇.Net6 LTS版本。

 

 

 

 

4、初始項目，自動引用了包 Grpc.AspNetCore，用於提供gRPC基礎服務。以及Protos文件夾下有proto文件，services文件夾下有與之對應的類文件。

 

 

 

 

5、proto文件和對應的類文件的內容比對，以及它們之間的關係。

 

 

 

 

6、新增一個test.proto文件，定義服務名稱和方法名稱，以及參數和返回值屬性。

 

 

 

 

7、項目文件，可以看到新增的proto文件被自動引入到項目裏面。

 

 

 

 

8、添加完畢需要生成一下。此處更正個錯誤，proto文件裏面,int類型需要指定為int32，否則會出問題。然後在項目目錄下cmd，執行dotnet run一下。

 

 

 

 

9、執行dotnet run 以後。會在根目錄的obj文件夾下，產生一個以Grpc結尾的中間類文件，該文件裏面提供了服務有關的內容實現。

 

 

 

 

10、然後新增一個測試服務類，此時就可以引用自動生成的文件裏面提供的Grpc類，該類和proto文件裏面定義的保持一致。

 

 

 

 

11、在服務裏面重寫方法，以及提供參數。注意空參數也需要傳一個Empty類型的參數進去。可以自行比對重寫的服務與proto文件的一些關聯點。

 

 

 

 

12、新增一個控制台項目TestConsole,當作客戶端，用來做交互使用。並且引入所需要的包，包括Google.Protobuf、Grpc.Net.Client和Grpc.Tools。

 

 

 

 

13、把protos文件，直接複製到客戶端項目目錄下。Proto文件起到一個中間連接的作用，類似WCF服務的契約代理類。

 

 

 

 

14、GRPC服務端的program文件裏面，對剛才新增的TestService服務進行註冊(類似依賴注入的註冊)。

 

 

 

 

15、打開服務端項目文件，拷貝裏面的proto的引用地址。

 

 

 

 

16、客戶端對應的proto內容在人品好的情況下，會在拷貝proto文件的時候自動生成。如果人品不好的情況下，就需要從服務端裏面拷貝了。拷貝過來以後，需要把Server改為Client，用來指示該服務是面向客戶端的。

 

 

 

 

17、按照服務端一樣的方式，在項目目錄下cmd，輸入dotnet run，顯示Hello,World的時候（控制台程序program裏面默認有個輸出的，沒有刪除，所以會顯示），在obj路徑下會生成中間類文件。服務端生成的是面向服務的的，客戶端生成的是面向客戶端的。

 

 

 

 

18、新建一個測試類，用來測試GRPC客戶端調用的。客戶端調用需要指定訪問的GRPC地址，地址當前服務端沒有指定，咱們可以在服務端的launchSettings.json文件裏面獲取到。

 

 

 

 

19、測試服務類需要靜態引用我們在proto文件定義的服務，然後在測試方法裏面進行遠程過程調用。

 

 

 

 

20、啟動GRPC服務端，然後客戶端調用測試方法，並啟動，獲得到了GRPC服務端返回的結果內容，說明我們搭建的簡單的gRPC服務端和客戶端程序OK。

 

 

 

 

21、接下來進行一個對比測試。關於使用webapi和gRPC的訪問性能測試。先新建一個minimal api項目：TestPerformanceApi。

 

 

 

 

22、新增一個POST請求方式的api接口Test，用於做測試使用。為了簡單些，不帶參數並且只返回兩個寫死的屬性，一個name和一個age。（備註：如果不曉得minimal api的，可以查看我的另一篇關於minimal api的文章）。

 

 

 

 

23、新增一個控制台程序，用於測試訪問minimal api服務使用。有關代碼和引用的包，如下圖所示。此處循環訪問500次進行測試，訪問方式使用HttpClientFactory。

 

 

 

24、訪問gRPC的服務，也加個循環500次調用。

 

 

 

 

25、既然都寫到這裡了，那同時也新增一個傳統的webapi項目好了，一起驗證下。

 

 

 

 

26、新增一個測試傳統webapi的項目TestTraditionalApi，然後新增一個Test2的api控制器，有關代碼如圖所示。為了保持和minimal api地址一致，減少其他可能性損耗，route路由也直接指定了action。

 

 

 

 

27、再新增一個控制台項目，用來測試訪問傳統webapi。代碼同測試mini api的控制台程序，只是訪問的URL地址不一樣。

 

 

 

 

28、啟動gRPC服務、minimal API服務、以及傳統webapi服務。為了防止先啟動的控制台佔據資源優勢，以及避免啟動項的項目佔據資源優勢，新增一個無任何功能的項目當作啟動項，然後服務全部從 調試-啟動新實例 裏面進行打開。

 

 

 

29、訪問500次gRPC服務結果：

 

 

 

30、訪問500次 minimal api服務結果：

 

 

 

 

31、訪問500次傳統webapi服務結果。

 

 

 

 

32、為了防止其他可能性干擾，我把控制台輸出其他信息全部屏蔽掉，並且循環次數新增到2000次，並且均測試兩次，降低首次訪問創建實例期間的延遲。其他代碼雷同，均增加至2000次*2,並取消控制台打印。

 

 

 

 

33、先測試gRPC服務的結果。第一個2000次訪問，耗時4399ms，第二次耗時3140ms.

 

 

 

 

34、然後是minimal api。第一個2000次使用了53347ms,第二個2000次使用了52459ms.

 

 

 

 

35、訪問傳統的webapi,第一個2000次使用了92025ms，第二個2000次訪問，使用了90627ms.

 

 

 

 

36、gRPC效率有點偏高，為了防止可能是網絡震蕩導致的問題，最後再重新測一次。第一個2000次使用了68709ms，第二個2000次使用了65987ms

 

 

 

 

37、結論：由此可見，在沒有任何其他限制情況下，minimal api的訪問效率最高，gRPC服務次之，傳統webapi最慢。gRPC此處是傳入了參數，所以也有可能增加了些許時差，有興趣的小夥伴可以自行繼續測試。

本輪測試使用的開發環境是VS2022企業版，運行環境全部都是.NET 6，本地機器配置(五年多的老古董了)，可以參考如下截圖：

 

 

 

 

 

38、以上就是本文章的全部內容。歡迎大佬們留言、點贊或轉發推廣~~