介紹
SpringCloud與grpc
首先，對 dubbo 不是很瞭解，因此只說一下我對於 SpringCloud 和 grpc 的瞭解，若是有什麼地方說得不對，請指正。
在 SpringCloud 中，服務間的調用是經過 http 通訊的，其實就至關於在調用 RESTFul 接口。而 grpc 服務間的調用是基於 http2 以及 protobuff 協議的一種通訊機制，他要求在調用前須要先定義好接口契約，並使用工具生成代碼，而後在代碼中調用這些生成的類進行服務調用。二者之間，我的認爲 grpc 會有比較多的限制。
第二個問題，分佈式和單體結構的通訊區別，我的認爲可能就是多了一個負載均衡的差別吧。原生與接口的通訊、H5 與接口的通訊，我的認爲二者不該該有區別，接口只須要暴露出一種通訊方式，這樣才能節省開發成本。java
gRPC
https://github.com/grpc/grpc-java
由谷歌開發的一個高性能開源RPC框架，基於HTTp/2協議標準開發。利用ProtoBuf做爲序列化工具和接口定義語言。git
Dubbo
Dubbo遠程接口調用，負載均衡和容錯，自動服務註冊和發現。github
RPC
HTTP 是通訊協議，RPC 是一種設計實現框架。
RPC 中使用的通訊協議大都是長鏈接，不須要每次通過 3 次握手。
RPC 中使用的通訊協議大都本身設計，沒有通用標準。
RPC 框架基本都圍繞通訊協議、傳輸協議、線程模型展開。
分佈式不是 RPC 的必要特性。web
總結
對springcloud、grpc、dubbo 什麼區別？rpc和分佈式的關聯？根據網絡各自不一樣的發聲，總結以下spring
SpringCloud 中，服務間的調用是經過 http 通訊的，其實就至關於在調用 RESTFul 接口。
grpc 服務間的調用是基於 http2 以及 protobuff 協議的一種通訊機制，他要求在調用前須要先定義好接口契約，並使用工具生成代碼，而後在代碼中調用這些生成的類進行服務調用。springboot
RPC 中使用的通訊協議大都本身設計，沒有通用標準。
RPC 中使用的通訊協議大都是長鏈接，不須要每次通過 3 次握手。服務器
分佈式不是 RPC 的必要特性。網絡
概念：負載均衡
Dubbo RPC：基於TCP或HTTP的遠程過程調用（就像在本地調用同樣），RPC強調的是遠程調用。框架
spring cloud：基於springboot，而springboot是基於HTTP協議REST風格的RPC。
對比：
一、協議：服務間通訊協議不一樣，Dubbo是基於TCP協議的rpc，spring cloud基於http協議。
二、RPC避免了上面提到的原生RPC帶來的問題。並且REST相比RPC更爲靈活，SpringCloud不存在代碼級別的強依賴
三、效率：因爲協議的不一樣，調用的效率相比之下Dubbo比SpringCLoud效率高。
四、技術開放性：SpringCLoud基於http協議，因爲http的協議更方便於多語言狀況下的整合，提供服務方能夠用任意語言開發服務。
五、spring cloud是微服務生態，包括完整的微服務相關的組件工具集，而RPC是遠程調用的技術，僅僅是微服務的一部分，而dubbo框架正是RPC的實現框架。
六、Spring Cloud還提供了包括Netflix Eureka、hystrix、feign、Spring Boot Admin 、Sleuth、config、stream、security、sleuth等分佈式服務解決方案，
而Dubbo爲了擁抱融入Spring Cloud生態，Dubbo也在積極規劃和演進適配SpringCloud生態的新版本。
優缺點
grpc限制多，但http2相對http有二進制、長鏈接、服務器主動發消息等優點。
歷史溯源
rpc先於http出現
（但當時是http初代有不少問題，如今http2我的以爲grpc仍是有可取的優點）
性能
grpc一開始(2016年前)的性能貌似是dubbo的2/3左右
可是2017年的一篇博客看出grpc已經開始超越dubbo
本文同步分享在 博客「瑞 新」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。