1樓：k8seasy
一種rpc好不好，自身效能是乙個方面更多的是限流日誌健康檢查監控分布式呼叫連分析和現在語言系統的配合這些方面。如果體系不完整。想和現有的體系競爭很難。
相對比的是sofa stack。螞蟻金服的東西，不說它好不好，但是你可以看看它提供了多少元件建立這個體系。這不是乙個簡單的序列號反序列化執行的簡單業務。grpc太單薄了。
2樓：濤叔
gRPC 功能強則強矣，但太複雜。gRPC 強依賴 http/2 實則為實現 stream RPC 這種特性，而這種特性又不怎麼常用。偶爾有需要 stream 介面的地方，起乙個 tcp 服務就足以應付，沒必要引入 gRPC。
濤叔：Twirp: 極簡 RPC
3樓：無名
文件啊，文件啊，文件啊！現有的官方文件只是個demo級別的！現在在用C++做乙個etcd的client，對於怎樣迅速發現server岩機還是沒有非常好的解決辦法。
4樓：Ehco
我廠現在的新專案基本上都是基於grpc了
另外還開源了乙個輕量級的框架 Sea
shanbay.github.io/sea/#/有興趣的小夥伴可以看看
5樓：不能說的秘密
使用protobuffer，壓縮效率非常高基於HTTP2，具有流雙向流傳輸等特性
客戶端，服務端基於同乙份.proto檔案來編碼不容易出錯效能不清楚
6樓：
我自己感覺grpc的前途非常好。
對任何RPC協議來說，最重要的兩個因素是內容互動格式和傳輸協議。
內容交換格式
grpc 採用的protocol buffer，開源已久，序列化和反序列化的速度都比thrift還要稍微好點的。
傳輸協議
grpc採用了http2, 效能比http1.1好的不是一星半點啊。
HTTP2的多路復用，頭壓縮都好了很多，效能槓槓的。
從開放性上來說，比thrift那私有的協議後期更好做效能優化，快取，集群，都更好做些。
當然，我也不是說thrift一無是處。畢竟 grpc出來的太晚了寫，用的人少，windows上環境部署麻煩。當然，這些都不會影響grpc的光明未來。
怎麼看待谷歌發布的Jsonnet？
眭文峰 看下kubeflow的原始碼，就知道某些場景下，一段業務流程，每個狀態變化產生乙個描述物件，每個狀態之間物件描述明明可以復用的，但目前很多語言都要為每個描述物件寫乙份定義，賊尷尬。需求變更時，又不得不每個物件定義挨個改過去。更尷尬的是，很多時候，哪些物件定義要跟著改根本搞不清。Jsonnet...
怎麼看待 NET開源和VS支援Android iOS開發？
shavy 昨天看到個新聞說vs2013社群版 免費哦 能一攬子通殺iOS Android跟WP了，正好有打算做個手機遊戲，興沖沖地部署了一天重灌系統安裝vs安裝xamarin，好了，建立Android跟iOS專案。尼瑪此外掛程式原來要錢的，上xamarin官網瞅瞅。尼瑪能在vs上開發的busine...
你怎麼看待谷歌2019 年 10 月 15 日的新品發布會？
嵐欽欽 谷歌發布的新品手機是Pixel 4系列手機，包括Pixel 4以及Pixel 4 XL兩個型號。精確到具體的時間，谷歌新品發布會為10月15日。谷歌Pixel 4 XL手機搭載高通驍龍855處理器，螢幕尺寸為6.23英吋，預計螢幕解析度為3040 1440，同時螢幕的重新整理率也達到了90H...