接口访问速度突然变慢，怎么排查

现在大多数的业务都微服务化了，可能一个请求需要调用好几个甚至几十个ms才能拿到最终的结果，但是如果一旦中间某个servcie出现了问题，影响的将会是整条调用链路，就比如某个ms突然变的很慢，那么整个请求也会跟着一起变慢，怎么排查这个问题，然后怎么解决？

首先，使用现有的链路追踪器（比如现在比较流行的zipkin）查看在整个调用链路中，是哪个接口耗时时间过长，那么可能的原因有以下几点：

        1. 是否线程池配置的参数有问题，比如核心线程数，或者最大线程数是否合理

        2. 还是线程池，是否有多个业务共用一个线程池的场景，建议在资源允许的情况下，每个业务场景配置自己的线程池，一个是比较灵活，可以根据实际业务场景配置线程池的参数，防止配置过少或过多；二是防止某个业务场景访问量突然升高导致线程池阻塞影响其他业务的访问

        3. 是否有线程死锁

        4. 是否有大对象的频繁的深拷贝，比如for循环里对大对象深拷贝，会影响性能，还有就是有一些大对象的创建，可能会引起频繁的full GC

        5. 是否有频繁的hashmap扩容，或者其他集合类的频繁扩容

        6. 是否有使用本地缓存，比如caffeine等，当然没有使用本地缓存导致变慢可能不是当前接口的问题，有可能是下游接口变慢，但是如果当前接口使用了本地缓存，也可以不用直接调用下游接口，就可以减少一次调用提升性能

        8. 是否正确配置了数据库连接池的大小

        9. 接口是否有使用缓存，比如redis缓存

        10. 机器的cpu和内存是否打爆了

        11. 请求是否被合理的分发，比如之前使用的负载均衡模式是权重的模式，分配的依据是网络速度，但是现在这个权重大的机器网络速度突然变慢，但是大量的请求又都到这个机器上

        12. 类似11点，检查网络速度

        13. sql是否使用到了索引，或者是否正确的使用了索引

        14. 在使用锁或者synchronized的时候，是否同步的力度太大        

        15. 是否有内存泄漏或者内存溢出导致频繁的full GC

        16. tomcat连接数配置是否合理