目前赶舆，Spring Cloud在國內(nèi)的知名度并不高肴裙，在前陣子的求職過程中，與一些互聯(lián)網(wǎng)公司的架構(gòu)師涌乳、技術(shù)VP或者CTO在交流時蜻懦，有些甚至還不知道該項目的存在∠ο可能這也與國內(nèi)阿里巴巴開源服務(wù)治理框架Dubbo有一定的關(guān)系宛乃，除了Dubbo本身較為完善的中文文檔之外，不少科技公司的架構(gòu)師均出自阿里系蒸辆，所以就目前情況看征炼，短期國內(nèi)還是Dubbo的天下。
那么第一次實施微服務(wù)架構(gòu)時躬贡，我們應(yīng)該選擇哪個基礎(chǔ)框架更好呢谆奥？
以下內(nèi)容均為作者個人觀點，知識面有限拂玻，如有不對酸些，純屬正常，不喜勿噴檐蚜。
Dubbo魄懂，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于阿里巴巴集團的各成員站點闯第。阿里巴巴近幾年對開源社區(qū)的貢獻不論在國內(nèi)還是國外都是引人注目的市栗，比如：JStorm捐贈給Apache并加入Apache基金會等，為中國互聯(lián)網(wǎng)人爭足了面子咳短，使得阿里巴巴在國人眼里已經(jīng)從電商升級為一家科技公司了填帽。
Spring Cloud，從命名我們就可以知道咙好，它是Spring Source的產(chǎn)物篡腌，Spring社區(qū)的強大背書可以說是Java企業(yè)界最有影響力的組織了，除了Spring Source之外敷扫，還有Pivotal和Netfix是其強大的后盾與技術(shù)輸出哀蘑。其中Netflix開源的整套微服務(wù)架構(gòu)套件是Spring Cloud的核心。
小結(jié)：如果拿Dubbo與Netflix套件做對比葵第，前者在國內(nèi)影響力較大绘迁，后者在國外影響力較大，我認(rèn)為在背景上可以打個平手卒密；但是若要與Spring Cloud做對比缀台，由于Spring Source的加入，在背書上哮奇，Spring Cloud略勝一籌膛腐。不過睛约，英雄不問出處，在背景這一點上哲身，不能作為選擇框架的主要因素辩涝，當(dāng)您一籌莫展的時候，可以作為參考依據(jù)勘天。
我們選擇一個開源框架怔揩，社區(qū)的活躍度是我們極為關(guān)注的一個要點。社區(qū)越活躍脯丝，解決問題的速度越快商膊，框架也會越來越完善，不然當(dāng)我們碰到問題宠进，就不得不自己解決晕拆。而對于團隊來說，也就意味著我們不得不自己去維護框架的源碼材蹬，這對于團隊來說也將會是一個很大的負(fù)擔(dān)实幕。
下面看看這兩個項目在github上的更新時間，下面截圖自2016年7月30日：
Dubbo ：https://github.com/dubbo
最后更新時間為：2016年5月6日
Spring Cloud ：https://github.com/spring-cloud
最后更新時間為：12分鐘前
可以看到Dubbo的更新已經(jīng)是幾個月前赚导，并且更新頻率很低茬缩。而Spring Cloud的更新是12分鐘前赤惊，仍處于高速迭代的階段吼旧。
小結(jié)：在社區(qū)活躍度上，Spring Cloud毋庸置疑的優(yōu)于Dubbo未舟，這對于沒有大量精力與財力維護這部分開源內(nèi)容的團隊來說圈暗，Spring Cloud會是更優(yōu)的選擇。
或許很多人會說Spring Cloud和Dubbo的對比有點不公平裕膀，Dubbo只是實現(xiàn)了服務(wù)治理员串，而Spring Cloud下面有17個子項目（可能還會新增）分別覆蓋了微服務(wù)架構(gòu)下的方方面面，服務(wù)治理只是其中的一個方面昼扛，一定程度來說寸齐，Dubbo只是Spring Cloud Netflix中的一個子集。但是在選擇框架上抄谐，方案完整度恰恰是一個需要重點關(guān)注的內(nèi)容渺鹦。
根據(jù)Martin Fowler對微服務(wù)架構(gòu)的描述中，雖然該架構(gòu)相較于單體架構(gòu)有模塊化解耦蛹含、可獨立部署毅厚、技術(shù)多樣性等諸多優(yōu)點，但是由于分布式環(huán)境下解耦浦箱，也帶出了不少測試與運維復(fù)雜度吸耿。
根據(jù)微服務(wù)架構(gòu)在各方面的要素祠锣，看看Spring Cloud和Dubbo都提供了哪些支持。
服務(wù)注冊中心ZookeeperSpring Cloud Netflix Eureka
服務(wù)調(diào)用方式RPCREST API
服務(wù)網(wǎng)關(guān)無Spring Cloud Netflix Zuul
斷路器不完善Spring Cloud Netflix Hystrix
分布式配置無Spring Cloud Config
服務(wù)跟蹤無Spring Cloud Sleuth
消息總線無Spring Cloud Bus
數(shù)據(jù)流無Spring Cloud Stream
批量任務(wù)無Spring Cloud Task
………………
以上列舉了一些核心部件咽安，大致可以理解為什么之前說Dubbo只是類似Netflix的一個子集了吧伴网。當(dāng)然這里需要申明一點，Dubbo對于上表中總結(jié)為“無”的組件不代表不能實現(xiàn)妆棒，而只是Dubbo框架自身不提供是偷，需要另外整合以實現(xiàn)對應(yīng)的功能，比如：
分布式配置：可以使用淘寶的diamond募逞、百度的disconf來實現(xiàn)分布式配置管理蛋铆。但是Spring Cloud中的Config組件除了提供配置管理之外，由于其存儲可以使用git放接，因此它天然的實現(xiàn)了配置內(nèi)容的版本管理刺啦，可以完美的與應(yīng)用版本管理整合起來。
服務(wù)跟蹤：可以使用京東開源的Hydra
批量任務(wù)：可以使用當(dāng)當(dāng)開源的Elastic-Job
……
雖然纠脾，Dubbo自身只是實現(xiàn)了服務(wù)治理的基礎(chǔ)玛瘸，其他為保證集群安全、可維護苟蹈、可測試等特性方面都沒有很好的實現(xiàn)糊渊，但是幾乎大部分關(guān)鍵組件都能找到第三方開源來實現(xiàn)，這些組件主要來自于國內(nèi)各家大型互聯(lián)網(wǎng)企業(yè)的開源產(chǎn)品慧脱。
另外渺绒，由于Dubbo是基礎(chǔ)框架，其實現(xiàn)的內(nèi)容對于我們實施微服務(wù)架構(gòu)是否合理菱鸥，也需要我們根據(jù)自身需求去考慮是否要修改宗兼，比如Dubbo的服務(wù)調(diào)用是通過RPC實現(xiàn)的，但是如果仔細拜讀過Martin Fowler的microservices一文氮采，其定義的服務(wù)間通信是HTTP協(xié)議的REST API殷绍。那么這兩種有何區(qū)別呢？
先來說說鹊漠，使用Dubbo的RPC來實現(xiàn)服務(wù)間調(diào)用的一些痛點：
服務(wù)提供方與調(diào)用方接口依賴方式太強：我們?yōu)槊總€微服務(wù)定義了各自的service抽象接口主到，并通過持續(xù)集成發(fā)布到私有倉庫中，調(diào)用方應(yīng)用對微服務(wù)提供的抽象接口存在強依賴關(guān)系躯概，因此不論開發(fā)登钥、測試、集成環(huán)境都需要嚴(yán)格的管理版本依賴楞陷，才不會出現(xiàn)服務(wù)方與調(diào)用方的不一致導(dǎo)致應(yīng)用無法編譯成功等一系列問題怔鳖，以及這也會直接影響本地開發(fā)的環(huán)境要求，往往一個依賴很多服務(wù)的上層應(yīng)用，每天都要更新很多代碼并install之后才能進行后續(xù)的開發(fā)结执。若沒有嚴(yán)格的版本管理制度或開發(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ù)用了空执。
相信這些痛點也是為什么當(dāng)當(dāng)網(wǎng)在dubbox（基于Dubbo的開源擴展）中增加了對REST支持的原因之一。
小結(jié)：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)袍镀，以標(biāo)準(zhǔn)化的姿態(tài)將一些微服務(wù)架構(gòu)的成熟產(chǎn)品與框架揉為一體，并繼承了Spring Boot簡單配置冻晤、快速開發(fā)苇羡、輕松部署的特點，讓原本復(fù)雜的架構(gòu)工作變得相對容易上手一些（如果您讀過我之前關(guān)于Spring Cloud的一些核心組件使用的文章鼻弧，應(yīng)該能體會這些讓人興奮而激動的特性设江，傳送門）锦茁。所以，如果選擇Dubbo請務(wù)必在各個環(huán)節(jié)做好整套解決方案的準(zhǔn)備叉存，不然很可能隨著服務(wù)數(shù)量的增長码俩，整個團隊都將疲于應(yīng)付各種架構(gòu)上不足引起的困難。而如果選擇Spring Cloud歼捏，相對來說每個環(huán)節(jié)都已經(jīng)有了對應(yīng)的組件支持稿存，可能有些也不一定能滿足你所有的需求，但是其活躍的社區(qū)與高速的迭代進度也會是你可以依靠的強大后盾瞳秽。
Dubbo的文檔可以說在國內(nèi)開源框架中算是一流的瓣履，非常全，并且講解的也非常深入练俐，由于版本已經(jīng)穩(wěn)定不再更新拂苹，所以也不太會出現(xiàn)不一致的情況，另外提供了中文與英文兩種版本痰洒，對于國內(nèi)開發(fā)者來說瓢棒，閱讀起來更加容易上手，這也是dubbo在國內(nèi)更火一些的原因吧丘喻。
Spring Cloud由于整合了大量組件脯宿，文檔在體量上自然要比dubbo多很多，文檔內(nèi)容上還算簡潔清楚泉粉，但是更多的是偏向整合连霉，更深入的使用方法還是需要查看其整合組件的詳細文檔。另外由于Spring Cloud基于Spring Boot嗡靡，很多例子相較于傳統(tǒng)Spring應(yīng)用要簡單很多（因為自動化配置跺撼，很多內(nèi)容都成了約定的默認(rèn)配置），這對于剛接觸的開發(fā)者可能會有些不適應(yīng)讨彼，比較建議了解和學(xué)習(xí)Spring Boot之后再使用Spring Cloud歉井，不然可能會出現(xiàn)很多一知半解的情況。
小結(jié)：雖然Spring Cloud的文檔量大哈误，但是如果使用Dubbo去整合其他第三方組件哩至，實際也是要去閱讀大量第三方組件文檔的，所以在文檔量上蜜自，我覺得區(qū)別不大菩貌。對于文檔質(zhì)量，由于Spring Cloud的迭代很快重荠，難免會出現(xiàn)不一致的情況箭阶，所以在質(zhì)量上我認(rèn)為Dubbo更好一些。而對于文檔語言上，Dubbo自然對國內(nèi)開發(fā)團隊來說更有優(yōu)勢仇参。
通過上面再幾個環(huán)節(jié)上的分析嘹叫，相信大家對Dubbo和Spring Cloud有了一個初步的了解。就我個人對這兩個框架的使用經(jīng)驗和理解冈敛，打個不恰當(dāng)?shù)谋扔鳎菏褂肈ubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦待笑，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可能因為一條內(nèi)存質(zhì)量不行就點不亮了抓谴，總是讓人不怎么放心暮蹂，但是如果你是一名高手，那這些都不是問題癌压；而Spring Cloud就像品牌機仰泻，在Spring Source的整合下，做了大量的兼容性測試滩届，保證了機器擁有更高的穩(wěn)定性集侯，但是如果要在使用非原裝組件外的東西，就需要對其基礎(chǔ)有足夠的了解帜消。
從目前Spring Cloud的被關(guān)注度和活躍度上來看棠枉，很有可能將來會成為微服務(wù)架構(gòu)的標(biāo)準(zhǔn)框架。所以泡挺，Spring Cloud的系列文章辈讶，我會繼續(xù)寫下去。也歡迎各位朋友一起交流娄猫，共同進步贱除。
【一些文章與示例的匯總】：http://git.oschina.net/didispace/SpringBoot-Learning
【轉(zhuǎn)載請注明出處】：http://blog.didispace.com/microservice-framework/
