假設有乙個遺留的dubbo系統，現在想改用spring cloud。
由於遺留dubbo系統比較龐大，短期之內無法完成技術棧的遷移。因此需要「分步走」，即：初期實現兩者共存，後期逐步絞殺dubbo應用，最終實現技術棧的統一。
p.s. 這裡並沒有貶低dubbo的意思，僅是按照該場景討論。
架構遷移、技術棧更換、專案重構時的第一步往往不是「改造」，而是「停止修改」。基於這個原則，個人不太傾向於去立即大幅重構dubbo應用原先的**。原因有二：首先是原則問題，更重要的是時間成本、技術風險很難得到控制。
而，假如新編寫的spring cloud應用去進行遷就，例如：
考慮到一般來講，遺留系統的改造過程中一般都是新系統呼叫老系統，很少出現老系統大規模呼叫新系統的場景（至少我這邊目前是這樣_）。因此，筆者列出幾種僅需少量的**編寫成本即可實現spring cloud與dubbo短期/長期共存，並且侵入性較小，同時還允許我們改造遺留dubbo系統的幾種方案，算是拋磚引玉。期待朋友們提出更優雅、成本更小的方案。
優點：架構不依賴eureka或其他服務註冊元件，借助ribbon去呼叫dubbo微服務暴露的restful api；
缺點：如果dubbo微服務較多時，均需手動配置，不適合新式的部署環境（例如docker，因為每次部署ip/埠可能都不同）
使用sidecar，dubbo微服務必須實現健康檢查（對於spring boot程式即：新增spring-boot-starter-actuator依賴）。
優點： 缺點：
將dubbo應用也註冊到eureka上。
優點： 缺點：
本專案中幾個demo中，都是手動編碼為dubbo應用開放restful api的，實際遷移過程可以借助cglib或者lombok之類的工具，實現從dubbo介面道restful api的轉換。本倉庫主要還是為大家提供思路，不做具體討論。
dubbo與springcloud對比與面試
對比 具體見此部落格 dubbo 組裝機 springcloud 品牌機 打個不恰當的比喻 使用dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題 而spring clo...
SpringCloud 服務註冊與發現
寫在開頭 網上關於springcloud的教程已經很多了，本系列博文不會去大家如何從頭構建乙個專案，只是對springcloud中的各個知識點做詳細的闡述，同時把一些細節提供給大家作參考。security basic enabled true user name user password 1234...
微服務 Dubbo與Spring Cloud
模組註解 provider 暴露服務的服務提供方。consumer 呼叫遠端服務的服務消費方。registry 服務註冊與發現的註冊中心。monitor 統計服務的呼叫次調和呼叫時間的監控中心。container 服務執行容器。流程詳解 0 服務容器負責啟動，載入，執行服務提供者 standalon...