【原】從零開始改造淘淘商城（引入dubbo解決項目耦合）02，淘淘dubbo

【原】從零開始改造淘淘商城（引入dubbo解決項目耦合）02，淘淘dubbo
前言：　　關於為什麼要引入dubbo架構，而不是用spring cloud或者是motan呢，主要是筆者現在公司用的就是dubbo,並且第一次接觸到微服務的概念是來源於dubbo，再加上最近dubbo頻繁的更新，所以就有採用dubbo改造的想法。建議沒看過這個教程的園友可以先看看原來的教程,因為現在所寫的一些東西是基於原來的教程源碼上重構的版本。

•      首先看下改造前的一個版本如下（前台主站）：

　　　　　

 

　　　通過可知portal不負責db操作,而是通過調用rest項目完成資料更新或查詢;筆者現在的公司項目也有很多這種調用方式,主要原因是因為調用方是一個非常古老的項目，系所採用的架構是ssh,且項目比較龐大,耦合度很高,並且大量的商務邏輯代碼擠壓在一起,短時間內無法重構成微服務,所以目前用的也是httpclient方式去調用rest服務。這種方式有幾個不好的地方如下：

• 解決辦法：
• 統一服務介面層,服務介面層只負責對外提供服務,調用方只負責調用的服務介面; 假如某天服務提供者需要部署更新,那麼只需要部署對應的服務, 比如訂單服務,更新的的只是訂單服務,不會影響其他服務的提供,同理調用方也不會因為訂單服務要維護導致調用方也跟著受影響,頂多就是當前更新的這個服務用不了而已,簡單來說就是減少顆粒度範圍。
• 　　重構思路：

　　　　將每個項目中的service介面層提取出來,放到taotao-service-api裡,然後將taotao-manager-service做成服務提供者,實現taotao-service-api所有的介面,也就是dubbo裡面的Provider;將rest、portal項目作為dubbo裡面的Consumer角色,引用taotao-service-api。

• 重構後項目結構如下：

•