最近一段時(shí)間不論互聯(lián)網(wǎng)還是傳統(tǒng)行業(yè)，凡是涉及信息技術(shù)范疇的圈子幾乎都在討論微服務(wù)架構(gòu)。近期也看到各大技術(shù)社區(qū)開(kāi)始組織一些沙龍和論壇來(lái)分享Spring Cloud的相關(guān)實(shí)施經(jīng)驗(yàn)，這對(duì)于最近正在整理Spring Cloud相關(guān)套件內(nèi)容與實(shí)例應(yīng)用的我而言，還是有不少激勵(lì)的。

目前，Spring Cloud在國(guó)內(nèi)的知名度并不高，在前陣子的求職過(guò)程中，與一些互聯(lián)網(wǎng)公司的架構(gòu)師、技術(shù)VP或者CTO在交流時(shí)，有些甚至還不知道該項(xiàng)目的存在?？赡苓@也與國(guó)內(nèi)阿里巴巴開(kāi)源服務(wù)治理框架Dubbo有一定的關(guān)系，除了Dubbo本身較為完善的中文文檔之外，不少科技公司的架構(gòu)師均出自阿里系，所以就目前情況看，短期國(guó)內(nèi)還是Dubbo的天下。

那么第一次實(shí)施微服務(wù)架構(gòu)時(shí)，我們應(yīng)該選擇哪個(gè)基礎(chǔ)框架更好呢？

以下內(nèi)容均為作者個(gè)人觀點(diǎn)，知識(shí)面有限，如有不對(duì)，純屬正常，不喜勿噴。

Round 1：背景

Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點(diǎn)。阿里巴巴近幾年對(duì)開(kāi)源社區(qū)的貢獻(xiàn)不論在國(guó)內(nèi)還是國(guó)外都是引人注目的，比如：JStorm捐贈(zèng)給Apache并加入Apache基金會(huì)等，為中國(guó)互聯(lián)網(wǎng)人爭(zhēng)足了面子，使得阿里巴巴在國(guó)人眼里已經(jīng)從電商升級(jí)為一家科技公司了。

Spring Cloud，從命名我們就可以知道，它是Spring Source的產(chǎn)物，Spring社區(qū)的強(qiáng)大背書(shū)可以說(shuō)是Java企業(yè)界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強(qiáng)大的后盾與技術(shù)輸出。其中Netflix開(kāi)源的整套微服務(wù)架構(gòu)套件是Spring Cloud的核心。

小結(jié)：如果拿Dubbo與Netflix套件做對(duì)比，前者在國(guó)內(nèi)影響力較大，后者在國(guó)外影響力較大，我認(rèn)為在背景上可以打個(gè)平手；但是若要與Spring Cloud做對(duì)比，由于Spring Source的加入，在背書(shū)上，Spring Cloud略勝一籌。不過(guò)，英雄不問(wèn)出處，在背景這一點(diǎn)上，不能作為選擇框架的主要因素，當(dāng)您一籌莫展的時(shí)候，可以作為參考依據(jù)。

Round 2：社區(qū)活躍度

我們選擇一個(gè)開(kāi)源框架，社區(qū)的活躍度是我們極為關(guān)注的一個(gè)要點(diǎn)。社區(qū)越活躍，解決問(wèn)題的速度越快，框架也會(huì)越來(lái)越完善，不然當(dāng)我們碰到問(wèn)題，就不得不自己解決。而對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，也就意味著我們不得不自己去維護(hù)框架的源碼，這對(duì)于團(tuán)隊(duì)來(lái)說(shuō)也將會(huì)是一個(gè)很大的負(fù)擔(dān)。

下面看看這兩個(gè)項(xiàng)目在github上的更新時(shí)間，下面截圖自2016年7月30日：

• Dubbo ：https://github.com/dubbo

最后更新時(shí)間為：2016年5月6日

• Spring Cloud ：https://github.com/spring-cloud

最后更新時(shí)間為：12分鐘前

可以看到Dubbo的更新已經(jīng)是幾個(gè)月前，并且更新頻率很低。而Spring Cloud的更新是12分鐘前，仍處于高速迭代的階段。

小結(jié)：在社區(qū)活躍度上，Spring Cloud毋庸置疑的優(yōu)于Dubbo，這對(duì)于沒(méi)有大量精力與財(cái)力維護(hù)這部分開(kāi)源內(nèi)容的團(tuán)隊(duì)來(lái)說(shuō)，Spring Cloud會(huì)是更優(yōu)的選擇。

Round 3：架構(gòu)完整度

或許很多人會(huì)說(shuō)Spring Cloud和Dubbo的對(duì)比有點(diǎn)不公平，Dubbo只是實(shí)現(xiàn)了服務(wù)治理，而Spring Cloud下面有17個(gè)子項(xiàng)目（可能還會(huì)新增）分別覆蓋了微服務(wù)架構(gòu)下的方方面面，服務(wù)治理只是其中的一個(gè)方面，一定程度來(lái)說(shuō)，Dubbo只是Spring Cloud Netflix中的一個(gè)子集。但是在選擇框架上，方案完整度恰恰是一個(gè)需要重點(diǎn)關(guān)注的內(nèi)容。

根據(jù)Martin Fowler對(duì)微服務(wù)架構(gòu)的描述中，雖然該架構(gòu)相較于單體架構(gòu)有模塊化解耦、可獨(dú)立部署、技術(shù)多樣性等諸多優(yōu)點(diǎn)，但是由于分布式環(huán)境下解耦，也帶出了不少測(cè)試與運(yùn)維復(fù)雜度。

根據(jù)微服務(wù)架構(gòu)在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

以上列舉了一些核心部件，大致可以理解為什么之前說(shuō)Dubbo只是類(lèi)似Netflix的一個(gè)子集了吧。當(dāng)然這里需要申明一點(diǎn)，Dubbo對(duì)于上表中總結(jié)為“無(wú)”的組件不代表不能實(shí)現(xiàn)，而只是Dubbo框架自身不提供，需要另外整合以實(shí)現(xiàn)對(duì)應(yīng)的功能，比如：

• 分布式配置：可以使用淘寶的diamond、百度的disconf來(lái)實(shí)現(xiàn)分布式配置管理。但是Spring Cloud中的Config組件除了提供配置管理之外，由于其存儲(chǔ)可以使用git，因此它天然的實(shí)現(xiàn)了配置內(nèi)容的版本管理，可以完美的與應(yīng)用版本管理整合起來(lái)。
• 服務(wù)跟蹤：可以使用京東開(kāi)源的Hydra
• 批量任務(wù)：可以使用當(dāng)當(dāng)開(kāi)源的Elastic-Job
• ……

雖然，Dubbo自身只是實(shí)現(xiàn)了服務(wù)治理的基礎(chǔ)，其他為保證集群安全、可維護(hù)、可測(cè)試等特性方面都沒(méi)有很好的實(shí)現(xiàn)，但是幾乎大部分關(guān)鍵組件都能找到第三方開(kāi)源來(lái)實(shí)現(xiàn)，這些組件主要來(lái)自于國(guó)內(nèi)各家大型互聯(lián)網(wǎng)企業(yè)的開(kāi)源產(chǎn)品。

RPC vs REST

另外，由于Dubbo是基礎(chǔ)框架，其實(shí)現(xiàn)的內(nèi)容對(duì)于我們實(shí)施微服務(wù)架構(gòu)是否合理，也需要我們根據(jù)自身需求去考慮是否要修改，比如Dubbo的服務(wù)調(diào)用是通過(guò)RPC實(shí)現(xiàn)的，但是如果仔細(xì)拜讀過(guò)Martin Fowler的microservices一文，其定義的服務(wù)間通信是HTTP協(xié)議的REST API。那么這兩種有何區(qū)別呢？

先來(lái)說(shuō)說(shuō)，使用Dubbo的RPC來(lái)實(shí)現(xiàn)服務(wù)間調(diào)用的一些痛點(diǎn)：

• 服務(wù)提供方與調(diào)用方接口依賴(lài)方式太強(qiáng)：我們?yōu)槊總€(gè)微服務(wù)定義了各自的service抽象接口，并通過(guò)持續(xù)集成發(fā)布到私有倉(cāng)庫(kù)中，調(diào)用方應(yīng)用對(duì)微服務(wù)提供的抽象接口存在強(qiáng)依賴(lài)關(guān)系，因此不論開(kāi)發(fā)、測(cè)試、集成環(huán)境都需要嚴(yán)格的管理版本依賴(lài)，才不會(huì)出現(xiàn)服務(wù)方與調(diào)用方的不一致導(dǎo)致應(yīng)用無(wú)法編譯成功等一系列問(wèn)題，以及這也會(huì)直接影響本地開(kāi)發(fā)的環(huán)境要求，往往一個(gè)依賴(lài)很多服務(wù)的上層應(yīng)用，每天都要更新很多代碼并install之后才能進(jìn)行后續(xù)的開(kāi)發(fā)。若沒(méi)有嚴(yán)格的版本管理制度或開(kāi)發(fā)一些自動(dòng)化工具，這樣的依賴(lài)關(guān)系會(huì)成為開(kāi)發(fā)團(tuán)隊(duì)的一大噩夢(mèng)。而REST接口相比RPC更為輕量化，服務(wù)提供方和調(diào)用方的依賴(lài)只是依靠一紙契約，不存在代碼級(jí)別的強(qiáng)依賴(lài)，當(dāng)然REST接口也有痛點(diǎn)，因?yàn)榻涌诙x過(guò)輕，很容易導(dǎo)致定義文檔與實(shí)際實(shí)現(xiàn)不一致導(dǎo)致服務(wù)集成時(shí)的問(wèn)題，但是該問(wèn)題很好解決，只需要通過(guò)每個(gè)服務(wù)整合swagger，讓每個(gè)服務(wù)的代碼與文檔一體化，就能解決。所以在分布式環(huán)境下，REST方式的服務(wù)依賴(lài)要比RPC方式的依賴(lài)更為靈活。
• 服務(wù)對(duì)平臺(tái)敏感，難以簡(jiǎn)單復(fù)用：通常我們?cè)谔峁?duì)外服務(wù)時(shí)，都會(huì)以REST的方式提供出去，這樣可以實(shí)現(xiàn)跨平臺(tái)的特點(diǎn)，任何一個(gè)語(yǔ)言的調(diào)用方都可以根據(jù)接口定義來(lái)實(shí)現(xiàn)。那么在Dubbo中我們要提供REST接口時(shí)，不得不實(shí)現(xiàn)一層代理，用來(lái)將RPC接口轉(zhuǎn)換成REST接口進(jìn)行對(duì)外發(fā)布。若我們每個(gè)服務(wù)本身就以REST接口方式存在，當(dāng)要對(duì)外提供服務(wù)時(shí)，主要在API網(wǎng)關(guān)中配置映射關(guān)系和權(quán)限控制就可實(shí)現(xiàn)服務(wù)的復(fù)用了。

相信這些痛點(diǎn)也是為什么當(dāng)當(dāng)網(wǎng)在dubbox（基于Dubbo的開(kāi)源擴(kuò)展）中增加了對(duì)REST支持的原因之一。

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

Round 4：文檔質(zhì)量

Dubbo的文檔可以說(shuō)在國(guó)內(nèi)開(kāi)源框架中算是一流的，非常全，并且講解的也非常深入，由于版本已經(jīng)穩(wěn)定不再更新，所以也不太會(huì)出現(xiàn)不一致的情況，另外提供了中文與英文兩種版本，對(duì)于國(guó)內(nèi)開(kāi)發(fā)者來(lái)說(shuō)，閱讀起來(lái)更加容易上手，這也是dubbo在國(guó)內(nèi)更火一些的原因吧。

Spring Cloud由于整合了大量組件，文檔在體量上自然要比dubbo多很多，文檔內(nèi)容上還算簡(jiǎn)潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要查看其整合組件的詳細(xì)文檔。另外由于Spring Cloud基于Spring Boot，很多例子相較于傳統(tǒng)Spring應(yīng)用要簡(jiǎn)單很多（因?yàn)樽詣?dòng)化配置，很多內(nèi)容都成了約定的默認(rèn)配置），這對(duì)于剛接觸的開(kāi)發(fā)者可能會(huì)有些不適應(yīng)，比較建議了解和學(xué)習(xí)Spring Boot之后再使用Spring Cloud，不然可能會(huì)出現(xiàn)很多一知半解的情況。

小結(jié)：雖然Spring Cloud的文檔量大，但是如果使用Dubbo去整合其他第三方組件，實(shí)際也是要去閱讀大量第三方組件文檔的，所以在文檔量上，我覺(jué)得區(qū)別不大。對(duì)于文檔質(zhì)量，由于Spring Cloud的迭代很快，難免會(huì)出現(xiàn)不一致的情況，所以在質(zhì)量上我認(rèn)為Dubbo更好一些。而對(duì)于文檔語(yǔ)言上，Dubbo自然對(duì)國(guó)內(nèi)開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)更有優(yōu)勢(shì)。

總結(jié)

通過(guò)上面再幾個(gè)環(huán)節(jié)上的分析，相信大家對(duì)Dubbo和Spring Cloud有了一個(gè)初步的了解。就我個(gè)人對(duì)這兩個(gè)框架的使用經(jīng)驗(yàn)和理解，打個(gè)不恰當(dāng)?shù)谋扔鳎菏褂肈ubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可能因?yàn)橐粭l內(nèi)存質(zhì)量不行就點(diǎn)不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問(wèn)題；而Spring Cloud就像品牌機(jī)，在Spring Source的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性，但是如果要在使用非原裝組件外的東西，就需要對(duì)其基礎(chǔ)有足夠的了解。

從目前Spring Cloud的被關(guān)注度和活躍度上來(lái)看，很有可能將來(lái)會(huì)成為微服務(wù)架構(gòu)的標(biāo)準(zhǔn)框架。所以，Spring Cloud的系列文章，我會(huì)繼續(xù)寫(xiě)下去。也歡迎各位朋友一起交流，共同進(jìn)步。

【一些文章與示例的匯總】：http://git.oschina.net/didispace/SpringBoot-Learning