背景：最近在做一个企业内部管理系统，有个系统目前在并行开发，部署了两套环境，新部署的环境修改员工信息，岗位信息均失败，问题持续时间昨天下午到今天上午。
虽然问题原因已找到，但是确实是触发了原来自己埋的一个坑，由此可以引发更多的讨论。
问题异常：
{DE7BE210-87F3-4A32-B205-8BE2A601E78A}_20191113185447.jpg
这个异常很明显是说服务方的接口返回声明不对，但是事实却不是这样。
一开始的排查思路是
1.由于服务方和调用方都是目前我在负责，因此可以先查看服务方的包版本，服务方的接口声明及代码变更
2.查看调用方的代码，目前已将调用方的代码返回值全部去掉，调用完结束就OK，但是异常仍然存在。
然后刚好看到稳定性群里有人提到了arthas，因此觉得可以用它排查一下代码变更情况。
arthas:https://alibaba.github.io/arthas/index.html
将arthas下载到18.216的/opt/soft/arthas目录下
根据使用指南链接到指定jvm进程
java -jar arthas-boot.jar pid
链接成功后进行问题类代码反编译
反编译服务方实现类：jad com.corehr.service.impl.EditStaffServiceImpl
反编译调用方实现类：jad com.hrexternal.service.impl.CoreHrUserServiceImpl
1.怀疑是新代码没有部署，但是经过arthas反编译后代码是最新的。
因此找到架构部大佬，帮忙排查，
2.确认com.qypt.common.dto.ResultDto在服务方和调用方都有
3.确认调用方是否已请求到服务方
4.确认服务方是否有拦截器之类的实现
问题就在第4步，因为服务方确实有拦截器实现。
而且拦截的就是调用方的服务类和机器Ip
拦截器的逻辑如下图：
{C284B2B0-45EA-433A-BCCC-6291E80032E0}_20191113185904.jpg
这也就解释了为啥老是出现类型转换错误的问题了，这个拦截器的逻辑就是当访问CoreHrUserServiceImpl这里面的接口的时候会校验调用方IP是否在白名单里，否则会返回失败。
这个扩展一点来说上面这么写其实是有问题的，就如上面的异常一样，那返回false可以吗，也不可以。
本质上是鉴权访问，自己实现的拦截器其实是比较折中的方案，类似于一个简单的鉴权网关，那如果接口返回正好是ResultDto的话，调用方是需要知道这个鉴权返回协议码和消息的。因此如果想在服务框架拦截器里实现鉴权访问，鉴权成功之后正常执行，没有问题，如果鉴权失败建议直接抛出异常，自定义一个鉴权相关的异常。上面的描述其实也是一种自定义的实现，如果可以在框架层面做，有框架做鉴权其实是比较好的，业务方不需要关注鉴权逻辑，只需要配置鉴权相关的网关配置就行。调用方调用失败的时候可以明确的知道由于鉴权失败导致的，而不是接口数据类型转换导致的，更容易排查问题。
网友评论