记一次使用dubbo过程中版本冲突导致的坑

前言：2019年09月23日临下班，产品的一个变更需求临近尾声阶段。本地测试OK，兴致冲冲的想着发布到测试环境，验证一下没有问题，五分钟结束战斗，明天就开始下个需求了。随在CE（公司的devOps系统）上切换到hotfix/xxx分支，部署上线。部署没有问题，跑了一通单测，呃呃呃呃呃。莫名的一堆错误。怎么可能，再deploy ,再重启，还是这个错误，难道是公司的CE有问题（以前会莫名其妙的出问题），释放掉重新申请服务器部署。忙了一通还是不行。绝望，后悔。公司的什么烂逼环境。本地明明没有问题，怎么部署一下就这样了（程序员通病，嘻嘻）。得，沙箱环境坏了，解决不了别想走了，明天ISV还要用。

查问题：入口肯定先根据日志确定问题呗，单测错误日志如下：

2019-09-24 19:19:57.899 ERROR --- [io-12345-exec-1] c.y.p.g.facade.ParkingBizOpenApiImpl     : (ParkingBizOpenApiImpl.java:90) : 参数校验或转换出错javax.validation.UnexpectedTypeException: HV000030: No validator could be found for constraint 'javax.validation.constraints.NotBlank' validating type 'java.lang.String'. Check configuration for 'auth_code',输入参数为：PrePayPTO(pay_type=ALIPAY, mch_id=2099190827010164, sub_mchid=20190827151134481925, auth_code=11111, total_amount=1, out_trade_no=ISV1569323953935, subject=测试订单, goods_detail=[{"goods_id":"goods_id123","goods_name":"停车缴费","quantity":1,"price":1}], goods_tag=, attach=, extend_params={"industry_reflux_info":{"parking_id":"PI1509464128728884840","car_number":"京XX1234","einlass":"2019-08-15 17:30:26","parking_hours":"1.5","parking_name":"测试停车场"}}, service_name=PKTEST01)

看日志大概意思就是说@NotBlank注解不能用在属性auth_code上，第一：我的代码这块没有改过，以前明明可以运行，第二：我的auth_code就是String类型的，并且@NotBlank就是使用在String类型上 ，然后网上找了一堆的blog,随发现有一个博客说springboot2.0 ，hibernate-validator版本冲突 也可能报这个错，删除本地所有引入的第三方包，然后重新import , 查看本地项目依赖，果然：

hibernate-validator 两个版本号，6.0.16.Final 是我自己的， 5.2.4.Final 是哪里来的，随查阅自己的show depencies  , 查找hibernate-validator 的引入如图：

根据两个版本点进去，最后发现5.2.4.Final 是引入别人的dubbo依赖带进来了，以前他们没有，后加的（所以先前没有暴露过问题，上图中的密密麻麻的依赖图也是引入他们的一个依赖后变成这样不忍直视的样子），然后从他们的依赖中排除掉hibernate-validator ，问题解决。

后记：

1：通过躺过的这个坑，我认为这虽然是编码者导致的问题，也算是使用dubbo的一个弊端吧。

2：现在编码的时候基本上都是一个project ，多个moduel的架构，所以很多时候暴露的dubbo接口的服务只是project的一个moudel ，而父pom中一般都会引入一下常用的依赖。这样无形中被服务消费者强制依赖。所以建议dubbo 对外api，尽量不要继承父pom,且以最少依赖发布接口。

3：以一个正常的心态，平心静气的分析问题，别什么问题都推脱给环境。

花絮：上面说的解决过程虽然很简单，但是由于实际中操作中各种原因，折腾了三四个小时。

首先：始终坚信是环境问题，我写的代码肯定没有问题；我压根就没有改过这里的代码，而且已经稳定运行了很久。

其次：线上环境服务器不给开权限，下载不了jar包，本地刚开始没有删除本地所有第三方依赖，因为上面那个依赖图太大，电脑死机，确认不了是哪个第三方依赖引入的依赖，且本地打包没有问题，本地复现不了，线上的jar包看不到。

最后：因为别人的依赖坑了我，然后赶快看看我对外提供的dubbo接口pom:

​​

还好，老子果然明智，没有继承父pom,独立出去的。然后看看依赖：

啊，咋回事。。。。哎，没办法，产品要个性化提示校验信息，要不就是好几十行的if/else ,算了，就这样吧，互坑互坑吧。。回家，睡觉。。。。。。。程序员不就是这样，被别人坑人再坑别人嘛。。。。