前言：
异常信息：
java.io.IOException: UT000128: Remote peer closed connection before all data could be read
在九月份-十月初一直都被这个问题困扰～
排查链路
第一次、二次、三次排查该问题：
当时看到”Remote peer closed connection before all data could be read“ remote peer closed？
看到这些字眼第一次就判断大概率是接口意外断开链接导致的。琢磨着是不是用户在手机上强制关闭了小程序或者手机死机导致出现的问题～ 无视了该问题
现在想想这个想法还挺扯的～
第四次排查（终于重视了）同一个问题出现这么多次不正常！
理解问题现状
一直以为是因为客户端关闭导致的，细看才发现原来是“服务A”调用“服务B”出现的，看异常信息得仔细啊，兄弟萌，注意不止第一行！
刚看到这个远程调用错误关闭，确实没啥思绪（第一产生的想法是，有没有可能接口调用不通？有没有可能服务重启了？但是查了下pod重启信息，调用了下接口都没问题），此时想到的唯一就是（先问问度娘）
查询文献信息如下
分析
两个可能原因
1、传参的时候出现了问题导致超时
2、在读取所有数据之前，远程对等方已关闭连接
2这个点不大可能，因为同一个用户在我们的服务器请求时大多数情况都是正常返回的。除非正好cpu呗抢占导致没有返回用户信息。但是这样应该不止um服务会有这个问题所有服务应该都有，因为鉴权是一起的逻辑～（但是目前看来使用该解决方案好像解决问题了～）
并且在相同时间段鉴权服务也没有收到请求
怀疑是“1”导致的。因为在查询数据时userId是没有判空处理的，如果是通过网关来的请求userId是一定有值的（正常业务逻辑来说）。
但是目前也只有um服务是接入了网关在线上跑的。
不能完全排除“1”和“2”。
建议解决方案
1、优化鉴权。通过我们上周说的打通用户中心来完成整体鉴权，减少鉴权过程中返回数据包的大小（只返回必要的信息如：userId、openId、appId）。
2、增加判空校验。并且做好异常拦截如果确实是鉴权有问题考虑是否可以让用户重新静默登陆一次在重新点击一次（我认为是能够接受的，可容忍）。
最终选择了第二种解决方案！优先处理问题。
选择了第二种解决方案后从 2022-10-11 到 2023-03-07 为止还没再次出现过同类问题。
截止到现在问题算是解决了，但是这个原因具体目前还是不明。还没有找到最终原因，问题算是解决了～
经验教训
- 当同一个问题出现两次的时候就该重视起来了！
- feign调用的参数异常可能会以奇怪的方式爆出来，最好做足参数校验。
