Dubbo,SpringCloud,EJB對比

引言

最近一段時間不論互聯網仍是傳統行業，凡是涉及信息技術範疇的圈子幾乎都在討論微服務框架。近期也看到各大技術社區開始組織一些沙龍和論壇來分享spring cloud的相關實施經驗。

目前，Spring Cloud在國內的知名度不高。其實以前國內比較流行的是阿里巴巴的服務治理框架Dubbo有必定的關係，出了Dubbo自己有本身較爲完善的中文文檔，短時間內是Dubbo的天下。咱們項目中用到的EJB框架作爲SOA服務核心，EJB做爲J2EE的113個規範之一，實在是有本身不能夠或缺的地位。如今咱們就來比較一下那個基礎框架更好一些。

背景：

Dubbo是阿里巴巴服務治理的核心框架，並被普遍應用於阿里巴巴集團的各成員站點。阿里巴巴近幾年對開源社區的貢獻不論在國內仍是國外都是引人注目的，好比：JStorm捐贈給Apache並加入Apache基金會等，爲中國互聯網人爭足了面子，使得阿里巴巴在國人眼裏已經從電商升級爲一家科技公司了。

Spring Cloud，從命名咱們就能夠知道，它是Spring Source的產物，Spring社區的強大背書能夠說是Java企業界最有影響力的組織了，除了SpringSource以外，還有Pivotal和Netfix是其強大的後盾與技術輸出。其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。

EJB是是爲"服務集羣"和"企業級開發"而生，其龐大且唬人的背景，我就不闡述了，EJB實現原理： 就是把原來放到客戶端實現的代碼放到服務器端，並依靠RMI進行通訊。RMI實現原理 ：就是經過Java對象可序列化機制實現分佈計算。服務器集羣： 就是經過RMI的通訊，鏈接不一樣功能模塊的服務器，以實現一個完整的功能。

社區活躍度：

咱們選擇一個開源框架，社區的活躍度是咱們極爲關注的一個要點。社區越活躍，解決問題的速度越快，框架也會愈來愈完善，否則當咱們碰到問題，就不得不本身解決。而對於團隊來講，也就意味着咱們不得不本身去維護框架的源碼，這對於團隊來講也將會是一個很大的負擔。

小結：在社區活躍度上，Spring Cloud毋庸置疑的優於Dubbo，Dubbo優於EJB，這對於沒有大量精力與財力維護這部分開源內容的團隊來講，SpringCloud會是更優的選擇。

架構完整性：

在SpringCloud和Dubbo以及EJB的比較中，用張圖來比較一下：

 

	EJB	Dubbo	SpringCloud
開發方	標準由Oracle開發	阿里	Spring社區
最新版本及時間	3.1，2009年	2.5.3，2012年10月23號	Camden.SR3，2016年11月29號
維護狀態	不活躍，3.2只是草案	再也不繼續維護	活躍
互聯網應用案例	暫未發現	阿里、京東、噹噹等	中國聯通子公司 上海米麼金服 指點無限（北京）科技有限公司 易保軟件 目前在定製開發中 廣州簡法網絡 深圳睿雲智合科技有限公司 豬八戒網，目前調研中 上海雲首科技有限公司 華爲 整合netty進來用rpc 包括nerflix那套東西 須要注意的是sleuth traceid的傳遞須要本身寫。tps在物理機上能突破20w 東軟 南京雲賬房網絡科技有限公司 四衆互聯(北京)網絡科技有限公司 深圳摩令技術科技有限公司 廣州萬表網 視覺中國 上海秦蒼信息科技有限公司-買單俠 愛油科技(大連)有限公司 愛油科技基於SpringCloud的微服務實踐
基於協議	Rmi	可選，默認dobbo	http
可用的語言	Java	Java	全部語言
分佈式事物	是	否	否
無狀態部署	否	是	是
服務器治理	服務發現、負載均衡	服務發現、服務路由、服務負載均衡、服務列表、服務分組、服務依賴管理、服務權重、服務受權、服務直連、上下文隱式傳參、分組聚合、結果緩存	除dubbo有的外：服務網關、斷路器、服務跟蹤、消息總線、批量任務
分佈式配置	無	第三方	有
基於的web容器	Jboss	Tomcat內嵌	Tomcat內嵌
單元測試	支持	支持	支持
性能對比

 

 

咱們通常使用EJB，徹底是很看好它的分佈式的遠程調用，可是在這個網絡發展面向大數據的時代，光能實現遠程調用是遠遠不夠的，好比說服務跟蹤、服務治理、批量任務等等。

Dubbo自身只是實現了服務治理的基礎，其餘爲保證集羣安全、可維護、可測試等特性方面都沒有很好的實現，可是幾乎大部分關鍵組件都能找到第三方開源來實現，這些組件主要來自於國內各家大型互聯網企業的開源產品。

 

或許不少人會說SpringCloud和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而SpringCloud下面有17個子項目（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，必定程度來講，Dubbo只是Spring CloudNetflix中的一個子集。可是在選擇框架上，方案完整度偏偏是一個須要重點關注的內容。

根據MartinFowler對 微服務架構 的描述中，雖然該架構相較於單體架構有模塊化解耦、可獨立部署、技術多樣性等諸多優勢，可是因爲分佈式環境下解耦，也帶出了很多測試與運維複雜度。

根據微服務架構在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

 

	Dubbo	Spring Cloud
服務註冊中心	Zookeeper	Spring Cloud Netflix Eureka
服務調用方式	RPC	REST API
服務網關	無	Spring Cloud Netflix Zuul
斷路器	不完善	Spring Cloud Netflix Hystrix
分佈式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
消息總線	無	Spring Cloud Bus
數據流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task
……	……	……

 

 

Dubbo對於上表中總結爲「無」的組件不表明不能實現，而只是Dubbo框架自身不提供，須要另外整合以實現對應的功能，好比：
分佈式配置：可使用淘寶的diamond、百度的disconf來實現分佈式配置管理。可是Spring Cloud中的Config組件除了提供配置管理以外，因爲其存儲可使用Git，所以它自然的實現了配置內容的版本管理，能夠完美的與應用版本管理整合起來。

服務跟蹤：可使用京東開源的Hydra

批量任務：可使用噹噹開源的Elastic-Job
…… 

RMI vs RPC vs REST

RMI對於服務間調用：性能是幾種裏面快的，EJB性能沒得說，相比於RPC和REST。可是RMI在服務中也是有接口依賴方式比較強，下面會介紹，所以RMI和RPC在通訊靈活方面是沒有REST更加靈活地。可是性能是是RMI>RPC>REST的。

Dubbo使用的RPC：服務提供方與調用方接口依賴方式太強：咱們爲每一個微服務定義了各自的service抽象接口，並經過持續集成發佈到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關係，所以不論開發、測試、集成環境都須要嚴格的管理版本依賴，纔不會出現服務方與調用方的不一致致使應用沒法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，每每一個依賴不少服務的上層應用，天天都要更新不少代碼並install以後才能進行後續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關係會成爲開發團隊的一大噩夢。而REST接口相比RPC更爲輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，固然REST接口也有痛點，由於接口定義太輕，很容易致使定義文檔與實際實現不一致致使服務集成時的問題，可是該問題很好解決，只須要經過每一個服務整合swagger，讓每一個服務的代碼與文檔一體化，就能解決。因此在分佈式環境下，REST方式的服務依賴要比RPC方式的依賴更爲靈活。

小結：

Dubbo實現了服務治理的基礎，可是要完成一個完備的微服務架構，還須要在各環節去擴展和完善以保證集羣的健康，以減輕開發、測試以及運維各個環節上增長出來的壓力，這樣才能讓各環節人員真正的專一於業務邏輯。而SpringCloud依然發揚了Spring Source整合一切的做風，以標準化的姿態將一些微服務架構的成熟產品與框架揉爲一體，並繼承了SpringBoot簡單配置、快速開發、輕鬆部署的特色，讓本來複雜的架構工做變得相對容易上手一些（若是您讀過我以前關於Spring Cloud的一些核心組件使用的文章，應該能體會這些讓人興奮而激動的特性，傳送門）。因此，若是選擇Dubbo請務必在各個環節作好整套解決方案的準備，否則極可能隨着服務數量的增加，整個團隊都將疲於應付各類架構上不足引發的困難。而若是選擇SpringCloud，相對來講每一個環節都已經有了對應的組件支持，可能有些也不必定能知足你全部的需求，可是其活躍的社區與高速的迭代進度也會是你能夠依靠的強大後盾。

文檔質量：

EJB做爲一種規範，EJB容器出了服務治理方面上的完整架構，可是仍是服務治理方面是它的硬傷呀。

 

Dubbo的 文檔 能夠說在國內開源框架中算是一流的，很是全，而且講解的也很是深刻，因爲版本已經穩定再也不更新，因此也不太會出現不一致的狀況，另外提供了中文與英文兩種版本，對於國內開發者來講，閱讀起來更加容易上手，這也是dubbo在國內更火一些的緣由吧。

SpringCloud因爲整合了大量組件，文檔在體量上天然要比dubbo多不少，文檔內容上還算簡潔清楚，可是更多的是偏向整合，更深刻的使用方法仍是須要查看其整合組件的詳細文檔。另外因爲SpringCloud基於SpringBoot，不少例子相較於傳統Spring應用要簡單不少（由於自動化配置，不少內容都成了約定的默認配置），這對於剛接觸的開發者可能會有些不適應，比較建議瞭解和學習SpringBoot以後再使用Spring Cloud，否則可能會出現不少只知其一;不知其二的狀況。

小結：雖然SpringCloud的文檔量大，可是若是使用Dubbo去整合其餘第三方組件，實際也是要去閱讀大量第三方組件文檔的，因此在文檔量上，我以爲區別不大。對於文檔質量，因爲SpringCloud的迭代很快，不免會出現不一致的狀況，因此在質量上我認爲Dubbo更好一些。而對於文檔語言上，Dubbo天然對國內開發團隊來講更有優點。

總結

 

經過上面再幾個環節上的分析，相信你們對EJB、Dubbo和SpringCloud有了一個初步的瞭解。就我我的對這兩個框架的使用經驗和理解，打個不恰當的比喻：使用EJB、Dubbo構建的微服務架構就像組裝電腦，各環節咱們的選擇自由度很高，可是最終結果頗有可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；而SpringCloud就像品牌機，在Spring Source的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要在使用非原裝組件外的東西，就須要對其基礎有足夠的瞭解。