前言
前面我們已經(jīng)了解了微服務(wù)的服務(wù)分層和技術(shù)架構(gòu)分層，接下來我們就要選擇一個框架將微服務(wù)進(jìn)行落地。我們都知道，現(xiàn)在在微服務(wù)市場比較流行的有 2 大框架，一個是 Ali 的 Dubbo，一個是 SpringCloud。兩者孰優(yōu)孰劣一直是一個比較令人頭疼的問題。
1. 技術(shù)選型考慮的要素
其實我們可以先不去考慮是采用 Dubbo 還是 SpringCloud，而是回到技術(shù)選型本身，先看下技術(shù)選型可能存在的指標(biāo)，然后根據(jù)這些指標(biāo)來考慮到底是選擇那個微服務(wù)框架。
| 考慮要素 | 評判 |
|---|---|
| 背景 | 調(diào)研選型技術(shù)的背景，了解來源 |
| 是否滿足業(yè)務(wù)需求 | 是否能滿足業(yè)務(wù)的需求，切記避免過重引用，技術(shù)是支撐業(yè)務(wù)，避免太過超前于業(yè)務(wù) |
| 成本 | 成本包含了人力成本，時間成本，還有資源硬件成本 |
| 是否開源 | 如果是開源，應(yīng)該清楚開源的組織是哪一家，謹(jǐn)慎使用社區(qū)版 |
| 社區(qū)活躍度 | 社區(qū)活躍度在一定程度決定軟件質(zhì)量，當(dāng)你碰到問題之前活躍的社區(qū)已經(jīng)有其他人碰到過，并可能已經(jīng)很好的解決 |
| 安全性 | 了解框架或組件是否存在漏洞 |
| 與本公司技術(shù)棧是否一致 | 盡可能考慮與公司技術(shù)棧一致或相差不關(guān)的技術(shù)，可以保證質(zhì)量和成本 |
| 是否是自己熟悉的技術(shù) | 一次選型不要引用過多未知新技術(shù)，避免出現(xiàn)過多不可控風(fēng)險，保證穩(wěn)定 |
| 穩(wěn)定性 | 系統(tǒng)是否開源長期運(yùn)行，是否已經(jīng)經(jīng)得住考驗 |
| 擴(kuò)展性 | 是否兼容其他平臺，是否可以進(jìn)行二次開發(fā) |
| 性能效率 | 考慮吞吐率，響應(yīng)時間等等 |
| 技術(shù)前進(jìn)的步伐 | 選擇的技術(shù)什么周期必須明顯長于項目的生命周期，確保技術(shù)本身都緊跟時間進(jìn)行迭代 |
可以看到，技術(shù)選型需要評估的指標(biāo)還是非常多的，也是要個很需要經(jīng)驗的決策。要進(jìn)行大量的調(diào)研和輸入，根據(jù)現(xiàn)有的業(yè)務(wù)情況作出一個符合自身情況的決策。
我們在做技術(shù)選型的時候最忌諱的是臨時抱佛腳，在網(wǎng)上隨意搜索幾個對比文章利用這些碎片化信息來做出決策。一定要確保我們的選型是基于當(dāng)前業(yè)務(wù)增長的判斷，還要弄清楚業(yè)務(wù)事實背后的假設(shè)。
即使這樣，也未必能選出一個最優(yōu)的方案，但是通過這一系列的評判標(biāo)準(zhǔn)絕對可以挑選出滿足當(dāng)下業(yè)務(wù)的技術(shù)棧。
2. Dubbo 還是 SprigCloud
2.1 Dubbo
Dubbo，阿里巴巴公司開源的一個高性能優(yōu)秀的服務(wù)框架，當(dāng)前 Dubbo 支撐的阿里分布式應(yīng)用內(nèi)支撐萬級別的應(yīng)用數(shù)，運(yùn)行在 20 多萬的服務(wù)器實例上，每天調(diào)用量萬億級別，是國內(nèi)最高的分布式應(yīng)用集群。目前 Dubbo 已經(jīng)被阿里贈予 apache 基金會成為頂級項目。
Dubbo 其實也經(jīng)歷過一段坎坷，中間出現(xiàn)一大段無人維護(hù)的階段，可能是讓路于阿里云收費(fèi)項目 HSF。不過目前已經(jīng)在 apache 頂級項目下重新維護(hù)，目前最新版本是 3.0。
2.2 SpringCloud
SpringCloud 是 Spring Source 的產(chǎn)物，Spring 社區(qū)的強(qiáng)大背書可以說是 Java 業(yè)務(wù)界無人能匹敵的組織，SpringBoot 和 SpringCloud 更是無縫的緊密相連，在 SpringCloud 發(fā)展得初期，Netfix 為其提供了強(qiáng)大的技術(shù)輸出，在一開始的階段 Netfix 開關(guān)套件基本上是 SpringCloud 的核心。不過隨著 Netfix 的部分組件不更新，SpringCloud 已經(jīng)在各個方面提供了替代甚至更強(qiáng)的方案。
如果只是拿兩者的背景做比較，前者在國內(nèi)影響力更大，后者在國外和國內(nèi)新興企業(yè)中影響力更大。但由于背靠 Spring Source 強(qiáng)大的靠山，在背景上，應(yīng)該是 SpringCloud 略勝一籌。不過不應(yīng)該作為選型框架主要依據(jù)。
2.3 社區(qū)活躍度
有人在 2017 年，Dubbo 還未加入 apache 頂級項目時，有人在做了兩個框架在 github 上的活躍度對比，可以看出 SpringCloud 是以小時為活躍維度，而 Dubbo 基本上以年為維度。
但在今天，Dubbo 在加入 apache 頂級項目后，在 github 重新對比，可以看出差距正在縮小
當(dāng)然真正的活躍不是這么簡單就做出評判，不過粗略的觀察還是可以得出結(jié)論，Dubbo 在社區(qū)特別是中國區(qū)，活躍已經(jīng)在恢復(fù)。當(dāng)官方?jīng)]有維護(hù)之后，還是有一些公司對 Dubbo 做了進(jìn)一步的開發(fā)和維護(hù)，例如當(dāng)當(dāng)基于 Dubbo 研發(fā)的分布式框架 Dubbox。
2.4 兩者的性能
Dubbo 和 SpringCloud 其實只是解決方案的框架，集中性能的差異主要體現(xiàn)在服務(wù)調(diào)用和傳輸協(xié)議上，Dubbo 使用的是 RPC 通訊協(xié)議，提供了 Dubbo 的序列化，Dubbo 缺省協(xié)議采用單一長鏈接和 NIO 異步通訊（保持連接、輪訓(xùn)處理），使用自定義的報文，適合小數(shù)量大并發(fā)的服務(wù)調(diào)用場景，
而 SpringCloud 缺省采用的是 HTTP 協(xié)議的 REST API。
網(wǎng)上有人特意做了個模擬測試兩者的性能，使用一個 Pojo 對象包含 10 個屬性，請求 10 萬次，Dubbo 和 SpringCloud 在不同線程數(shù)量下，每次請求耗時（ms）
以上圖片和測試結(jié)果均采自網(wǎng)上
不出意外，采用 HTTP 的 SpringCloud 確實比不過采用 RPC 的 Dubbo。但由此產(chǎn)生了：Http + Json 的 Rest 通信，性能上難堪重用，其實也是一種誤讀。
評估性能更大的程度是判斷 Http 協(xié)議的通信對于應(yīng)用的負(fù)載是否會成為真正的瓶頸點。
在大部分的公司網(wǎng)絡(luò)下，網(wǎng)絡(luò)消耗并不能算上什么太大的問題。如果真的有問題，SpringCloud 也并不是 Http + Json 強(qiáng)制綁定，也可以選用 Thrift，Protobuf 等高性能 RPC，序列化作為替代方案。
2.5 架構(gòu)完整性
上述的幾點在這次選型中，最多是參考點之一，真正決定選擇的是架構(gòu)的完整性，他決定了是否滿足我們的需求。
其實把 SpringCloud 和 Dubbo 進(jìn)行在架構(gòu)完整性對比有點不太公平，Dubbo 只是實現(xiàn)了服務(wù)治理，而 SpringCloud 到目前為止在 github 上已經(jīng)有三十多個項目，已經(jīng)覆蓋了微服務(wù)架構(gòu)下的方方面面。在一定得程度來說，Dubbo 是指 SpringCloud 的一個子集，但在選擇框架的問題上，方案完整度卻恰恰是一個最需要我們重點關(guān)注。
在上面章節(jié)中，說到了，微服務(wù)雖然帶來了模塊清晰劃分，獨(dú)立部署，技術(shù)多樣式的好處，但是由于分布式，也帶來了非常多的復(fù)雜度，這些復(fù)雜度，是需要進(jìn)行治理和必要的組件進(jìn)行支撐。
| Dubbo | SpringCloud | |
|---|---|---|
| 服務(wù)注冊中心 | Zookeeper | Netflix EureKa / Consule/Nacos |
| 服務(wù)調(diào)用凡是 | RPC | REST API |
| 服務(wù)網(wǎng)關(guān) | 無 | NetFlix Zuul / gateway |
| 斷路器 | 不完善 | NetFlix Hystrix |
| 分布式配置 | 無 | SpringCloud Config |
| 鏈路跟蹤 | 無 | SpringCloud Sleuth |
| 消息總線 | 無 | SpringCloud Bus |
| 批量任務(wù) | 無 | SpringCloud Task |
以上列舉出來一些常用的核心組件，從表格不難發(fā)現(xiàn)為何說 Dubbo 只是 SpringCloud 的一個子集，不過有一點必須聲明，Dubbo 里面對比項中的” 無 “并不是代表不能實現(xiàn)，只是默認(rèn) Dubbo 框架自身沒有提供，而我們在市面上還是可以找到很多與之相匹配的開源組件。
例如：
- 服務(wù)網(wǎng)關(guān)：可以采用 Nginx+lua 作為基礎(chǔ)網(wǎng)關(guān)，可以起到鑒權(quán)，路由等簡單網(wǎng)關(guān)的規(guī)則；
- 斷路器 ：可以采用 ali 的 Sentinel,Sentinel 比 Hystrix 功能還要強(qiáng)大，并有控制臺；
- 分布式配置 ： 可以采用百度的 Disconf 或者攜程的 Apollo 作為分布式配置管理，對比起，SpringCloud 的 Config，Config 是存儲和配置在 git 上，使用默認(rèn)配置不夠直觀，而 Disconf 和 Apollo 都提供了優(yōu)秀的控制臺，有灰度發(fā)布，權(quán)限隔離功能更加強(qiáng)大；
- 鏈路跟蹤 ： 可以使用 SkyWalking，目前 SkyWalking 也已經(jīng)納入 apache 的頂級項目，這 2 年發(fā)展迅速，相比 Zipkin，Cat 更加強(qiáng)大，更不用說 Sleuth；
- 消息總線 ： 可以使用 RabbitMq，采用 AMQP 協(xié)議的 RabbitMq 也可以實現(xiàn)消息代理將分布式系統(tǒng)節(jié)點串聯(lián)，達(dá)到廣播狀態(tài)；
- 批量任務(wù) ： 可以使用 xxl-job。
你可以認(rèn)為 Dubbo 是組裝電腦，SpringCloud 是品牌電腦。下面給出我們組裝完的 Dubbo 和 SpringCloud 的對比，其中選擇組裝的組件大部分來自國產(chǎn)：
| Dubbo + 自選組件 | SpringCloud | |
|---|---|---|
| 服務(wù)注冊中心 | Zookeeper | Netflix EureKa / Consule/Nacos |
| 服務(wù)調(diào)用凡是 | RPC | REST API |
| 服務(wù)網(wǎng)關(guān) | Nginx + Lua | NetFlix Zuul / gateway |
| 斷路器 | Sentinel | NetFlix Hystrix |
| 分布式配置 | Apollo | SpringCloud Config |
| 鏈路跟蹤 | Skywalking | SpringCloud Sleuth |
| 消息總線 | RabbitMq | SpringCloud Bus |
| 批量任務(wù) | Xxl-Job | SpringCloud Task |
Dubbo 在各個環(huán)節(jié)我們的選擇自由度很高，也可以說，只能外部去選裝。但畢竟是外部的選裝，例如我們?yōu)橐慌_組裝電腦選擇了一條內(nèi)存或一塊硬盤存在問題導(dǎo)致整臺電腦都奔潰。如果你是 DIY 的高手，這些都不是問題，但如果你是一名小白，或?qū)Ω鱾€組件不是太熟悉，那可能品牌機(jī)會更適合你。
SpringCloud 像品牌機(jī)，在 Spring Source 的整合下，做了大量的兼容性測試，保證了機(jī)器擁有較高的穩(wěn)定性，但 SpringCloud 的默認(rèn)組件中也有一些不太好用的組件。
除了以上我們講的組件的區(qū)別，還有一些小的細(xì)節(jié)，例如
筆者在早年使用 Dubbo 為了實現(xiàn)隱式傳參，就對 Dubbo 的源碼進(jìn)行了改動，（因為早點 dubbo 停止了維護(hù)，所以進(jìn)行了局部二次開發(fā)），在使用 SpringCloud，發(fā)現(xiàn)直接實現(xiàn) RequestInterceptor 就可以實現(xiàn)，可能 SpingCloud 是后發(fā)，所以在一些細(xì)節(jié)上更加考慮周到，更適合小白的使用。
2.6 學(xué)習(xí)，招聘成本
應(yīng)該說，學(xué)習(xí)成本是 SpringCloud 相比較 Dubbo 是更低的，各種組件基本都是開箱即用，并且依托于 SpringSource 大樹，兼容性和可靠性是有保障的，相信寫 Java 代碼的人無人不熟 Spring。在編碼上，依托 SpringBoot，各種組件配置即可使用，很大的降低的學(xué)習(xí)和入門成本。
3. 小結(jié)
關(guān)于 Dubbo 和 SpringCloud 的相關(guān)概念和對比，上面已經(jīng)敘述清楚了，至于選型是 選擇 Dubbo 還是 SpringCloud，這里得根據(jù)自身的情況需求出發(fā)，這里不做推薦選擇。
筆者之前用的一直都是 Dubbo，但后面去了一家新公司新的團(tuán)隊，選擇了是 ali 版本的 SpringCloud，考慮的原因是：新團(tuán)隊這方面相關(guān)經(jīng)驗還是比較欠缺，SpringCloud 提供了完整的組件支持，SpringCloud 不失為比較穩(wěn)妥的選擇。
作為后起之秀，SpringCloud 使用簡單方便，并且 SpringCloud 也有強(qiáng)大的社區(qū)支持，文檔方面也是非常完善，新團(tuán)隊沒有必要在此投入過多的時間去閱讀分散的文檔和研究各種開源組件，可以分出精力和時間在業(yè)務(wù)上。
而且公司還存在其他技術(shù)棧的團(tuán)隊，存在接口互調(diào)的需求。Dubbo 默認(rèn)使用的 RPC 并不能很好的實現(xiàn)跨語言，而 SpringCloud 默認(rèn) Http REST 本身就是支持跨語言實現(xiàn)。