Spring Cloud與Dubbo共存方案總結

1、背景

假設有一個遺留的Dubbo系統，如今想改用Spring Cloud。

因爲遺留Dubbo系統比較龐大，短時間以內沒法完成技術棧的遷移。所以須要「分步走」，即：初期實現二者共存，後期逐步絞殺Dubbo應用，最終實現技術棧的統一。

p.s. 這裏並無貶低Dubbo的意思，僅是按照該場景討論。

2、頭腦風暴

架構遷移、技術棧更換、項目重構時的第一步每每不是「改造」，而是「中止修改」。基於這個原則，我的不太傾向於去當即大幅重構Dubbo應用原先的代碼。緣由有二：首先是原則問題，更重要的是時間成本、技術風險很可貴到控制。

而，假如新編寫的Spring Cloud應用去進行遷就，例如：

徹底不動Dubbo遺留系統，使用RestTemplate或Feign編寫Dubbo（DubboX）的RESTful API客戶端代理 —> 有必定的實現複雜度、Dubbo接口改形成RESTful API後，消費方都須要再次修改（開始是代理，後來不用代理，所以有二次修改的問題）。

索性將Spring Cloud應用也整合Dubbo—>存在改造不完整、技術棧不統1、沒法約束開發人員用哪一種方式API、額外的複雜度的問題（越多的組件、越多的環節意味着越多的坑）。

考慮到通常來說，遺留系統的改造過程當中通常都是新系統調用老系統，不多出現老系統大規模調用新系統的場景（至少我這邊目前是這樣^_^）。所以，筆者列出幾種僅需少許的代碼編寫成本便可實現Spring Cloud與Dubbo短時間/長期共存，而且侵入性較小，同時還容許咱們改造遺留Dubbo系統的幾種方案，算是拋磚引玉。期待朋友們提出更優雅、成本更小的方案。

3、亮代碼

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