最近在测试过程中，遇到了几次maven传递依赖冲突的问题，所以记录下解决的过程，遇到类似问题供参照。
问题现象：
某服务不可用，查看启动log有报错信息，例如：
java.lang.NoSuchMethodError，类名和方法名看起来，初步判断出是在某个依赖的jar包里。
排查步骤：
首先确认是哪个jar包。根据类名进行搜索，确认jar包为：netty。同时发现本地依赖的jar包版本都有多个，已经基本可断定是依赖版本冲突了。
确定是netty，那么看下具体是哪些地方引入了netty，在应用根目录打印依赖树：mvn dependency:tree>tree.txt
发现报错的nkv中引入的版本号是3.6.3.Final，dubbok引入的版本号是3.2.5.Final。可以断定是maven传递依赖的冲突了。
也可以在测试服务部署机器的tomcat lib目录下查找，确实是有两个版本的依赖:
解决办法：
附：概念解释
1.Maven依赖传递
假如有Maven项目A，项目B依赖A，项目C依赖B。那么我们可以说 C依赖A。也就是说，依赖的关系为：C—>B—>A。
那么我们执行项目C时，会自动把B、A都下载导入到C项目的jar包文件夹中。这就是依赖的传递性。
2.依赖传递的排除
如上，C—>B—>A。加入现在不想执行C时把A下载进来，那么我们可以用 <exclusions>标签。
<dependencies>
<dependency>
<groupId>B</groupId>
<artifactId>B</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<!--被排除的依赖包坐标-->
<groupId>A</groupId>
<artifactId>A</artifactId>
<version>0.0.1</version>
</exclusion>
</exclusions>
</dependency>
</dependencies>
所以，上述错误现象的解决办法就是：排除掉低版本依赖，引入高版本依赖。
提交代码，再部署，服务启动ok，调用ok。
