1樓：fleuria
跟之前了解 HTTP2.0 的個人印象有點接近，感覺這個協議把太多 tcp/ip 的複雜性提到了使用者層，而面向廣域網流動網路優化而引入的很多複雜性，在內網高頻寬/低延時總之資源充裕的網路環境中不那麼顯著。然而抽象洩露不可避免，開發者要負擔更多的複雜性。
反觀 RPC 走 HTTP1.1 協議的話，使用 haproxy/nginx 等負載均衡器已經可以卡乙個很高的效能上限了。勝在簡單穩定，周邊工具多，行為好預期（比如負載均衡、graceful restart、故障節點摘除，短連線方案都會比長連線方案簡單一點）。
不過很不建議自己輪 RPC 框架，業務發展招起人的時候，多語言互動會比想象中來的早，對自研 RPC 框架做各種多語言支援，價效比太低了。除非特殊原因，還是不如選用 grpc/dubbo/thrift 這類成熟框架，在公司內部做點服務化架構適配、監控埋點之類的定製擴充套件工作，後期做起客服來不那麼累。
2樓：neal ho
看了下，一共四點。
1. 用了rpc還要走lb，說明服務治理的能力不足啊。正確做法不是應該加強服務治理，使每個請求都能點到點直連麼。
這樣容易畫出每個請求的呼叫拓撲，又節省資源，少了lb這一跳，一進一出兩層頻寬的消耗。何況有時lb不止一跳。我們之前走lvs+nginx+nginx+realserver，改成e2e快了很多，又少了集中化的lb(proxy)，而且現在又流行service mesh，不正是發揚光大e2e麼。
2. 看個人偏好吧，擁抱變化。
3. 有bug就修唄，grpc的社群又不是一潭死水。設計複雜又不是藉口，設計複雜是為了功能多。
就好比人家送你乙個坦克，你說太複雜，沒我駁殼槍簡單……。除非設計有問題，效能有問題，否則設計複雜度不是任何問題，人家又不影響你效能什麼的。
4.grpc又不是不支援pingpong模式，人家又支援乙個stream模式反而被說成缺點了……。但是grpc沒有像thrift一樣把邏輯上的每一層變成可插拔的，確實有點不好，就像他說的json相關問題。
但是grpc的g是green啊。
如何評價谷歌開源的 Mesh TensorFlow？
靈魂機器 Mesh Tensorflow的靈感來自於目前廣泛使用的資料並行 data parallelism data parallelism可以看做是把tensors和operations 在 batch這個維度上進行分割。Mesh Tensorflow則順勢把這個點子推廣到所有維度。Mesh T...
如何評價阿里開源的ApsaraCache？
MemCache 和 Redis協議是啟動時切換的。本來以為是能同時乙個key支援以兩種協議訪問。如果是二選一就對大部分人沒什麼意義。為了其他的優勢和特點也沒明顯必要去選用，還是redis主流最穩妥。具體來說，ApsaraCache還具備多方面的技術特點和優勢，一是災備深度加固，可以重構核心同步機制...
如何評價谷歌開源的 TensorFlow 簡化庫 JAX？
如果沒有tensorflow或者pytorch，JAX絕對是對這個問題的最好抽象和實現 可惜有了tensorflow和pytorch之後，JAX抽象出來的設計和解決的問題成了極少數的1 的先鋒設計者們真正關心的問題，而99 的人只關心 如何用乙個full stack框架快速搭建起來乙個distrib...