前言之前写了一篇记录生产环境事故的文章，获得了很多好评。后续我们团队进行了一些讨论。为了支持运维，我们搭建了一个更好的日志平台Granfa+Loki，同时也引入了SkyWalking进行链路追踪。但是我在这个过程中也遇到了一些问题，我会在下面描述，然后分享这个简单的技巧，希望能帮助到大家。如果暂时没时间看，可以先收藏起来，有空再慢慢看。如果以后遇到类似的情况，或许可以直接复制。
困难如前所述，我们团队搭建了日志平台和链接跟踪，但实际上也带来了一些困难，具体如下：1）对于中小企业来说，搭建这样的平台有一个对资源有一定的影响。Requirements（需要钱），项目维护期经常出现资源紧张，增加维护成本，因为成本不是你控制的，而是老板控制的；2）对于团队成员来说，要有一定的能力熟悉和使用这样的平台，掌握一些常用的命令，而且中小企业人员流动比较频繁，不是每个入职的成员都能上手，无形中增加了人工成本；3）、在线排查问题的过程其中，方便很多，但也麻烦很多。方便是因为有平台可以直接定位。麻烦是因为平台越来越多。有些成员因为地址太多而感到头晕（笑）。综上所述，考虑到我们公司的规模和经济能力，我们团队最终决定用最简单的方法来定位接口耗时问题，即SpringAOP做一个第三方接口的aspect来完成耗时统计。
效果先展示最终的在线效果，让大家一目了然。我们的项目使用微服务+K8s。下图是Granfa+Loki搭建的收集k8s日志的平台。通过关键字搜索可以直接定位到调用第三方接口耗时的情况。
模拟场景下面模拟一下场景，实现AOP方面第三方接口的耗时统计。1、模拟用户文件构建实体类，用map模拟存储用户、获取用户、删除用户。2.这里模拟第三方接口就是简单的用threadsleep来模拟调用第三方接口的耗时，假装几个接口分别耗了那么多时间。3.Service服务4.Controller服务5.测试接口OK，没问题。6、AOP切面引入依赖，编写切面类。这里简单解释一下，把要点说清楚。1）、Pointcut切面应该指向第三方接口调用的类，即本场景中的RemoteClient；2)、使用环绕切面，其中方法名是关键字，用于在线检索日志定位；3）、计时直接使用StopWatch即可，避免引入其他依赖；4）、StopWatch的start和stop方法包裹的jointPoint.proceed()是第三方接口的执行操作，让StopWatch可以统计这个方法的耗时；5)、最后打印日志也很重要。你可以参考我打印出类名。方法()供以后检索。同时耗时最好用ms为单位，这样一目了然。七、效果我们在模拟场景中手动执行几个接口后，观察日志打印情况。可以看到方法对应的耗时已经统计了。这样最终的k8s日志就会这样被日志平台收集起来，我们最终只需要通过关键词检索就可以一次定位到所有第三方接口的耗时情况。最后给大家展示一下我们生产环境中第三方接口的超时日志。正是这样的统计，帮助我们定位了其他厂商的接口问题。以前，他们总是谈论我们的问题。这张截图让他们低头认罪，然后他们就解决了这个问题。这是我们在Granfa中直接根据类名和方法名定位第三方接口的命令。这是他们统计的一段时间内接口超时的统计，也是最后发给他们的证据。
总结最后再总结一下这种方法的好处，和我公司有类似情况的同事可以参考一下。1）节省维护成本，不需要额外搭建中间件或基础设施进行链路跟踪等定位。许多中小企业不使用它。一般用于通过日志定位问题。一个链接追踪平台搭建起来很简单，但是我们明显发现在使用过程中会造成资源限制，需要定期维护。这笔费用会随着时间的推移逐渐增加；2）团队成员不需要学习额外的技能，尤其是这种在快节奏的互联网行业团队中，人员变动频繁。每次培训和指导都是一项劳动密集型工作。往往一个人掌握后不久就跳槽，需要公司从头再来；3）、平台复杂不是好事，光是环境地址就能积累几个Excel，小规模的团队还是倾向于用最简单的方式处理问题。综合考虑，人力完全可以替代平台（老板其实就是喜欢这种员工）。另外再说一点，这种方法既可以应用于单体架构，也可以应用于分布式架构，但是要注意分布式架构，第三方服务应该是独立的，这样才能完美的使用AOP方面。已配置，否则需要重新导入各个服务。
附言源码会在评论区分享。有兴趣的可以自己下载试试。还有我整理的logback配置，包括colorlog配置，以及每个配置的详细注释。AOP部分代码是网上跑了大半年的代码，直接拿来用。你只需要修改你的方面指向和类名和方法名的日志打印。
原创文章纯手打，一篇一篇打出来，键盘满血，如果觉得有帮助，请点赞加收藏~我致力于分享我的工作心得和趣事，喜欢的话可以进入首页关注哦~更多最新技术文章请关注GZH：【Java分享客栈】
