Dubbox和Dubbo哪個好?其實Dubbox和Dubbo都是很好的服務框架，簡單來說，Dubbox和Dubbo本質上沒有區(qū)別，Dubbox是Dubbo的升級版本。這樣說來，好像Dubbox更好一些，為什么?畢竟它是升級的版本，擴展了Dubbo沒有的內容。現在，動力節(jié)點java學院小編詳細分析一下它們兩者的區(qū)別？

　　1、簡介

　　Dubbo源于阿里的淘寶網開源的分布式的服務架構，致力于提供高性能和透明化的RPC遠程服務調用方案，是SOA服務化治理方案的核心框架。淘寶網將其開源之后，得到了很多的拓展和支持(比較出名的有：當當網的擴展版本dubbox，京東的擴展版本jd-hydra等)

　　Dubbox是一個開源的RPC(Remote ProcedureCall Protocol)遠程調用框架，是由dangdang對阿里的Dubbo的升級，可以被視為Dubbo的增強版，基本架構沒有變動，升級spring2.x到spring3.x,支持restful風格的調用調試方式，豐富了序列化的方式，提高了序列化的性能。Dubbox(即Dubbo eXtensions)是當當網Fork基于dubbo2.x的升級版本，兼容原有的dubbox。其中升級了zookeeper和spring版本，并且支持restfull風格的遠程調用。

　　2、現狀

　　Dubbo源于阿里的淘寶網開源的分布式的服務架構，據說淘寶網dubbo與一個非開源的框架HSF有爭執(zhí)，導致dubbo的團隊已經解散了。Dubbo目前已停止更新。

　　Dubbox(即Dubbo eXtensions)是當當網Fork基于dubbo2.x的升級版本，兼容原有的dubbox。其中升級了zookeeper和spring版本，并且支持restfull風格的遠程調用。Dubbox得到不斷的發(fā)展(升級更新)，目前還在更新。

　　3、服務框架對比

　　Dubbox名字的含義擴展了Dubb，以下為擴展出來的功能，這也是選擇Dubbox很重要的考察點。

　　支持REST風格遠程調用(HTTP + JSON/XML);

　　支持基于Kryo和FST的Java高效序列化實現;

　　支持基于Jackson的JSON序列化;

　　支持基于嵌入式Tomcat的HTTP remoting體系;

　　升級Spring至3.x;

　　升級ZooKeeper客戶端;

　　支持完全基于Java代碼的Dubbo配置。

　　4、RPC vs REST

　　服務提供方與調用方接口依賴方式太強：我們?yōu)槊總€微服務定義了各自的service抽象接口，并通過持續(xù)集成發(fā)布到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，因此不論開發(fā)、測試、集成環(huán)境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一致導致應用無法編譯成功等一系列問題，以及這也會直接影響本地開發(fā)的環(huán)境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼并install之后才能進行后續(xù)的開發(fā)。若沒有嚴格的版本管理制度或開發(fā)一些自動化工具，這樣的依賴關系會成為開發(fā)團隊的一大噩夢。而REST接口相比RPC更為輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，當然REST接口也有痛點，因為接口定義過輕，很容易導致定義文檔與實際實現不一致導致服務集成時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。所以在分布式環(huán)境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。

　　服務對平臺敏感，難以簡單復用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平臺的特點，任何一個語言的調用方都可以根據接口定義來實現。那么在Dubbo中我們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發(fā)布。若我們每個服務本身就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關系和權限控制就可實現服務的復用了。

　　Dubbo實現了服務治理的基礎，但是要完成一個完備的微服務架構，還需要在各環(huán)節(jié)去擴展和完善以保證集群的健康，以減輕開發(fā)、測試以及運維各個環(huán)節(jié)上增加出來的壓力，這樣才能讓各環(huán)節(jié)人員真正的專注于業(yè)務邏輯。而Spring Cloud依然發(fā)揚了Spring Source整合一切的作風，以標準化的姿態(tài)將一些微服務架構的成熟產品與框架揉為一體，并繼承了Spring Boot簡單配置、快速開發(fā)、輕松部署的特點，讓原本復雜的架構工作變得相對容易上手一些。所以，如果選擇Dubbo請務必在各個環(huán)節(jié)做好整套解決方案的準備，不然很可能隨著服務數量的增長，整個團隊都將疲于應付各種架構上不足引起的困難。而如果選擇Spring Cloud，相對來說每個環(huán)節(jié)都已經有了對應的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區(qū)與高速的迭代進度也會是你可以依靠的強大后盾。

　　Dubbox： 相對于Dubbo支持了REST，估計是很多公司選擇Dubbox的一個重要原因之一，但如果使用Dubbo的RPC調用方式，服務間仍然會存在API強依賴，各有利弊，懂的取舍吧。

以上就是動力節(jié)點java學院小編分享的“ Dubbox和Dubbo哪個好？為什么？”的相關內容，希望對各位有幫助，有任何問題可以隨時在線咨詢，有專業(yè)老師為你服務。