微服務框架Dubbo與Springcloud的區別
微服務框架Dubbo與Springcloud的區別
微服務主要的優勢如下：
1、降低複雜度
將原來偶合在一起的複雜業務拆分為單個服務，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的介面清晰表述服務邊界。
每個服務開發者只專注服務本身，通過使用快取、DAL等各種技術手段來提升系統的效能，而對於消費方來說完全透明。
2、可獨立部署
由於微服務具備獨立的執行程序，所以每個微服務可以獨立部署。當業務迭代時只需要釋出相關服務的迭代即可，降低了測試的工作量同時也降低了服務釋出的風險。
3、容錯
在微服務架構下，當某一元件發生故障時，故障會被隔離在單個服務中。 通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常執行。
4、擴充套件
單塊架構應用也可以實現橫向擴充套件，就是將整個應用完整的複製到不同的節點。當應用的不同元件在擴充套件需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴充套件。
Dubbo
Dubbo是阿里巴巴公司開源的一個高效能優秀的服務框架，使得應用可通過高效能的 RPC 實現服務的輸出和輸入功能，可以和Spring
Dubbo 核心部件（如下圖）:
Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務
Consumer：呼叫遠端服務的服務消費方。
Registry： 服務註冊中心和發現中心。
Monitor： 統計服務和呼叫次數，呼叫時間監控中心。（dubbo的控制檯頁面中可以顯示，目前只有一個簡單版本）
Container：服務執行的容器。
Springcloud
Spring Cloud是一系列框架的有序集合，是構建分散式系統的工具集。開發者全家桶，把業界主流最好技術整合起來集中利用這些方便工具構建業務系統。
Spring Cloud總體架構如下圖
Service Provider： 暴露服務的提供方。
Service Consumer：呼叫遠端服務的服務消費方。
EureKa Server： 服務註冊中心和服務發現中心。
兩者的區別
最大的區別:Spring Cloud拋棄了Dubbo 的RPC通訊，採用的是基於HTTP的REST方式。
效能比較
使用一個Pojo物件包含10個屬性，請求10萬次，Dubbo和Spring Cloud在不同的執行緒數量下，每次請求耗時（ms）如下：
來源（背景）：
Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於阿里巴巴集團的各成員站點。
Spring Cloud，從命名我們就可以知道，它是Spring Source的產物，Spring社群的強大背書可以說是Java企業界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強大的後盾與技術輸出。
其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。
傳輸：
Dubbo由於是二進位制的傳輸，佔用頻寬會更少；
Spring Cloud是http協議傳輸，頻寬會比較多，同時使用http協議一般會使用JSON報文，消耗會更大。但是在國內95%的公司內，網路消耗不是什麼太大問題，
如果真的成了問題，通過壓縮、二進位制、快取記憶體、分段降級等方法，很容易解。
開發難度：
Dubbo的開發難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決；
Spring Cloud的介面協議約定比較自由且鬆散，需要有強有力的行政措施來限制介面無序升級
後續改進：
Dubbo通過dubbofilter，很多東西沒有，需要自己繼承，如監控，如日誌，如限流，如追蹤
Spring Cloud自己帶了很多監控、限流措施，但是功能可能和歐美習慣相同，國內需要進行適當改造，但更簡單，就是ServletFilter而已，但是總歸比dubbo多一些東西是好的；
註冊中心：
Dubbo的註冊中心可以選擇zk,redis等多種；
Spring Cloud:的註冊中心只能用eureka或者自研；
配置中心：
dubbo：如果我們使用配置中心、分散式跟蹤這些內容都需要自己去整合，無形中增加了使用難度。
Spring Cloud：提供了微服務的一整套解決方案：服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等