前言：隨著.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、以上就是本文章的全部內容。歡迎大佬們留言、點贊或轉發推廣~~