SkyWalking 拓扑功能的性能优化

一、背景

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方法，逻辑简单总结即为双层循环：

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

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

4.3 改造

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

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

4.4 效果

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

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

五、其他措施与效果

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

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

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

六、最后说一句

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