SpringMVC 性能優化（不使用@pathvariable註解）

背景

達達後臺系統目前每天都要支撐數十億的訪問量，這對於服務系統整體架構是個嚴峻的考驗。考慮到越來越複雜的業務以及不斷增加的訪問壓力，我們對數據層進行了一系列的改造（參見達達-高性能服務端優化之路），也對業務層進行了服務化（參見基於Zookeeper的服務註冊與發現）。同時，參照DDD設計，我們引入了一個數據訪問層，即ModelService。

ModelService的職責：

• 封裝業務層對數據層的調用

• 實現對數據庫的分庫分表（寫入以及查詢）

• 實現對部分數據的緩存

ModelService以及我們目前大部分系統提供的對外接口都是RESTful風格。

使用RESTful風格的接口有如下優勢：

• 語言無關（這點對於我們Python＋Java的後臺系統很關鍵）

• 開發效率高、調試方便

• 接口的語義明確 <!-- more --> 然而缺點也顯而易見：基於HTTP的RPC在效率上不如傳統的RPC。 在ModelService中，我們使用SpringMVC框架來實現RESTful接口。但是，在最近一次對ModelService的更新中我們發現SpringMVC的RESTful接口性能存在問題。

---

RESTful：

@RequestMapping(path = "/list/cityId/{cityId}", method = RequestMethod.GET)
@ResponseBody
public String getJsonByCityId(@PathVariable Integer cityId)

客戶端請求： GET /list/cityId/1

非RESTful：

@RequestMapping(path = "/list/cityId", method = RequestMethod.GET)
@ResponseBody
public String getJsonByCityId(@RequestParam Integer cityId)

客戶端請求： GET /list/cityId?cityId=1

---

我們使用Apache JMeter對SpringMVC RESTful接口與非RESTful接口進行了性能測試：

RESTful接口： 

非RESTful接口： 

＊併發量爲200 ＊測試在同一臺機器上進行，執行業務邏輯相同，僅接口不同。 ＊爲了證明的確是SpringMVC造成的問題，我們使用了最簡單的業務邏輯，直接返回字符串。

由結果可見，非RESTful接口的性能是RESTful接口的兩倍，且請求的最大響應時間是35毫秒，有99%的請求在20毫秒內完成。相比之下，RESTful接口的最大響應時間是436毫秒。

由於ModelService是一個對併發性能要求極高的系統，且被多個上層業務系統所依賴，所有請求需在50ms內返回，若超時則會引起上層系統的read timeout，進而導致502。所以需要對這一情況進行優化。

---

方案一：將所有的url修改爲非RESTful風格（不使用@PathVariable）

這是最直接的方式，也是最能保證效果的方式。但是這麼做需要修改的是ModelService中已有的全部100+個接口，同時也要修改客戶端相應的調用。修改量太大，而且極有可能由於寫錯URL導致404。更令人不爽的是這種修改會導致接口沒有了RESTful風格。故該方案只能作爲備選。

---

方案二：對SpringMVC進行改造

根據實際現象以及測試的結果，幾乎可以確定的是問題出在SpringMVC的RESTful路徑查找中。所以我們對SpringMVC中的相關代碼進行了調查。

SpringMVC的請求處理過程中的路徑匹配過程：

org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#lookupHandlerMethod
(spring-webmvc-4.2.3.RELEASE) 

路徑匹配的過程中有如下代碼：

List<Match> matches = new ArrayList<Match>();
List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
if (directPathMatches != null) {
   addMatchingMappings(directPathMatches, matches, request);
}
if (matches.isEmpty()) {
   // No choice but to go through all mappings...
   addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
}

SpringMVC首先對HTTP請求中的path與已註冊的RequestMappingInfo（經解析的@RequestMapping）中的path進行一個完全匹配來查找對應的HandlerMethod，即處理該請求的方法，這個匹配就是一個Map#get方法。若找不到則會遍歷所有的RequestMappingInfo進行查找。這個查找是不會提前停止的，直到遍歷完全部的RequestMappingInfo。

public RequestMappingInfo getMatchingCondition(HttpServletRequest request) {
    RequestMethodsRequestCondition methods = this.methodsCondition.getMatchingCondition(request);
    ParamsRequestCondition params = this.paramsCondition.getMatchingCondition(request);
    HeadersRequestCondition headers = this.headersCondition.getMatchingCondition(request);
    ConsumesRequestCondition consumes = this.consumesCondition.getMatchingCondition(request);
    ProducesRequestCondition produces = this.producesCondition.getMatchingCondition(request);