事件起因

还是那个项目，至少对于我来说要学习的东西其实还是挺多的。

需求

员工信息管理，员工简历，导出功能，需要去联查员工的各项信息，其中，涉及到微服务的之间的操作出现了问题，目前主要的微服务是person服务，需要向basic-config服务请求具体的帮助，然后获取到null的结果，因为接手的是成型代码，所以不敢大规模的改动，目前情况是person服务没有收到basic-config服务的返回值，但是basic-config服务收到了person服务的请求与参数。

分析

首先，因为这个是成型的代码，所以没有太大的问题，而且微服务之间的是相互通的，这是大前提。其次，项目年头挺长了，确实有两边相同实体但是不一致的情况，可能是因为历史问题有些内容没有成功提交，或者提交了但是不在我们目前掌握的项目之中，定下了其中的一个方向就是实体不一致的问题。

问题处理

首先，我们朝着实体的角度去考虑，确实两边实体有轻微不一致，包括有的地方是使用手写的getset有的是使用直接生成的lombok的Getter、Setter、ToString。
而且两边实体极其麻烦，是由三层架构组成。
确实在比较上面花费了我很大的心思，就是一个实体，里面存在的包含的因素是一个list，然后这个list他也是包含了一个list，这一步我大概花费了不断地时间。

其实转机在这里，确实我是没有注意到，BasicConfigFeignService日志打印已经将BasicConfig服务的返回值打印出来了，还有个没有注意到的点就是，当我在postman访问的时候，person服务和basicconfig服务在person服务请求basicconfig服务的过程中同时响应了，

同一个请求，两边同时响应了，其实就是意味着其实，这一块被熔断了，当basicconfig服务在执行获取数据组织数据时，person已经熔断了，已经返回了null，等basicconfig执行完之后将数据传回person服务的时候其实已经结束了，所以在BasicConfigFeignService会打印出basicconfig的返回值。
相应的验证其实我也应该意识到了，其实当实体比较没有生效的时候提出了两个解决办法。
第一个还是对于实体的一个怀疑，将basicconfig服务中的实体全部迁移到person中，发现问题没有改变，最后放弃这个想法的做法将person服务接受返回值的参数从实体修改为String，发现String也是空的，就放弃这个想法。
第二个想法是有没有可能是数据量过大，因为我们观察了BasicConfigFeignService日志返回的结果，发现数据量确实不小，大概是成百上千条，然后我这边不想大规模破坏对应的代码转而使用了在basicconfig服务执行完成之前的一步，去除多余数据，然后发现没有生效，要是我当时使用直接全部新建一套实体其实早就可以发现这个问题了。
从postman调用的时候其实就已经很明显了，问题是出现在feign的熔断，原本feign 的配置是

修改为

取消熔断，并且加强超时间
然后问题处理，就是因为执行时间过长，导致的。
虽然整件事的最后以扣掉这个功能的前台按钮未结束，但是我确实学到了东西。