1.專案拆分為微服務 訂單服務被單獨拆出 負責訂單的下單取消退款等等

訂單服務 provider

商品服務 是訂單服務的comsumer

2.專案是maven多模組形式結構 以訂單的provider舉例

最外層pom.xml中 配置公共的基礎依賴jar包，其他子模組會相應引入相同的jar

order-api為暴露給comsumer呼叫的介面，service-order為api的實現，provider為main函式的入口，專案的啟動類

同時需要在最外層的pom.xml中定義子模組的module

module的名字跟子模組中的artifactId相同

以下為子模組的artifactId的例子

子模組需要宣告parent才能繼承父pom.xml的依賴 同樣需要填寫父parent的artifactId

模組之間的依賴關係 api模組只依賴最基礎的三方模組，不能依賴其所在專案的模組，防止出現迴圈依賴

service模組需要依賴api模組 以及相應的common模組（基礎的常用工具類或者result封裝物件可以寫在這裡）和mapper模組（資料庫的操作模組，也可以叫manager模組） 以及pojo模組（最基礎的實體模組，其不應該再依賴任何模組），

common模組和mapper模組以及pojo模組， 在comsumer專案中有，通過install命令推到maven的本地倉庫中

provider專案可以通過引入maven依賴的形式 去使用這些jar

啟動類模組中需要依賴service模組，因為需要在啟動的時候載入這些模組

一定要加上包掃描，因為預設的掃描只會掃描該啟動類所在的目錄以及其子目錄，而多模組並不滿足這個條件

所以需要特別定義

掃描的路徑 就是每個子模組下的java目錄下的第一個包路徑 比如 com.nchu.order

並不需要考慮子模組名稱

需要注意的點。

第一，迴圈依賴，這個出現頻率最高！ 舉個例子， 如果common模組依賴了pojo模組，mapper模組依賴common模組，而pojo模組居然去依賴mapper模組，此時就出現了迴圈依賴，因為此時 common模組裡面有pojo模組，mapper模組裡裡面有commom模組，而pojo裡面有mapper模組。 分析如下 commom->pojo->mapper->comom ，死迴圈

迴圈依賴報錯如下

解決方式

Analyze->Analyze Module Dependencies.

即可看到標紅

通過這種方式可以知道具體是哪些模組出現了迴圈依賴，去對應的pom檔案中去刪掉即可

千萬注意模組之間的依賴關係。

還有一種情況，就是迴圈依賴出現在誤操作的時候引入，則可以繼續用下面這種方式去解決

選中pojo 然右鍵

最後選擇modules 找到要解決衝突的子模組名稱 選擇dependencies 選擇剛剛衝突的mapper 右鍵remove 即可

第二 重複依賴 即對同一個介面 引入多個實現類，常見於日誌框架，因為日誌slf4j就是一個介面，它的實現有很多，比如logback log4j等

這裡報錯就是 slf4j有多個實現類 衝突了 。原因是，在maven專案裡引入多了多個jar，比如說引入了zookeeper和dubbo, 而dubbo和zookeeper分別對是slf4j採用了不同的實現類，一個使用的是log4j,一個是logback ，這樣在spring在注入的時候，就不會不知道該注入哪個bean

解決方法一，直接找到這個jar所在的目錄，直接刪掉， 這個方法簡單粗暴，但是隻能用一時，下次編譯的時候，又會從maven倉庫裡引入進來

解決方法二，利用idea提供的maven依賴管理工具去從pom.xml裡把衝突的jar移除

方法二的解決方式 在pom.xml中，右鍵maven ->show dependencies

可以很明顯的找到衝突的jar 但有時候也需要根據經驗去判斷

選中之後 右鍵 exclude 即可將多餘的jar從依賴中排除