架構完整度

Dubbo只是實現了服務治理，而Spring Cloud下面有17個子專案（可能還會新增）分別覆蓋了微服務架構下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。

Dubbo 提供了各種 Filter，對於上述中“無”的要素，雖然Dubbo本身並不提供，但可以通過擴充套件 Filter 來完善。例如：

• 分散式配置：可以使用淘寶的 diamond、百度的 disconf 來實現分散式配置管理。
• 服務跟蹤：可以使用京東開源的 Hydra，或者擴充套件 Filter 用 Zippin 來做服務跟蹤。
• 批量任務：可以使用噹噹開源的 Elastic-Job、tbschedule。

注意：Spring Cloud中的Config元件除了提供配置管理之外。由於其儲存可以使用git，因此它天然的實現了配置內容的版本管理，可以完美的與應用版本管理整合起來

通訊協議

Dubbo的服務呼叫是通過RPC實現的，SpringCloud是基於HTTP協議的REST API。

使用Dubbo的RPC來實現服務間呼叫的一些痛點：

• 服務提供方與呼叫方介面存在強依賴關係
  不論開發、測試、整合環境都需要嚴格的管理版本依賴，才不會出現服務方與呼叫方的不一致導致應用無法編譯成功等一系列問題。
  而REST介面相比RPC更為輕量化，服務提供方和呼叫方的依賴只是依靠一紙契約，不存在程式碼級別的強依賴，當然REST介面也有痛點，因為介面定義過輕，很容易導致定義文件與實際實現不一致導致服務整合時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的程式碼與文件一體化，就能解決。所以在分散式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。
• 服務對平臺敏感，難以簡單複用
  通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平臺的特點，任何一個語言的呼叫方都可以根據介面定義來實現。那麼在Dubbo中我們要提供REST介面時，不得不實現一層代理，用來將RPC介面轉換成REST介面進行對外發布。若我們每個服務本身就以REST介面方式存在，當要對外提供服務時，主要在API閘道器中配置對映關係和許可權控制就可實現服務的複用了。這也是為什麼噹噹網在dubbox（基於Dubbo的開源擴充套件）中增加了對REST支援的原因之一。