看到越南小哥 的github 上的Evaluating Performance of REST vs. gRPC ， 使用的是.NET Core 3.0 , 今天我把它更新到.NET Core 3.1 同樣做了一個測試，文章的結果和他的部落格文章是一樣的：https://dev.to/thangchung/performance-benchmark-grpc-vs-rest-in-net-core-3-preview-8-45ak。
在8年前我寫過一篇文章：WCF和ASP.NET Web API在應用上的選擇。 現在是2020年了，WCF換成了gRPC， ASP.NET Web API換成了ASP.NET Core Web API, 對外提供标準化的REST服務，内部通信采用gRPC的也是新時代的.NET應用程式的一個好選擇，類似于Kubernetes 架構将有效負載格式用于傳輸協定的方式。
- REST API：
cd RESTvsGRPC\RestAPI
dotnet run -p RestAPI.csproj -c Release
- gRPC API：
cd RESTvsGRPC\GrpcAPI
dotnet run -p GrpcAPI.csproj -c Release
- 基準項目：
cd RESTvsGRPC\RESTvsGRPC
dotnet run -p RESTvsGRPC.csproj -c Release 等待完成測試後，我們将會得到類似下面的結果，具體的結果依賴于你的測試機器配置，我使用Win10 的Surface Book 2上面完成的下面的測試結果： 
.NET Core 3.1 的REST 和gRPC 性能測試 當接口傳回的資料量比較小時候，REST 的性能要比gRPC要好，當資料量變大之後gRPC的性能優勢就比較明顯了。 .NET Core 3的 json 進行了大量的優化， 在處理消息有效負載中的小資料時會産生巨大的差異，但是實際上，對于大資料有效負載，差異就不複存在了。總體來說 gRPC在這一領域仍然是赢家。我并不是說哪個比另一個更好。我要說的是，我們需要在您的業務案例中使用哪種協定的适當政策。我們通常在與外部世界的外部通信（例如外部服務內建，與前端的通信）中使用REST通信，内部服務之間通信采用gRPC。 參考文獻：
- https://medium.com/@EmperorRXF/evaluating-performance-of-rest-vs-grpc-1b8bdf0b22da
- https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/servers/kestrel
- https://gooroo.io/GoorooTHINK/Article/16623/One-Weird-Trick-To-Improve-Web-Performance/21564#.Vx9o5UdkldB
- https://devblogs.microsoft.com/aspnet/asp-net-core-2-2-0-preview1-http-2-in-kestrel/
- https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/
- https://dev.to/thangchung/performance-benchmark-grpc-vs-rest-in-net-core-3-preview-8-45ak
- https://www.cnblogs.com/shanyou/archive/2012/09/26/2704814.html
歡迎大家掃描下面二維碼成為我的客戶，為你服務和上雲