最近項目上做服務間通信准備用gRPC，聽說快，但是到底效果怎么樣呢？
按照網上入門教程使用VS模板建了一個gRPC項目，不測不知道，居然比WebApi慢。
后來搜索到 RiccoYuan 的文章 .netcore - gRPC vs WebApi 耗時比較
他也提到gRPC比WebAPI還慢，不過他在測試中加入了按照官網教程創建的Console版本，這個版本倒是很快。
下面是他的測試結果（我也加入GrpcServiceConsoleApp，測試結果跟他一樣）
最后 RiccoYuan 還在官方倉庫提了個issue，不過官方直接說 it is still faster than JSON + WebAPI.
后來我又看到了一位越南小哥 Thang Chung 的博客
Performance benchmark: gRPC vs. REST in .NET Core 3 Preview 8
張隊的文章在此基礎上升級到了.NET Core 3.1並進行了測試
.NET Core 3.1 的REST 和gRPC 性能測試
得出結論：
當接口返回的數據量比較小時候，REST 的性能要比gRPC要好，當數據量變大之后gRPC的性能優勢就比較明顯了。
我也下載了張隊的代碼進行了測試，結果一致。
為什么我測小數據量的時候，gRPC還是不如WebApi呢？！
我循環100次請求 結果如下：
經過對比代碼我發現了差別：
我按照網上及微軟官方教程創建的客戶端代碼：
var channel = GrpcChannel.ForAddress("https://localhost:5001"); var client = new Greeter.GreeterClient(channel);
越南小哥的代碼，也是上面提到gRPC官網的Console版本客戶端代碼（這個方法比上面快哦）：
var channel = new Channel("127.0.0.1:5000", ChannelCredentials.Insecure); var client = new Greeter.GreeterClient(channel);
修改代碼后再來，我多跑了幾遍供大家參考，提升迅猛有木有：
上面的測試我是在循環內部創建Channel的，既然這么耗時，那我把最初的代碼中的創建部分放到循環外部，果然跟我想的一樣，性能好了很多：
從 RiccoYuan 測試結果的圖片也能看出來這個問題。
綜上所述：創建Channel是關鍵（微軟gRPC的介紹中也提到，如下圖），還是采用gRPC官方的方式吧。
如果就想用微軟的，盡量重用，避免頻繁的創建操作。
寫在最后：我沒去研究這兩種創建方式到底差在哪里，有大神如果清楚也可以在下面留言，告訴我一下，謝謝啦。