利⽤SkyWalking优化性能实例
APM⼯具由之前的pinpoint切换为sw了，主要还是开发者是国内的，交流起来⽐较⽅便，并且社区也⽐较活跃。少说废话，下⾯直接开始。
微服务在哪里
切换sw后，发现某个实例性能不太好
image.png
1、复制⼀下慢接⼝的接⼝名称，到追踪⾥⾯查询慢接⼝的情况
image.png
在这⾥可以清楚看到基本上都需要好⼏秒，每次请求。在这个接⼝⾥⾯，做了好⼏次数据库的查询，其中第⼀次查询就3秒以上，⽤explain SQL 语句，看看执⾏计划，发现了问题
image.png
QQ20200720-005256.png
在这⾥，我们可以看到某个服务基本上都是需要5秒以上（ ），这类请求会拖慢全站，关键的时候会导致雪崩效应，使得连接数爆了，所以这类服务必须消灭。
我们打开追踪的界⾯，看具体的连接情况
01725E64-46F0-49CA-8639-F1361CEACDA8.png
发现这⾥⼀共跨了2个应⽤，⾥⾯包含了51个事情（我的天呀，⼀个⼜长⼜臭的事务），紫⾊的是接⼝的⼊⼝⽹关层，我们可以看到⽹关⼤概是消耗3ms左右，剩下的5秒都是到具体的应⽤消耗的，⽹关层⾯上没有任何问题。⽽在业务应⽤层，可以看到51个事情基本上都是在做redis的处理，get，set和expire，⽽这些操作基本上都是1ms不到，redis层⾯是没有问题的（暂时不管set和expire的不合理问题，起码性能是好的），我们再观察⼀下右边的图形，你发现了啥？
image.png
哈哈，就是这⾥了，你发现在做完redis的⼀个get后，到下⼀个redis的操作set之间，差不多⽤了5秒，中间⼤量的真空。
打开具体的操作，看看是在获取哪个key⾥⾯的内容，⽅便查问题
image.png
根据这个key，到具体的代码，发现获取到内容后，⾥⾯有⼀个for循环去调⽤外部服务（汗ing）导致耗时过长，接下来就是具体的逻辑优化了，因为这⾥主要是讲如何利⽤⼯具跨应⽤去全链路分析具体问题在哪⾥。这⾥只是举例，只涉及到⽹关和⼀个业务应⽤，实际中会有跨多个应⽤的调⽤，主要都接⼊了skywalking，就可以⽤这个⽅法快速定位到是具体哪个应⽤，哪个逻辑慢或者出问题了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。