用了一个很蠢的方法定位服务不可用原因
概述
哎，最近的一次上线，业务功能点很少，本以为稳稳的，肯定没事，谁知晚上十点半刚上完线，服务突然自动重启了，运维人员认为风险极高，回滚了。运维这么一快速回滚，没有dump出堆栈信息，研发这边定位问题会麻烦一些。下面将定位问题的整个过程简单重现一下。
定位过程
公司用的是spring cloud+k8s体系，会使用到存活探针，探测失败的话，会重启pod，当时通过阿里的arms，发现了full gc次数非常多，导致服务都无法响应了。因此想跟运维要一份gc日志和core jump文件，分析一把，但是都拿不到，因为java进程启动脚本里都没加这两个的配置，醉了。由于当时已经非常晚了，上线的功能也不是特别重要，就跟产品经理沟通了一下，业务需求延期上线。
当时的思路是，既然没有很好的上下文信息，不太好定位原因，那就使用排除法，找一个晚上，把当时上线的几个小功能点，一个一个挨着上，每上一个就观察服务器和gc情况，当上完倒数第二个功能点还是没出问题，我们就基本锁定是最后一个业务功能点的代码出问题了，那是一个简单的订单查询功能改造，如果真是这个功能点有问题，那么我们只需要在后台点击几次订单查询操作，应该就能复现了。果然，上完这个功能点后，才点击了三次订单查询，服务就开始重启了，full gc次数开始多了。
最后仔细的看了代码，发现是订单查询的统计功能中，没有加上新增的查询过滤条件，导致整表查询了，一下子从数据库里加载了几十万条数据，导致内存一下子满了。这里要吐槽一下，当时从腾讯云的慢sql日志里，没看到有慢sql。
解决方式很简单，统计的方式里，带上查询条件即可。
小结
办法虽然笨，但是至少找到了问题了，如果你也遇到过类似的问题，又毫无头绪，可以尝试使用排除法，重现线上问题，然后对症下药。