别再背锅了，这个小技巧统计第三方接口耗时很安逸

news2025/1/15 18:15:06

前言

之前我有写过一篇记录生产环境事故的文章，获得了不少好评。

后续，我们团队有做过一些讨论，为了支撑运营维护，搭建了更好的日志平台Granfa+Loki，也引入了SkyWalking做链路追踪。

但过程中也遇到了一些问题，我会在下面讲述出来，然后将这个简单的小技巧分享出来，希望对大家有所帮助。

如果暂时没时间看，可以先收藏起来，等闲下来慢慢看，以后如果遇到类似的情况说不定能直接翻出来照搬。

困难

前面说了，我们团队有搭建日志平台和链路追踪，但实际上也带来一些困难，大体如下：

1）、对于中小企业来说，这样的平台搭建起来对资源有一定要求(要钱)，项目维护期也经常会出现资源紧张的情况，增加了维护成本，因为成本不是控制在你手上，是老板手上；

2）、对于团队成员来说，要有一定能力熟悉和使用这样的平台，掌握一些常用的命令，而中小企业人员流动还挺频繁，并不是每个入职的成员都能上手，这无形中加大了人力成本；

3）、在线上排查问题过程中，方便了许多，但也麻烦了许多，方便是因为有平台能直接定位了，麻烦是因为平台越来越多，有成员反应地址太多有点晕了(笑)。

综上所述，考虑到我们公司的规模和经济能力，最终我们团队还是决定用最简单的办法来定位接口耗时的问题，也就是SpringAOP对第三方接口做切面来完成耗时统计。

效果

先把最终在线上呈现的效果展示出来，大家能一目了然。

我们项目使用的是微服务+K8s，下图是Granfa+Loki搭建的收集k8s日志的平台，通过关键字进行搜索就能直接定位到调用第三方接口耗时的情况。

模拟场景

我们来模拟一下场景，实现AOP切面统计第三方接口的耗时。

1、模拟用户建档

实体类

用map来模拟存放用户、获取用户、删除用户。

2、模拟第三方接口

这里就是简单的用线程睡眠来模拟调用第三方接口的耗时，假装几个接口分别耗费了这么多时间。

3、service服务

4、controller服务

5、测试一下接口

接口1.jpg

接口2.jpg

接口3.jpg

OK，没有问题。

6、AOP切面

引入依赖

编写切面类，这里简单说明一下，主要明确几点。

1）、Pointcut切面要指向第三方接口调用的类，也就是本篇场景中的RemoteClient；

2）、使用环绕切面，其中方法名是之后线上检索日志定位的关键字；

3）、计时直接使用StopWatch即可，省得引入其他依赖；

4）、StopWatch的start和stop方法包裹的jointPoint.proceed()就是第三方接口的执行操作，这样StopWatch就可以统计出该方法的耗时；

5）、最后打印日志也挺重要，可以参考我这样，把类名.方法()都打印出来便于以后检索，同时耗时最好用ms单位，这样一目了然。

7、效果

我们手动执行模拟场景中的几个接口后，来观察日志打印的情况。

可以看到，方法对应的耗时都统计出来了。

这样，最终k8s的日志也会像这样被日志平台收集起来，我们最终只需要通过关键字检索就能一次定位到所有第三方接口的耗时情况。

最后，我把我们某一次生产环境定位到的第三方接口超时的日志展示出来给大家看看，正是这样的统计帮助我们定位到了其他厂家的接口问题，之前他们一直都是说我们的问题，靠这个截图才让他们低头认罪，之后他们就修复了这个问题。

这是在Granfa中我们根据类名.方法名直接定位第三方接口的命令

这是检索到的某一段时间内他们接口一直超时的统计，也是最后发给他们的证据。

总结

最后，我把这种方式的好处再总结一遍，如果和我所在公司情况类似的同行可以参考下。

1）、节约了维护成本，不需要额外搭建什么链路追踪等用来定位的中间件或基础设施，很多中小企业其实用不上，大体还是习惯通过日志来定位问题，一个链路追踪的平台搭建简单，但是使用过程中我们明显发现会造成资源紧张，也要进行定期的维护，这个成本会在日积月累中逐渐变多；

2）、团队成员不需要再额外学习多余的技能，尤其是这种快节奏的互联网行业团队，人员变更挺频繁，每次都要培训和指导是一件比较耗费心力的事情，往往一个人掌握了没多久他又跳槽了，对于公司而言又要重来；

3）、平台变复杂不是好事，光是环境地址就能积累几个Excel，规模不大的团队还是倾向于最简单的方式来处理问题，综合考虑之下，人力完全可以替代平台（老板们其实就喜欢这样的员工）。

另外稍微提一点，这种方式既可以应用于单体架构，也可以应用于分布式架构，但对于分布式架构要注意一点，第三方服务最好能独立出来，这样你使用AOP切面就完美适配了，否则你需要每个服务都引入一遍。