這是個老生常談的問題，每個技術團隊在業務轉型微服務化架構的時候都糾結過這個選型問題；
首先，dubbo 之前確實在 2012 年的時候發佈了最後一個版本 2.5.3 並且停止維護更新，在2017年的時候又”起死回生“，官方宣佈重啓更新，並重點投入開源建設；終於在 2017 年 9 月，新發布了 2.5.4 版本，這中間"沉寂"的 5 年的時間究竟是出於什麼原因，我們無需關注，幸運的是，Dubbo 於 2018 年 2 月通過投票進入 Apacha 基金會孵化器，並且宣佈框架不再僅侷限於 java 語言，這對於國內的很大一部分開發者而言算是一大福音；
所以想說的是，dubbo 框架並沒有廢棄，相反現在正處於積極活躍的開源孵化中，因此對於想使用 dubbo 的用戶而言，大可不必擔心，它確實是一個非常不錯的分佈式技術選型對象。
那接下來我們再聊聊 Dubbo 與 SpringCloud 的區別，希望能爲後續同樣糾結在這個問題上的同學提供一些參考意見。
從嚴格意義上來說，Dubbo和SpringCloud的定位是不一樣的，dubbo 包括官方對自身的定義很清楚，從github的項目簡介即可看出——Apache Dubbo is a high-performance, java based, open source RPC framework. 翻譯過來就是，Dubbo 是一個高性能的、基於java的開源 RPC框架；劃重點，高性能 和 RPC框架；
而 Spring Cloud呢，官方對於它的定義可以直接參考官網：
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).
簡單介紹就是 SpringCloud 提供了一系列通用工具來幫助開發者在分佈式系統裏快速構建一些常見模式，比如分佈式配置管理、服務發現、熔斷降級、智能路由、微代理、控制總線、一次性令牌、全局鎖、分佈式選主、分佈式session等等一系列你可能目前還沒想到，但是開發過程中也許會碰到的問題；看到這裏大家應該已經會有一個比較初步的感覺，SpringCloud 的設計目標是提供一整套服務治理能力，它是一個完整的體系，涉及範圍很廣；
而 dubbo ，它只是一個分佈式的 RPC 框架，如果一定要按照分佈式系統架構裏的功能來定義的話，只是解決了服務發現、服務路由、服務降級和負載均衡方面的能力，新版本里也提供了動態配置中心和服務治理相關的能力，但相比 Sprin Cloud 而言，還是差了相當一部分的能力；
從功能支持上來說，dubbo 的角色定位可能更像是另外一個大名鼎鼎的框架，那就是 gRPC，而且兩者在使用的方式以及工作原理上都非常相似，都是基於序列化協議來解決分佈式系統中的遠程調用問題，在使用上可以通過約定接口或者通過 proto 文件生成代碼文件來“提升用戶的使用”
那麼問題來了，功能越多一定越好嗎？答案顯然不是，取決於你究竟想要什麼？
如果你在系統設計之初就已經考慮到了後續可能會涉及到各種服務治理能力，比如分佈式配置、全局鎖、分佈式session等常見需求，那麼使用 SpringCloud 將會減少你很多的工作，因爲這些基本上都是"套件"，相互配合使用會非常順暢。如果你想要的只是解決分佈式架構後的遠程調用問題，那麼 Dubbo 是一個不錯的選擇。
SpringCloud 和 Dubbo 的基本差異大概就是如上所述，很多同學可能還是覺得很迷茫，不知道該如何做選擇，這裏再補充幾個比較關鍵的差異點，希望能幫助你更好的結合自身業務做出選擇：
1、能力支持方面
上文也提到，SpringCloud 提供了一整套微服務治理的功能組件，很多組件基本上都是"開箱即用"的，並且相互之間能很好的兼容，舉個例子，如果要在 Spring Cloud 裏實現服務發現、負載均衡和熔斷降級，你只需要引用SpringCloud 的依賴組件即可，直接通過註解便可使用，基本上零配置；而 dubbo 框架，除了上述提到的能力支持之外，如果想要使用熔斷降級，那你可能需要額外引用 hystrix 或者 resilience4j 來實現；溫馨提示，hystrix 官方目前也已經宣佈不再更新，並且推薦使用 resilience4j 。
2、協議兼容方面
SpringCloud 裏並沒有限制服務之間的通信協議，但是主流的一些客戶端比如 restTemple、feign 等都是直接支持使用 Ribbon 來做服務註冊發現和智能路由的，其底層通信的協議都是HTTP；而dubbo框架缺省是基於NIO異步傳輸使用 TCP 長連接並採用 Hessian 二進制序列化方式通信的；
這會涉及後續系統在擴展上的兼容性問題，比如需要調用一個三方系統或者是被第三方系統調用，相比而言 HTTP 協議可能更加通用。
3、模型定義方面
dubbo 在模型設計上將一個接口定義爲一個服務，而 SpringCloud 裏則是將一個應用定義爲一個服務，這兩者在模型上是存在很大差異的，你也許會奇怪，這個對使用會有影響嗎？從現有使用方面來說是沒有什麼影響的，但是你如果有關注 Service Mesh 最新微服務技術的話，目前對 Dubbo 協議這塊可能支持暫時還不完善，其中很大一部分原因就是因爲在服務模型上與 K8S 的服務模型有差異；
4、調用性能方面
如果分佈式系統中比較關注遠程調用的性能，那 Dubbo 可能是一個較好的選擇，基於 NIO 和 TCP 長連接的通信傳輸方式，在性能上相比 HTTP 協議是有絕對優勢的；當然基於 SpringCloud 你也可以使用 gRPC 協議來解決性能問題，那就是另外一個問題了。
網易輕舟就以 Spring Cloud 和 Service Mesh 作爲微服務基礎設施，適用於微服務改造、業務中臺、數字化轉型、工業互聯網、開放平臺等多種場景。