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