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