微服务的目录结构一般分为如下几个模块：

 当我们做的项目稍微大一点之后，就会经常遇到需要把不同的模块分离出来的时候，比如微信的朋友圈、微信支付、聊天服务等模块，像这种微服务项目一般都会把base、common、前端抽离出来。

common：用于存放一些公用的模块，比如枚举类（成功和失败返回数据），对外公开，pom里面不含任何和业务相关的东西。
base：一个写业务逻辑的包，把项目公用的业务模块抽出来放到项目里，不对外公开。在base的pom文件里包含了所有公用业务逻辑的依赖，在base里引用之后，其他的业务模块就不需要再进入这些依赖了（依赖传递）。

注意在其他业务逻辑的模块里面，都需要引入base：

base依赖于common，因为实现base里面的业务也需要用到common里的枚举等。

 在父项目的pom文件里面有一个<dependencyManagement> 标签，像这样：

 所有导入的依赖都被放到了<dependencyManagement> 标签里面，

<dependencyManagement> 的作用：

管理依赖版本号，微服务项目如果把所有模块的依赖各自引入，会出现版本冲突的问题，所以<dependencyManagement>充当了一个全局的依赖管理。当某个 Maven 模块需要具体引用某依赖的时候，直接在集合中指定若干个，这样就可以实现整个项目依赖的全局管理，不至于零碎地分布在每个模块中。在此标签元素中声明了所需依赖的版本号等信息，当子项目引入此依赖 jar 包时就需要列出版本号，如果不添加此标签的话子模块的pom文件就会直接继承。

 relativePath的作用：

默认值为../pom.xml，会从本地路径中获取parent的pom。

如果是一个空值，表示将始终从仓库(父级的pom文件)中获取，不从本地路径获取。

maven构建jar包时候查找顺序：relativePath元素中的地址–本地仓库–远程仓库