微服務(wù)架構(gòu)的基礎(chǔ)框架選擇

微服務(wù)架構(gòu)的基礎(chǔ)框架選擇：Spring Cloud還是Dubbo最近一段時間不論互聯(lián)網(wǎng)還是傳統(tǒng)行業(yè)，凡是涉及信息技術(shù)范疇的圈子幾乎都在討論微服務(wù)架構(gòu)。第一次實施微服務(wù)架構(gòu)時，我們應(yīng)該選擇哪個基礎(chǔ)框架更好呢？Round 1：背景Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點。阿里巴巴近幾年對開源社區(qū)的貢獻(xiàn)不論在國內(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ù)。Round 2：社區(qū)活躍度我們選擇一個開源框架，社區(qū)的活躍度是我們極為關(guān)注的一個要點。社區(qū)越活躍，解決問題的速度越快，框架也會越來越完善，不然當(dāng)我們碰到問題，就不得不自己解決。而對于團(tuán)隊來說，也就意味著我們不得不自己去維護(hù)框架的源碼，這對于團(tuán)隊來說也將會是一個很大的負(fù)擔(dān)。下面看看這兩個項目在 github 上的更新時間，Dubbo ：/dubbo最后更新時間為：2016年5月6日Spring Cloud ：/spring-cloud最后更新時間為：12分鐘前可以看到 Dubbo 的更新已經(jīng)是幾個月前，并且更新頻率很低。而 Spring Cloud 的更新是12分鐘前，仍處于高速迭代的階段。小結(jié)：在社區(qū)活躍度上，Spring Cloud 毋庸置疑的優(yōu)于 Dubbo，這對于沒有大量精力與財力維護(hù)這部分開源內(nèi)容的團(tuán)隊來說，Spring Cloud 會是更優(yōu)的選擇。Round 3：架構(gò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 都提供了哪些支持。以上列舉了一些核心部件，大致可以理解為什么之前說 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ǔ)，其他為保證集群安全、可維護(hù)、可測試等特性方面都沒有很好的實現(xiàn)，但是幾乎大部分關(guān)鍵組件都能找到第三方開源來實現(xiàn)，這些組件主要來自于國內(nèi)各家大型互聯(lián)網(wǎng)企業(yè)的開源產(chǎn)品。RPC vs REST另外，由于 Dubbo 是基礎(chǔ)框架，其實現(xiàn)的內(nèi)容對于我們實施微服務(wù)架構(gòu)是否合理，也需要我們根據(jù)自身需求去考慮是否要修改，比如 Dubbo 的服務(wù)調(diào)用是通過 RPC 實現(xiàn)的，但是如果仔細(xì)拜讀過 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 之后才能進(jìn)行后續(xù)的開發(fā)。若沒有嚴(yán)格的版本管理制度或開發(fā)一些自動化工具，這樣的依賴關(guān)系會成為開發(fā)團(tuán)隊的一大噩夢。而 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 接口進(jìn)行對外發(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)工作變得相對容易上手一些。所以，如果選擇 Dubbo 請務(wù)必在各個環(huán)節(jié)做好整套解決方案的準(zhǔn)備，不然很可能隨著服務(wù)數(shù)量的增長，整個團(tuán)隊都將疲于應(yīng)付各種架構(gòu)上不足引起的困難。而如果選擇 Spring Cloud，相對來說每個環(huán)節(jié)都已經(jīng)有了對應(yīng)的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區(qū)與高速的迭代進(jìn)度也會是你可以依靠的強大后盾。Round 4：文檔質(zhì)量Dubbo 的文檔可以說在國內(nèi)開源框架中算是一流的，非常全，并且講解的也非常深入，由于版本已經(jīng)穩(wěn)定不再更新，所以也不太會出現(xiàn)不一致的情況，另外提供了中文與英文兩種版本，對于國內(nèi)開發(fā)者來說，閱讀起來更加容易上手，這也是 dubbo 在國內(nèi)更火一些的原因吧。Spring Cloud 由于整合了大量組件，文檔在體量上自然要比 dubbo 多很多，文檔內(nèi)容上還算簡潔清楚，但是更多的是偏向整合，更深入的使用方法還是需要查看其整合組件的詳細(xì)文檔。另外由于 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ā)團(tuán)隊來說更有優(yōu)勢。總結(jié)通過上面再幾個環(huán)節(jié)上的分析，相信大家對 Dubbo 和 Spring Cloud 有了一個初步的了解。就我個人對這兩個框架的使用經(jīng)驗和理解，打個不恰當(dāng)?shù)谋扔鳎菏褂?Dubbo 構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可