一、背景
假設有一個遺留的Dubbo系統，現在想改用Spring Cloud。
由於遺留Dubbo系統比較龐大，短期之內無法完成技術棧的遷移。因此需要“分步走”，即：初期實現兩者共存，後期逐步絞殺Dubbo應用，最終實現技術棧的統一。
p.s. 這裏並沒有貶低Dubbo的意思，僅是按照該場景討論。
二、頭腦風暴
架構遷移、技術棧更換、項目重構時的第一步往往不是“改造”，而是“停止修改”。基於這個原則，個人不太傾向於去立即大幅重構Dubbo應用原先的代碼。原因有二：首先是原則問題，更重要的是時間成本、技術風險很難得到控制。
而，假如新編寫的Spring Cloud應用去進行遷就，例如：
完全不動Dubbo遺留系統，使用RestTemplate或Feign編寫Dubbo（DubboX）的RESTful API客戶端代理 —> 有一定的實現複雜度、Dubbo接口改造成RESTful API後，消費方都需要再次修改（開始是代理，後來不用代理，因此有二次修改的問題）。
索性將Spring Cloud應用也整合Dubbo—>存在改造不完整、技術棧不統一、無法約束開發人員用哪種方式API、額外的複雜度的問題（越多的組件、越多的環節意味着越多的坑）。
考慮到一般來講，遺留系統的改造過程中一般都是新系統調用老系統，很少出現老系統大規模調用新系統的場景（至少我這邊目前是這樣^_^）。因此，筆者列出幾種僅需少量的代碼編寫成本即可實現Spring Cloud與Dubbo短期/長期共存，並且侵入性較小，同時還允許我們改造遺留Dubbo系統的幾種方案，算是拋磚引玉。期待朋友們提出更優雅、成本更小的方案。
三、亮代碼
Sample1：藉助Ribbon調用Dubbo應用。
優點：
架構不依賴Eureka或其他服務註冊組件，藉助Ribbon去調用Dubbo微服務暴露的RESTful API；
缺點：
如果Dubbo微服務較多時，均需手動配置，不適合新式的部署環境（例如Docker，因爲每次部署IP/端口可能都不同）
Sample2：藉助Sidecar
使用Sidecar，Dubbo微服務必須實現健康檢查（對於Spring Boot程序即：添加spring-boot-starter-actuator依賴）。
優點：
這種方式下，Dubbo應用也可通過Sidecar調用Spring Cloud微服務的接口，Sidecar是連接Spring Cloud應用於Dubbo應用的橋樑。
可以通過Sidecar傳播Dubbo微服務的健康狀態到Eureka Server。
缺點：
在於每個Dubbo微服務節點必須額外部署一個Sidecar應用。
在Dubbo微服務調用Spring Cloud微服務時，增加了調用鏈的長度。（需使用Sidecar轉發）
Sample3：藉助Eureka實現整合
將Dubbo應用也註冊到Eureka上。
優點：
沒有多餘的組件（除了Dubbo的註冊中心ZK）
沒有什麼侷限
缺點：
對於非Spring Boot的應用，改造有一定的成本。
GOING FAR
本項目中幾個Demo中，都是手動編碼爲Dubbo應用開放RESTful API的，實際遷移過程可以藉助cglib或者lombok之類的工具，實現從Dubbo接口道RESTful API的轉換。本倉庫主要還是爲大家提供思路，不做具體討論。
代碼下載地址
https://github.com/itmuch/spring-cloud-dubbo-together