springboot升级过程中踩坑定位分析记录 | 京东云技术团队

作者：京东零售李文龙

1.背景

“ 俗话说：为了修复一个小bug而引入了一个更大bug ”

为了修复此bug进行了spring版本的升级，最终定的版本为收银台团队使用的版本5.2.12.RELEASE，对应的springboot版本为2.2.12.RELEASE。

1.有团队经过了长时间的线上验证

2.修复了5.1.5.RELEASE对应的bug

2.升级上线

日志中分析是某些参数未解析到，后在nginx日志中查到相关请求，使用postman模拟请求可以正常使用。

3.分析验证定位原因

1.临时修复

过滤器的顺序在线上未配置，按照预发的配置后可正常使用。我们暂且称修改的这两个过滤器为M和A,

M->A，顺序修改为A->M后正常，其两者作用大致为：

M : 通用过滤器，解析url中的参数至parameterMap中，并初始化读取了body中的inputstream进行了byte数组的缓存，用于解决重复读取流问题 A: 特定处理器，先是查询parameter中的参数，然后逻辑处理后再设置一些特殊参数。

2.为何需要改过滤器顺序

但未有头绪，只能先调转方向分析为什么postman和浏览器中的swagger可以正常使用

3.分析nginx日志

postman ： POST /shop/bpaas/floor?client&clientVersion&ip=111.202.149.19&gfid=getShopMainFloor&body= 前端 : POST /shop/bpaas/floor HTTP/1.0" 200 634 "-" "api" "0.94" 0.008 0.007 client&clientVersion&ip=111.202.149.17&gfid=getShopMainFloor&body=

request.getParameter获取到，注意此方法是解决问题的关键，此时还未意识到。

4.升级前后框架是否有大的修改

org.springframework.web.filter.HiddenHttpMethodFilter

此过虑器的作用是在浏览器不支持PUT、DELETE、PATCH等method时，可以在form表单中使用隐藏的_method参数支持这几种method。好像跟参数解析没有任何关系，

“ Disable auto-configuration of HiddenHttpMethodFilter by default ” github上对应的版本release notes： https://github.com/spring-projects/spring-boot/releases/tag/v2.2.0.M5

5.添加过滤器enable配置

因bug修复列表中有对应的issues，所以找到了此过滤器对应的配置：

添加后可以正常使用，证明是此过滤器中在某种条件下不可缺少。

6.未升级spring版本时disable验证

7.深入源码分析

此时需要分析HiddenHttpMethodFilter过滤器中是否有特殊操作，源码如下：

protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain
			throws ServletException, IOException {

		HttpServletRequest requestToUse = request;

		if ("POST".equals(request.getMethod( && request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE == null {
			String paramValue = request.getParameter(this.methodParam;
			if (StringUtils.hasLength(paramValue {
				String method = paramValue.toUpperCase(Locale.ENGLISH;
				if (ALLOWED_METHODS.contains(method {
					requestToUse = new HttpMethodRequestWrapper(request, method;
				}
			}
		}

		filterChain.doFilter(requestToUse, response;
	}

分析以上源码可以发现，有且只有一种可能，就是request.getParameter可能是解决问题的是关键。

8.大胆猜测

getParameter，所以顺序调整为A->M后，相当于间接使用了HiddenHttpMethodFilter。

9.开始验证

M执行前调用了request.getParameter，理论上可以正常为使用。所以在debug情况下

M过滤器调用前先行执行request.getParameter，发现的确可以正常使用。

10.分析过滤器

通过request.getParameter获取的数据，重写后的代码：

public String getParameter(String name {
		if ( this.parameterMap.containsKey(name 
			return this.parameterMap.get(name;
		else {
			return super.getParameter(name;
		}
	}

在经过request包装后，先是从paremeterMap中获取数据，此时map肯定是没有数据，只能从父类获取，而父类获取时会解析parameter，解析时使用到了inputStream，但M过滤器

而如果在调用M前调用了request.getParameter，tomcat内部将提前于M解析parameter，可以保证后续可获取到相关参数。

4. 修复方案

启用HiddenHttpMethodFilter，添加对应的参数，保证升级前后过滤器个数与顺序一致

A与M的顺序，保证M在A之前执行即可。
M内部的逻辑，不在初始化的时候解析body，或是在解析body后将参数重新放置到parameterMap中。

此文是笔者按照分析流程进行简单验证，分析验证过程中难免有遗漏之处，如有错误遗漏还烦请各位指出共同进步。

编程笔记 » springboot升级过程中踩坑定位分析记录 | 京东云技术团队