引言

最近一段時間不論網際網路還是傳統行業，凡是涉及資訊科技範疇的圈子幾乎都在討論微服務框架。近期也看到各大技術社群開始組織一些沙龍和論壇來分享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和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而SpringCloud下面有17個子專案（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring CloudNetflix中的一個子集。但是在選擇框架上，方案完整度恰恰是一個需要重點關注的內容。

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

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的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的瞭解。