背景
昨天功能上线之后，没多久，业务就反馈一个高频页面响应明显慢了很多。立马打开页面查看，发现果然如此，发现一个分页查询接口响应速度竟然要6-7s，于是立马展开了排查。
排查思路
为了避免业务大范围受影响，第一时间会滚了部署的代码。然后到测试环境查看，发现测试环境没有这个问题。于是想到肯定跟数据量级有关系，生产环境高达百万级，而测试环境只有不到一百条。于是立马检查本次改动的代码，好在改动不大，第一时间查到了问题所在。原来是在拼装一个查询条件时，在某些情况下，会导致查全表，于是立马进行了改动，准备发布。
正在此时，领导稳了一波，这是一个很典型的问题，排查接口响应速度慢，可以单独部署一个pod并配置对应的路由，指定特定策略，来使用这个pod访问生产环境，又不影响生产环境业务的正常使用。
说干就干
我们生产环境采用的k8s部署，注册配置中心、路由网关采用阿里云mse，那大致有一些思路了
- 使用yaml单独部署问题镜像的pod，部署时环境
spring.cloud.nacos.discovery.metadata中指定一个参数stage，值自定义=test-arvin - 检查mse注册配置中心服务是否注册成功
- 配置自定义的网关路由，例如前缀匹配
/test/arvin，后面添加自己的业务前缀 - 在部署的pod中安装并启动arthas
- 使用trace命令追踪指定的方法
- 使用postman访问指定接口
- 观察pod中的日志打印
这了可以看到，第一列显示的百分比就知道，具体哪个方法调用在耗时了，第二列是具体耗时，第三列是哪个类的哪个方法，而最后一列，也可以明显看出，具体的行数
解决
最后在修改代码之后，发布生产验证确定没有复现，大功告成
总结
排查方式有很多种，这只是其中一种，也欢迎大家介绍点更方便的排查方式。以前用过skywalking，但需要搭建相应服务，感觉比较麻烦，而且公司也不一定愿意给出对应资源来。
