這是兩個作用和使用場景不同的框架，目前的情況來看都不會被淘汰。

springcloud用於微服務，dubbo用於服務治理，各有各的適用場景。

在國外springcloud使用的多，在國內dubbo使用的多。

springcloud由國外的spring團隊開發維護，熱度和可靠性不用多說，dubbo由國內的阿里巴巴開發，現交由Apache孵化器，可靠性也很高。

阿里研發的dubbo都已經被阿里淘汰了。阿里媒體上吹dubbo的牛逼，參與的政企類投標，技術方案全是Spring Cloud

微服務現在是一陣風而已，實際來說，很多系統不適用，綜合算下來，微服務成本比原來大多了。不是所有系統都是網際網路，都是彈縮性很強。有的系統就是固定資料量，穩定執行，可能幾個大一點伺服器就足夠了。

真正需要微服務的不會像現在看到的那麼多。

慢慢沉澱，估計會把一些不需要的改回去，套殼的改回去。

如果簡化方式，感覺dubbo這種輕便的有優勢，開發運維都簡單。或者替代品也是輕便為主。

剩的可能真的需要微服務，一般都是中等規模以上的，或者巨頭，一般都有自己的內部框架。這種用也得全套完善的。

分層是電腦科學永恆的主題，service mesh是微服務的未來，這樣看來這兩個以後都會被取代，只有spring boot能夠繼續存活。

應該是不會被淘汰的，畢竟springcloud也是很多年來發展出來的結晶，而dubbo是目前非常火爆的一個框架，所以說我們未來還是會不斷地使用這兩個東西的。他們都是總結了之前很多的優點，然後摒棄了一些缺點所出來的目前來說市場上非常優秀的東西。

dubbo生態圈沒有spring cloud好，會被先淘汰掉。現有架構都會優先選擇Spring cloud，畢竟使用起來更簡單一點。

是否會被淘汰，取決於他們的更新，速度以及社群的支援情況和力度，而且他們兩個本身解決的角度和維度也不同。dubbo主要解決的是Rpc的遠端呼叫以及服務治理

Springcloud主要解決的是為服務，等一個實現的解決方案，以及成型的一個開發理念和開發規範本身屬於抽象的概念。

所以不能同日而語。

兩者面向的未來的發展方向呢，Springcloud會面向於花園跨平臺盛世華生態的一個雲服務的一個支援和微服務2.0第一個擴充套件發展，至少我個人認為近期不會被淘汰，但是未來。k8s的崛起以後可能會在市場份額上打壓一下。sc和dubbo的發展 sevicemesh也起來了，我只能說會慢慢地不佔據主導，但是不代表他會被淘汰。

關注的點不一樣，一個是微服務，一個是RPC，能說我們光用微服務不用RPC嗎？就目前生態來看，RPC要全部改造為Cloud也不是一件很簡單的事情，隨著service mesh的興起，未來到底是以RPC首當其中，還是微服務一馬當先還很難說

不會被淘汰，不同的需求使用不同的技術解決方案，有可能市場需求小被遺棄，但只要有市場就會有人用，好比ssh到現在還是有人在用一個道理，springcloud和dubbo算是業內比較熱門技術，被淘汰和取代的概率比較小。

個人覺的兩者都不會被淘汰，但是在未來分散式微服務解決方案中或者架構中，springCloud會佔主導地位。

springCloud：

2.springCloud是基於springboot的，spring的使用部署太方便了。

dubbo：

1.dubbo更多解決的是服務間的呼叫，也就是服務通訊協議rpc，也會是dubbo沒有完整的分散式解決方案基礎設施。例如：註冊中心需要藉助Zookeper，鏈路追蹤：zipkin。

要說Dubbo，算是Spring Cloud的一個子集好了,大致相當於Spring Cloud裡的 Eureka + Feign + 1/2Hystrix另外

現在大公司也在慢慢想springCloud服務過度，還有面試中文springCloud問題越來閱讀，dubbo越來越少。