通過對比 Dubbo和Spring Cloud ,綜合選擇最合適的

前言:

        目前學習了下Dubbo 和  Spring Cloud,並且在簡單學習後,總結了下這兩者之間簡單的區別;如果以後有需要搭建分佈式系統的需求,可以根據這兩者之間的區別,再根據當前公司的業務等情況選擇最爲合適的來搭建自己的分佈式系統。

 

Dubbo+Zookeeper   vs   Spring Cloud:

框架比較的方面 Dubbo+zookeeper Spring Cloud
性能方面       Dubbo是阿里巴巴開源的頂級項目,以前是用於阿里巴巴的分佈式服務治理框架,其性能毋庸置疑一定是很強的,它適合一些比較大的公司用的分佈式服務治理框架。(注:2017年之前阿里巴巴沒有對其進行更新維護,但是2017年Dubbo項目官網宣佈重新對其進行更新維護,並且在2018年Dubbo項目正式進入了Apache孵化器        Spring Cloud是最近才興起的一個分佈式服務框架,現在它的社區十分的火爆,代碼的更新迭代十分的快;它一般適合於中小型企業,並且性能比Dubbo低一些;
具有的特點

      Dubbo有良好的連通性、健壯性、伸縮性、升級性。結合Dubbo可以相對於單體系統提升系統整體的擴展性。

      Dubbo提供了多種協議給用戶選擇, 如dubbo、hessian、rmi 。 並可爲每個服務指定不同的傳輸協議,粒度可以細化到方法, 不同服務在性能上適用不同協議進行傳輸,比如大數據用短連接協議,小數據大併發用長連接協議。

       Spring Cloud來源於Spring,質量、穩定性、持續性都可以得到保證

       Spirng Cloud天然支持Spring Boot,更加便於業務落地。

        Spring Cloud是Java領域最適合做微服務的框架。

         相比於其它框架,Spring Cloud對微服務周邊環境的支持力度最大。

     框架結構

(自身支持的組件)

 

 

Dubbo

    SpringCloud

服務註冊中心

Zookeeper

SpringCloud  Netflix  Eureka

服務調用方式

RPC

REST API

服務網關

SpringCloudNetflix Zuul

斷路器

不完善

SpringCloud Netflix Hystrix

分佈式配置

SpringCloud Config

服務跟蹤

SpringCloud Sleuth

消息總線

SpringCloud Bus

.........

........

.............

注:(dubbo本身自帶的組件不夠支持搭建分佈式系統的架構,但是其可以集成第三方的開源項目,從而完善分佈式系統的架構。)

方便性

        Dubbo使用起來不太方便,由於許多組件其本身不支持,所以我們在搭建架構環境時,需要集成一些其他的開源組件,集成時會遇到種種的困難,並且在以後的項目維護和升級也不方便。

 

        Dubbo服務調用的方式是RPC,服務提供方與調用方接口依賴方式太強:我們需要將調用的抽象接口依賴到消費者項目中才能調用服務,這會導致在以後的開發、測試、版本管理上很麻煩。

       SpringCloud自身的組件可以搭建成一個完整的微服務架構,並且搭建起來稍微簡單一些;

       SpringCloud調用的方式是REST,REST接口相比RPC更爲輕量化,服務提供方和調用方的依賴只是依靠一紙契約,不存在代碼級別的強依賴,當然REST接口也有缺點,很容易導致定義文檔與實際實現不一致導致服務集成時的問題。

靈活性         由於dubbo許多組件都是集成的第三方,所以dubbo組件之間的自由度很高,dubbo更加的靈活。         SpringCloud自身支持了組件,各個組件之間的關聯關係已經配置好了,所以它的靈活度不是很好,如果想要用第三方組件代替其中的一個組件的話會有一些困難。
服務註冊中心

        Zookeeper保證C(一致性)P(分區容錯性)

        當master節點因爲網絡故障與其他節點失去聯繫時,剩餘節點會重新進行leader選舉。問題在於,選舉leader的時間太長,30 ~ 120s, 且選舉期間整個zk集羣都是不可用的,這就導致在選舉期間註冊服務癱瘓。

        Eureka保證A(可用性)P(分區容錯性)

        Eureka各個節點都是平等的,幾個節點掛掉不會影響正常工作。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗,則會自動切換至其它節點,只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查到的信息可能不是最新的(不保證強一致性)

代碼開發角度         Dubbo常與Spring、zookeeper結合,而且實現只是通過xml來配置服務地址、名稱、端口,代碼的侵入性是很小的,可以說幾乎沒有代碼入侵。 Spring Cloud,由於它的實現需要類註解等,所以多少具有一定代碼侵入。

總結:

        總的來說這兩個搭建分佈式系統的框架各有各的好處,在選擇時要根據自己的需求等情況綜合做選擇;

        但是Eureka作爲單純的服務註冊中心來說感覺要比Zookeeper更加“專業”,因爲註冊服務更重要的是高可用性,可以接受短期內達不到一致性的狀況。

 

不要忘記留下你學習的足跡 [點贊 + 收藏 + 評論]嘿嘿ヾ

一切看文章不點贊都是“耍流氓”,嘿嘿ヾ(◍°∇°◍)ノ゙!開個玩笑,動一動你的小手,點贊就完事了,你每個人出一份力量(點贊 + 評論)就會讓更多的學習者加入進來!非常感謝! ̄ω ̄=

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章