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

　　1、簡介

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

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

　　2、現(xiàn)狀

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

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

　　3、服務(wù)框架對比

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

　　支持REST風(fēng)格遠程調(diào)用(HTTP + JSON/XML);

　　支持基于Kryo和FST的Java高效序列化實現(xiàn);

　　支持基于Jackson的JSON序列化;

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

　　升級Spring至3.x;

　　升級ZooKeeper客戶端;

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

　　4、RPC vs REST

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

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

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

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

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