引言
最近一段時間不論互聯網還是傳統行業,凡是涉及信息技術範疇的圈子幾乎都在討論微服務框架。近期也看到各大技術社區開始組織一些沙龍和論壇來分享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的整合下,做了大量的兼容性測試,保證了機器擁有更高的穩定性,但是如果要在使用非原裝組件外的東西,就需要對其基礎有足夠的瞭解。