一、背景

假設有一個遺留的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