背景
某url性能测试表明，qps单机最高只有4000多，虽然靠堆机器可以解决问题，但是显然不是什么优雅的方案。
试着把controller里的所有的逻辑都屏蔽，只是简单的返回hello world，发现并没有什么用，略略提高了一点，但还是不到5000。显然是什么地方有个坑。
问题查找过程略去不表，坑有两个：
- 用了log4j，1.x的版本，这货的性能。。。嗯，不说了，都是泪
- spring url mapping也有点坑，在开trace日志的前提下（要知道此时是log也消耗性能），大概消耗了30%的性能。
google & 代码分析
google来google去，看了看spring的源代码，4.2.x。发现这篇文章写的不错。基本说明白了问题。
spring url
盗一张图来描述一下，spring处理url的过程
解释一下什么叫 完全匹配呢？
@RequestMapping(path = "/list/cityId/123", method = RequestMethod.GET) 是完全匹配
@RequestMapping(path = "/list/cityId/{cityId}", method = RequestMethod.GET) 不是完全匹配
看出问题来了吗？
如果path不是一个完全匹配的url，那么就需要遍历所有的path，依次做正则匹配。这个。。。不慢也没有道理吧。慢也就算了，随着一个项目里的url越来越多，那么匹配速度就会越来越慢。。。。
达达的方案
服务端：
1. 在每个@RequestMapping中添加接口对应服务名的信息。
2. 实现自己定义的HandlerMethod查询逻辑，在HandlerMethod注册时记录与之对应的服务名，在查询时通过HTTP请求头中的服务名查表获得HandlerMethod。
客户端：
1. 调用服务时将服务名加入到HTTP请求头中
分析：
* 这样的查询时间复杂度是O(1)的，典型的空间换时间。理论上使用这样的查找逻辑的效率和非RESTful接口的效率是一样的。
* 由于HandlerMethod的注册是在服务启动阶段完成的，且在运行时不会发生改变，所以不用考虑注册的效率以及并发问题。
* SpringMVC提供了一系列的方法可以让我们替换它的组件，所以该方案的可行性很高。
改进
这样做的话，虽然可以解决问题，但是客户端需要配合做修改，不是一个优雅的方案。
实际上，在一个具体的项目中，一般来说path参数一般也就是两种，int和string，比如
/city/id/{id:[\d]+}
/city/shared/{sharedStr:.*}
实际上，上面的path，可以用正则表达式：
@RequestMapping(path = "/list/cityId/{cityId}", method = RequestMethod.GET)
也就是说上面的path pattern可以表示成$ /city/id/{variable} $ 的形式。
那么一个用户的url请求呢？ 比如/city/id/123？那就更简单了，/\d{2, }即可。也可以表示成$ /city/id/{variable} $ 的形式。
即用户的请求这可以映射到VariableLikeUrl，通过VariableLikeUrl可以直接找到具体的处理函数。
public class OwnUrlMapping extends RequestMappingHandlerMapping {
private static final Pattern VARIABLE_PATTERN = Pattern.compile("/\\{[^/]+:[^/]+\\}");
protected Map<String, Pair<RequestMappingInfo, HandlerMethod>> url2method;
@Override
protected void handlerMethodsInitialized(Map<RequestMappingInfo, HandlerMethod> handlerMethods) {
url2method = new HashMap<>();
handlerMethods.forEach((info, method) -> {
Info2key(info).forEach(s -> {
RequestMappingInfo to variable like url
s = VariableLikeUrl
if (url2method.containsKey(s)) {
throw new IllegalStateException(
"Ambiguous mapping. " + s + " --> " +
method + " alread " + url2method.get(s));
}
url2method.put(s, new Pair<>(info, method));
}
);
});
}
@Override
protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
request to variableLikeUrl
String url = request2case(request.getRequestURI()) + ":" + request.getMethod();
Pair<RequestMappingInfo, HandlerMethod> method = url2method.get(url);
if (method != null) {
// If find it, call it directly
handleMatch(method.getFirst(), lookupPath, request);
return method.getSecond();
} else {
// Could not find, call super matching method
LOG.warn("no matching for " + url);
return super.lookupHandlerMethod(lookupPath, request);
}
}
}
总结
好处
- 性能可以得到有效的提升。
- 客户端完全没有修改
- 服务器controller的代码也不需要什么修改。
问题
- 项目by项目，如果出现不按格式写的url，就废了。。。
- 实际上spring考虑的东西还是比较多的，处理url，method 貌似还有很多别的东东，上述方法。
- 和spring的版本绑定，反正4.x版本都适用。
基本上为项目定制了一个url mapping规则，不能替代spring原有的mapping函数，但是依然有推广意义。毕竟没有几个项目把RequstMapping的所有参数都用全了不是。