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从依赖中排除