SkyWalking 拓扑功能的性能优化

不念不忘少年蓝@ 2023-10-03 22:57 6阅读 0赞

### 一、背景 ###

#### 1.1 前文 ####

溯源：Boss Li 提出部门的基础设施引入Skywalking, 于是踏上全链路监控之旅。。。其他暂略。。。

#### 1.2 现状简述 ####

一期规划，司内200多核心应用接入SkyWalking，伴随着接入的进行，主IDC一个多月内每天的segment在10亿以下，整个系统运行的也比较稳定；随着网关、基础资料等几十个大流量应用的接入，segment总量快速上升到25亿左右，自此噩梦来袭，服务端的各种稳定性、性能问题接踵而至，压力和优化的动力也相伴而生。

当时问题爆发的集中且突然，受资源、资料、精力多方面制约，选择了“弃车保帅”的策略：全方位功能降级，集中优化trace功能，把拓扑等功能隐藏起来，如此取舍的原因是：

1.  Trace的价值是引入Skywalking的主要原因，必须作为首要攻坚目标。
2.  应用尚未全面接入，拓扑功能还无法体现出其全视角的C位价值。

而最近SA同学刚好聊到一些大盘看板的需求，加上SkyWalking的其他优化也早已完成，抽点时间把拓扑功能优化一下。

### 二、目标 ###

对Trace查询做优化时，在保留60天记录的情况下，将基于traceId的查询从30秒优化到了1秒内，所以拓扑查询的目标自然也要优化到**毫秒级别**。

### 三、思路 ###

基于对skywalking的掌握和之前优化的经验，快速梳理出一些优化项。

#### 3.1 程序侧 ####

1.  增加查询的并行度，减少串行耗时。
2.  规避无效查询的触发，避免带来额外消耗。
3.  提升分片检索的命中，缩小检索分片数

#### 3.2 ES存储侧 ####

1.  从ES日志中定位耗时逻辑，作为重点优化分析项
2.  增加分片数，减少分片大小
3.  增加机器，减少但个机器上承载的分片数量

### 四、措施与效果 ###

#### 4.1 问题定位 ####

**问题定位-接口：** 拓扑页现实会有两个请求调用：

1.  `queryServiceTopo` 耗时在300ms内(整体优化未开始的时候，这个接口也超慢，现在其速度在毫秒级得益于早期其他的优化）
2.  `queryTopoInfo` 耗时在1min以上（限定了60s的超时）；切换任意一个service这个接口都超时。

**问题定位-ES日志：** 部门的科科老师是ES专家，经过之前协同攻坚优化skywalking后，已然是老战友了，这次把思路简单沟通后，科科便开始从ES日志中找线索。多次尝试后，日志中未检测到耗时语句，两人默契的会心一笑，因为不是存储层的问题，那就可以优先从OAP程序中找逻辑的问题，而这边逻辑的问题，相对ES会更容易解决一些。

#### 4.2 梳理接口代码 ####

因为已经确定了`queryTopoInfo`调用会超时，从其接口实现梳理，调试定位源码过程比较繁杂，咱们忽略直接从结论说起，此接口实现中后边会多次调用`MetricQuery#getValues`方法，逻辑简单总结即为双层循环：

![format_png][]

1.  外层循环为：遍历多个metric ,如`service_cpm`、`service_resp_time`、`service_sla`，每个metric 执行一次`MetricQuery#getValues`
2.  内层循环为：遍历每个metric中的id列表，对每个id执行一次`MetricsQuery#readMetricsValue`

通过分析http请求的数据可知，这个id列表可能是成百上千个；并通过一次模拟确认了此处的确耗时

#### 4.3 改造 ####

确定此处双循环逻辑的耗时后，首先考虑内、外层循环如何调整，外层循环次数不可减少（可考虑并行），内层循环可以考虑把多次变少次，也可考虑并行；这个过程咱们跳过直接从结论说出:

![format_png 1][]

原逻辑是每个id查询，最终进入图中所示的terms方法，但只传入了1个参数，而terms可以传入数组,即多个参数，于是尝试开辟另外一个执行链路，将第二层循环里的id数组传入到这个terms中。

#### 4.4 效果 ####

为了对比新老逻辑的差异，并留个后路达到快速回滚，代码中专门增加走新老逻辑的开关，执行4次请求看效果：

![format_png 2][]

上图4次请求中，第二次的请求是原始逻辑，1分钟后超时，而其他三次是执行优化后的逻辑，耗时都是毫秒级的；从分钟级到毫秒级的，随已是老码农，但仍然会开心难抑，或许正是这种简单的快乐让咱坚持到今天变成老码农一枚吧。

### 五、其他措施与效果 ###

web页还是要有一些改造处理的

1.  拓扑的服务清单中去除了所有服务
2.  增加查询按钮，只有点击查询按钮才能触发查询

目前的效果已初步满足需求，或许在后续数据量增大后，其他的优化项就会被启用。

### 六、最后说一句 ###

我是石页兄，如果这篇文章对您有帮助，或者有所启发的话，欢迎关注笔者的微信公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。

[format_png]: https://img-blog.csdnimg.cn/img_convert/b500af89b87301b2ecc0dd5f00745e74.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/5db5ed87ec5e015d9f754957f5a6c88c.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/fdccf27ad22cef2615918162044d6bb6.webp?x-oss-process=image/format,png