作者：京東零售?李文龍
1.背景
“ 俗話說：為了修復一個小bug而引入了一個更大bug ”
因所負責的系統(tǒng)使用的spring框架版本5.1.5.RELEASE在線上出過一個偶發(fā)的小事故，最后定位為spring-context中的一個bug導致的。
為了修復此bug進行了spring版本的升級，最終定的版本為收銀臺團隊使用的版本5.2.12.RELEASE，對應的springboot版本為2.2.12.RELEASE。
選擇這個版本的原因是：
1.有團隊經(jīng)過了長時間的線上驗證
2.修復了5.1.5.RELEASE對應的bug
2.升級上線
升級相關版本后在預發(fā)環(huán)境進行了驗證，暫未遇到關于框架的問題。本以為安全升級完成，在上線過程中發(fā)現(xiàn)在APP中無法訪問，此時還未掛載流量。
日志中分析是某些參數(shù)未解析到，后在nginx日志中查到相關請求，使用postman模擬請求可以正常使用。
3.分析驗證定位原因
1.臨時修復
在代碼一致的情況下，唯一的可能就只能是線上與預發(fā)配置不同，經(jīng)對比分析得出是某個過濾器的順序在線上未配置，按照預發(fā)的配置后可正常使用。我們暫且稱修改的這兩個過濾器為M和A,
其中默認情況下執(zhí)行順序為M->A，順序修改為A->M后正常，其兩者作用大致為：
M : 通用過濾器，解析url中的參數(shù)至parameterMap中，并初始化讀取了body中的inputstream進行了byte數(shù)組的緩存，用于解決重復讀取流問題 A: 特定處理器，先是查詢parameter中的參數(shù)，然后邏輯處理后再設置一些特殊參數(shù)。
2.為何需要改過濾器順序
經(jīng)查未升級前過濾器的順序與升級后過濾器順序一致，為何升級spring框架后需要修改配置。此時猜測可能是spring在升級過程中修改了一部分代碼，
但未有頭緒，只能先調(diào)轉(zhuǎn)方向分析為什么postman和瀏覽器中的swagger可以正常使用
3.分析nginx日志
前端請求與postman請求的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=
經(jīng)過以上對比發(fā)現(xiàn)雖然postman使用了post請求，但數(shù)據(jù)還是放置在url中，在經(jīng)過系統(tǒng)的一個內(nèi)置過濾器M時將url中的參數(shù)解析到了parameterMap中，后續(xù)過濾器可以使用
request.getParameter獲取到，注意此方法是解決問題的關鍵，此時還未意識到。
4.升級前后框架是否有大的修改
因升級的版本是升級了一個小版本號，所以不好對比升級的buglist，只能慢慢進行分析，后在分析過濾器時發(fā)現(xiàn)升級spring后過濾器個數(shù)由11個減少到了10個，減少了那一個為：
org.springframework.web.filter.HiddenHttpMethodFilter
此過慮器的作用是在瀏覽器不支持PUT、DELETE、PATCH等method時，可以在form表單中使用隱藏的_method參數(shù)支持這幾種method。好像跟參數(shù)解析沒有任何關系，
繼續(xù)分析升級版本中 （由2.1.3.RELEASE->2.2.12.RELEASE）是否修改了此過濾器的一些內(nèi)容，后在2.2.0.M5的release notes中發(fā)現(xiàn)HiddenHttpMethodFilter相關的：
“ Disable auto-configuration of HiddenHttpMethodFilter by default ” github上對應的版本release notes： https://github.com/spring-projects/spring-boot/releases/tag/v2.2.0.M5
也就是說升級后HiddenHttpMethodFilter默認配置由enable修改為了disable，如果再修改回去是不是可以修復參數(shù)解析的問題呢？
5.添加過濾器enable配置
因bug修復列表中有對應的issues，所以找到了此過濾器對應的配置：
-Dspring.mvc.hiddenmethod.filter.enabled=true
添加后可以正常使用，證明是此過濾器中在某種條件下不可缺少。
6.未升級spring版本時disable驗證
在確認未升級版本的spring支持此參數(shù)的情況下，添加了以上參數(shù)，將默認的啟動修改成了禁用，經(jīng)驗證：在不代碼修改的情況下，無此過濾器時參數(shù)無法解析。證明了上步的猜測。
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);
}
分析以上源碼可以發(fā)現(xiàn)，有且只有一種可能，就是request.getParameter可能是解決問題的是關鍵。
8.大膽猜測
分析后源碼猜測，第一步中的修改順序有可能是A中有調(diào)用getParameter，所以順序調(diào)整為A->M后，相當于間接使用了HiddenHttpMethodFilter。
9.開始驗證
在不使用HiddenHttpMethodFilter的情況下，如果在過濾器原有順序不修改的情況下，只要在M執(zhí)行前調(diào)用了request.getParameter，理論上可以正常為使用。所以在debug情況下
利用工具在M過濾器調(diào)用前先行執(zhí)行request.getParameter，發(fā)現(xiàn)的確可以正常使用。
10.分析過濾器
先前簡述了M的功能，主要是包裝了request，后讀源碼時發(fā)現(xiàn)，如果是post請求，讀取body體中的數(shù)據(jù)后并未解析body中的參數(shù)至parameterMap中，而代碼中的其它過濾器都是
通過request.getParameter獲取的數(shù)據(jù)，重寫后的代碼：
public String getParameter(String name) {
if ( this.parameterMap.containsKey(name) )
return this.parameterMap.get(name);
else {
return super.getParameter(name);
}
}
在經(jīng)過request包裝后，先是從paremeterMap中獲取數(shù)據(jù)，此時map肯定是沒有數(shù)據(jù)，只能從父類獲取，而父類獲取時會解析parameter，解析時使用到了inputStream，但M過濾器
的在初始化時解析了輸入流，此時tomcat內(nèi)部使用內(nèi)部的request獲取stream時將獲取到空數(shù)據(jù)，即無法從parameter中獲取到body體中的數(shù)據(jù)。
而如果在調(diào)用M前調(diào)用了request.getParameter，tomcat內(nèi)部將提前于M解析parameter，可以保證后續(xù)可獲取到相關參數(shù)。
4. 修復方案
既然得出了結(jié)論，那么升級spring版本后修復此bug可選擇的方案就比較多了，主要有：
-
啟用HiddenHttpMethodFilter，添加對應的參數(shù)，保證升級前后過濾器個數(shù)與順序一致
-
調(diào)整理過濾器A與M的順序，保證M在A之前執(zhí)行即可。
-
修改過濾器M內(nèi)部的邏輯，不在初始化的時候解析body，或是在解析body后將參數(shù)重新放置到parameterMap中。文章來源：http://www.zghlxwxcb.cn/news/detail-428020.html
此文是筆者按照分析流程進行簡單驗證，分析驗證過程中難免有遺漏之處，如有錯誤遺漏還煩請各位指出共同進步。文章來源地址http://www.zghlxwxcb.cn/news/detail-428020.html
到了這里，關于springboot升級過程中踩坑定位分析記錄 | 京東云技術團隊的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
