Spring Cloud 和 Dubbo 哪一個會被淘汰？

 

今天在知乎上看到了這樣一個問題：Spring Cloud 和 Dubbo哪一個會被淘汰？看了幾個回答，都以爲不在點子上，因此要麼就乾脆寫篇小文瞎逼叨一下。

簡單說說我的觀點

我認爲這兩個框架大機率會長期都存在。

時至今日，這兩個框架放到如今，已經不存在誰取代誰這一說了。因爲Spring Cloud Alibaba的出現，Dubbo已經很好的融入到了Spring Cloud體系，因此圍繞Spring Cloud生態的各類周邊產品都是能夠無縫整合到一塊兒來玩的。

Dubbo無縫整合Spring Cloud生態是啥意思呢？主要兩方面：

1. 若是你原來是Dubbo用戶，那麼如今能夠把Spring Cloud引入進來。輕鬆便捷地整合Spring Cloud的配置中心、註冊中心以及諸如分佈式跟蹤等好用的周邊產品來管理你的分佈式服務集羣，與其餘Spring Cloud Netflix用戶享受同等的生態優點。

2. 若是你原來不是Dubbo用戶，可是你的場景在使用HTTP調用時候以爲不夠效率不夠經濟，那麼就能夠考慮引入Dubbo，來提高你服務間調用的RPC性能。

到這裏，可能有的看官要說了，你都是站在融合的角度來講的，我就是不喜歡Dubbo那種接口依賴的方式，堅定捍衛Spring Cloud原始生態！

行！這種堅持也是能夠的，並無什麼錯，經過HTTP契約方式管理服務接口，不用接口提供方的JAR，這在編譯層面上就不會產生耦合，這點確實一直是目前不用Dubbo的一個重要論據。我的也以爲這種選擇在不少方面是有優點的，可是對接口的兼容設計也是有很是高要求的，只要能執行到位，任何一種方案均可以作的很流暢。

可是，我認爲Spring Cloud用戶對這種方案的堅持並不會影響Dubbo生態的消亡。主要兩點：

1. Dubbo的原始用戶羣巨大，在Spring Cloud佈道以前，Dubbo就擁有了極大的用戶羣體，如今既然有很好的融合方案，那麼融合的考慮確定要比重構的考慮要更爲穩妥的。

2. 有不少用戶會質疑阿里巴巴的開源項目容易太監，此次Dubbo從新維護，又能堅持多久？其實這點此次就不用過多的擔憂，由於目前的Dubbo已經給了Apache基金會，因爲Apache對開源項目在是否可長期維護的評估上有很高的要求（活躍度、貢獻比例等），能在Apache畢業的項目，除非出現了一個在各方面都能超越它的東西出現，否則就會很長時間的存在且並應用。

不論從Spring Cloud用戶來講，仍是Dubbo用戶來講，都沒有絕對要消亡另外一方的場景存在。因此，我的認爲這兩個極大可能會成爲好基友，尤爲在國內的應用上。

往期推薦

超級乾貨：關於數據中臺的深度思考與總結

Java 處理 Exception 的 9 個最佳實踐！

表明Java將來的ZGC深度剖析，牛逼！

微服務架構下靜態數據通用緩存機制

一文搞定分佈式系統ID生成方案