當然最最最重要的就是性能，在使用RPC的場景下對於多個程序通訊完成業務所消耗的性能是有巨大挑戰的，筆者也做了一套完整的性能測試大家可以繼續往下看。
附上:
喵了個咪的博客：w-blog.cn
博文實例demo：GitHub - sunmi-OS/grpc-php-to-golang-demo
grpc官網：grpc / grpc.io
protobuf代碼倉庫：Releases · protocolbuffers/protobuf · GitHub
一，服務器配置
- E5 - 2680V2 * 4
- 8G ddr3 1600Mhz
- ab工具壓測
分別對以下兩種場景進行測試：
- GO -> （Grpc） -> GO
- PHP -> （Grpc） -> GO
- GO -> （HTTP） -> GO
- PHP -> （HTTP） -> GO
GO通過一個開發一個http的api來進行rpc調用，下面稱爲api_client：
二，基準線
壓測需要一個基準線作爲參考
PHP直接echo 基準線是16K
go echo 基準是 20k
go echo -k 基準是74K
三，GO -> （Grpc） -> GO
CPU資源消耗 363%，壓力17K，相對20K基準差距3K
使用 -k 維持鏈接 CPU資源消耗 358%，壓力28K，相對74K基準差距46K
四，PHP -> （Grpc） -> GO
資源消耗396%，壓力3.5K，相對16K基準差距12.5K
-k 資源消耗393%，壓力3.4K，相對16K基準差距12.6K
壓測結果
五，GO -> （HTTP） -> GO
資源消耗361%，壓力8K，相對74K基準差距66K
-k資源消耗357%，壓力11K，相對74K基準差距63K
六，PHP -> （HTTP） -> GO
資源消耗386%，壓力6.8K，相對16K基準差距9.2K
七，結論
- GO 基準 74k
- PHP 基準 16k
- GO -> （Grpc） -> GO 壓力28K
- PHP -> （Grpc） -> GO 壓力 3.5K
- GO -> （HTTP） -> GO 壓力8.3K
- PHP -> （HTTP） -> GO 壓力6.8K
更具整體結果得到以下結論：
- 對於GO與GO之前通訊Grpc遠遠優於http協議
- PHP調用GO提供的服務，都有很大的開銷，http整體資源消耗和併發能力優於Grpc，Grpc依賴太重導致了PHP引入文件很慢，PHP更時候HTTP調用方式
PS：那麼有沒有什麼方式只需要開發一次就能都支持HTTP和Grpc，PHP調用http，Go調用Grpc，因此就有了後面的Grpc-gateway的內容了