【远程调用返回400问题排查(已解决)】

前言

我最近给公司一个两年前开发的项目售后,帮助客户验视功能点,顺便帮助解决项目中的问题,由于原负责该项目的项目组已经全都离职了,导致验收之路漫长且艰苦…

在解决问题的过程中碰到了许多疑难杂症都一一解决了,唯独其中有一个问题让我和同事绞尽脑汁花了三天才得以解决,所以为了以后不再被这个问题困扰,特地记录一下,毕竟好记性不如烂笔头嘛,话不多说,我们接着往下看

发生问题由来

是这样一个问题,在测试的过程中发现某部分功能依赖的数据源有部分缺失的情况,然后就着手开始排查问题,调用链调用方式如下:

客户标识
获得请求token
RestTemplate
客户标识
我的服务
远程登陆
转发平台
客户服务1
客户服务2
客户服务3

问题排查

刚开始我觉得肯定是接口报错了,然后开了一个测试接口去调用远程访问方法,结果报错400 Bad Request!!!WTF?如果这个接口400那应该一条数据都没有才对啊,怎么一部分成功一部分失败??

1. 参数400

常见的400就是参数和定义的参数类型不一致导致参数400,然后我拿跑成功的数据作为条件传入,然后成功了,我觉得可能就是这个问题,然后又访问了一次然后也爆出400问题,然后接下去访问的都是400了,再换个成功的数据也无济于事,只要有访问通过的接口就说明肯定不是因为参数问题导致的400了,然后就去看转发平台的日志,也证实了没有爆出参数400的问题
ps:使用Postman调用也是畅通无阻…

2. 请求头过大导致400

通过查看转发平台日志,发现有个问题就是调用的接口要么访问到达,然后转发平台打出日志,要么什么反应也没有,然后我想到了是不是由于请求头过大的原因,然后我直接把所有参数都去掉然后直接访问,结果还是400,然后我又把请求头的token以及标识全去掉,结果终于在转发平台看到了unauthorization错误,果然是这个问题,然后我就询问负责转发平台的同事他们的Nginx设置请求最大大小是多少,然后被告知他们的平台没用到Nginx,那就是说刚刚那个就仅仅只是因为没有token报的错,跟请求头大小没有关系,到这再次断了线索…

然后我就往封装调用的各个地方都插入日志打印,想从日志中找出蛛丝马迹,在漫长的打印查看打印查看日志的过程中,终于让我逮住了问题的小尾巴,我在打印Header的内容时发现token的value是一个数组,且里面有两个token!!!

3. header异常400

在发现header异常后,我就仔细的去看封装好的代码,结果发现了下面这一串代码:

public HttpHeaders getHeaders() {
	  HttpHeaders httpHeaders = new HttpHeaders();
      httpHeaders.setContentType(MediaType.APPLICATION_JSON);
      TokenHelp tokenHelp = tokenHelpRepository.findTokenByConsumerId("客户标识");
      // 如果当前客户在数据库中没有token则取用默认的token
      if (null == tokenHelp){
          tokenHelp = tokenHelpRepository.defaultToken();
      }
      // 如果还是为空则取用登录token
      if (null == tokenHelp){
          LoginResponse loginResponse = getToken();
          httpHeaders.add(HttpHeaders.AUTHORIZATION, BEARER + loginResponse.getToken());
      } else {
      	  // 如果不为空则设置token
      	  httpHeaders.add(HttpHeaders.AUTHORIZATION, tokenHelp.getToken());
      	  // 获得时间差
          long diffMillis = System.currentTimeMillis() - tokenHelp.getCreateTime();
          // 超过十分钟重新获取token
          long outTime = 10 * 60 * 1000;
          if (diffMillis > outTime) {
              LoginResponse loginResponse = getToken();
              httpHeaders.add(HttpHeaders.AUTHORIZATION, BEARER + loginResponse.getToken());
          }
          httpHeaders.add("consumerId", "客户标识");
      }
      return httpHeaders;
}

以上代码乍看上去没什么问题,但是当我点击进HttpHeaders的实现:

package org.springframework.http;

public class HttpHeaders implements MultiValueMap<String, String>, Serializable {
  private static final long serialVersionUID = -8578554704772377436L;
  // ...省略多行代码
}

我看到了MultiValueMap,如果不了解MultiValueMap的同学可能觉得这没什么问题,Map装很正常啊,但是认识的同学都知道MultiValueMap 可以同一个key下面放多个value,原来的Map如果设置了同样的Key,那么值会被替换,但是当使用MultiValueMap时设置了同样的Key,那么值会被用一个数组装起来,为了方便大家理解,这里贴一段简单的演示代码:

public static void main(String[] args) {
    MultiValueMap<String, String> valueMap = new LinkedMultiValueMap<>();
    valueMap.add("1","1");
    valueMap.add("1","2");
    valueMap.add("1","3");
    valueMap.add("1","4");
    valueMap.add("1","5");
    valueMap.add("2","1");
    valueMap.add("2","2");
    valueMap.add("3","1");
    for (Map.Entry<String, List<String>> stringListEntry : valueMap.entrySet()) {
        System.out.println(“key:+stringListEntry.getKey());
        List<String> value = stringListEntry.getValue();
        System.out.println("value:"+value);
    }
}


输出结果:=================================================
key:1
value:[1, 2, 3, 4, 5]
key:2
value:[1, 2]
key:3
value:[1]
输出结果:=================================================

结合之前的代码看这个问题

		  // 如果不为空则设置token
      	  httpHeaders.add(HttpHeaders.AUTHORIZATION, tokenHelp.getToken());
      	  // 获得时间差
          long diffMillis = System.currentTimeMillis() - tokenHelp.getCreateTime();
          // 超过十分钟重新获取token
          long outTime = 10 * 60 * 1000;
          if (diffMillis > outTime) {
              LoginResponse loginResponse = getToken();
              httpHeaders.add(HttpHeaders.AUTHORIZATION, BEARER + loginResponse.getToken());
          }

else代码块中,先设置了一遍AUTHORIZATION然后如果当前token过期了那么会再次设置一遍,这就导致了,如果在token过期的一段时间内,就会有少部分的请求头中有两个token,就会导致请求400,然后更改了设置token逻辑后,接口就顺利通车啦!!!

总结

在处理接口400问题的时候一定要擦亮眼睛,一步一步的去排查问题所在点,魔鬼永远藏在不经意发现的地方,好了,到这分享就结束了,写的不好大家多多谅解哈~

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当使用Feign进行远程调用时,有时会遇到.lang.reflect.InvocationTargetException异常。这个异常是由Java的反射机制引起的,表示在调用方法时发生了异常。 java.lang.reflect.InvocationTargetException是一个包装异常,它将原始异常封装在内部。通常,我们需要查看InvocationTargetException的getCause()方法来获取实际的异常信息。 出现java.lang.reflect.InvocationTargetException异常的原因可能有很多,以下是一些常见的情况: 1. 远程服务不可用:如果远程服务没有启动或者无法访问,Feign调用就会失败,并抛出InvocationTargetException异常。 2. 请求参数错误:如果Feign调用的请求参数不正确,例如参数类型不匹配或者缺少必要的参数,远程服务可能会抛出异常,并导致InvocationTargetException异常。 3. 远程服务异常:如果远程服务在处理请求时发生了异常,它可能会将异常信息返回给Feign客户端,并导致InvocationTargetException异常。 为了解决这个问题,我们可以通过以下步骤来排查: 1. 检查远程服务是否正常运行,并确保可以正常访问。 2. 检查Feign调用的请求参数是否正确,并与远程服务的接口定义进行对比。 3. 查看InvocationTargetException的getCause()方法返回的异常信息,以确定实际的异常原因。 4. 根据具体的异常原因采取相应的措施,例如修复远程服务的bug或者调整Feign调用的参数。 希望以上信息对您有帮助!如果您还有其他问题,请随时提问。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值