前言： 關於為什麼要引入dubbo框架，而不是用spring cloud或者是motan呢，主要是筆者現在公司用的就是dubbo,並且第一次接觸到微服務的概念是來源於dubbo，再加上最近dubbo頻繁的更新，所以就有採用dubbo改造的想法。建議沒看過這個教程的園友可以先看看原來的教程,因為現在所 ...
前言：
關於為什麼要引入dubbo框架，而不是用spring cloud或者是motan呢，主要是筆者現在公司用的就是dubbo,並且第一次接觸到微服務的概念是來源於dubbo，再加上最近dubbo頻繁的更新，所以就有採用dubbo改造的想法。建議沒看過這個教程的園友可以先看看原來的教程,因為現在所改造的是基於原來的教程源碼上重構的版本。
-
首先看下改造前的一個版本如下（前臺主站）：
通過上圖可知portal不負責db操作,而是通過調用rest項目完成數據更新或查詢;筆者現在的公司項目也有很多這種調用方式,主要原因是因為調用方是一個非常古老的項目，系所採用的架構是ssh,且項目比較龐大,耦合度很高,並且大量的業務邏輯代碼擠壓在一起,短時間內無法重構成微服務,所以目前用的也是httpclient方式去調用rest服務。這種方式有幾個不好的地方如下：
- 後續加了一個新的服務調用地址,需要在對應的配置文件里配置地址,大量的配置文件出現會導致項目難以管理,維護成本變高。
- http的3次握手以及傳輸過程中的網路開銷等等。
- 由於是在service層發起http請求,Controller直接調用工程里的service,如果某天service下麵的ItemService需要部署更新,由於這些代碼都是在放在同一個項目不同包的下麵,是一個整體,必然會導致淘淘商城裡面的OrderService,SerachService,CartService等不需要維護的也不能正常提供服務。
-
解決辦法：
- 統一服務介面層,服務介面層只負責對外提供服務,調用方只負責調用的服務介面; 假如某天服務提供者需要部署更新,那麼只需要部署對應的服務, 比如訂單服務,更新的的只是訂單服務,不會影響其他服務的提供,同理調用方也不會因為訂單服務要維護導致調用方也跟著受影響,頂多就是當前更新的這個服務用不了而已,簡單來說就是減少顆粒度範圍。
-
重構思路：
將每個項目中的service介面層提取出來,放到taotao-service-api里,然後將taotao-manager-service做成服務提供者,實現taotao-service-api所有的介面,也就是dubbo裡面的Provider;將rest、portal項目作為dubbo裡面的Consumer角色,引用taotao-service-api。
-
重構後項目結構如下：
