我是石页兄，朋友不因远而疏，高山不隔友谊情；偶遇美羊羊，我们互相鼓励欢迎关注微信公众号「架构染色」交流和学习
对skywalking架构设计、性能调优感兴趣可以查看文章：
一、背景
1.1 前文
溯源：Boss Li 提出部门的基础设施引入Skywalking, 于是踏上全链路监控之旅。。。其他暂略。。。
1.2 现状简述
一期规划，司内200多核心应用接入SkyWalking，伴随着接入的进行，主IDC一个多月内每天的segment在10亿以下，整个系统运行的也比较稳定；随着网关、基础资料等几十个大流量应用的接入，segment总量快速上升到25亿左右，自此噩梦来袭，服务端的各种稳定性、性能问题接踵而至，压力和优化的动力也相伴而生。
当时问题爆发的集中且突然，受资源、资料、精力多方面制约，选择了“弃车保帅”的策略：全方位功能降级，集中优化trace功能，把拓扑等功能隐藏起来，如此取舍的原因是：
- Trace的价值是引入Skywalking的主要原因，必须作为首要攻坚目标。
- 应用尚未全面接入，拓扑功能还无法体现出其全视角的C位价值。
而最近SA同学刚好聊到一些大盘看板的需求，加上SkyWalking的其他优化也早已完成，抽点时间把拓扑功能优化一下。
二、目标
对Trace查询做优化时，在保留60天记录的情况下，将基于traceId的查询从30秒优化到了1秒内，所以拓扑查询的目标自然也要优化到毫秒级别。
三、思路
基于对skywalking的掌握和之前优化的经验，快速梳理出一些优化项。
3.1 程序侧
- 增加查询的并行度，减少串行耗时。
- 规避无效查询的触发，避免带来额外消耗。
- 提升分片检索的命中，缩小检索分片数
3.2 ES存储侧
- 从ES日志中定位耗时逻辑，作为重点优化分析项
- 增加分片数，减少分片大小
- 增加机器，减少但个机器上承载的分片数量
四、措施与效果
4.1 问题定位
问题定位-接口：
拓扑页现实会有两个请求调用：
queryServiceTopo耗时在300ms内(整体优化未开始的时候，这个接口也超慢，现在其速度在毫秒级得益于早期其他的优化）queryTopoInfo耗时在1min以上（限定了60s的超时）；切换任意一个service这个接口都超时。
问题定位-ES日志：
部门的科科老师是ES专家，经过之前协同攻坚优化skywalking后，已然是老战友了，这次把思路简单沟通后，科科便开始从ES日志中找线索。多次尝试后，日志中未检测到耗时语句，两人默契的会心一笑，因为不是存储层的问题，那就可以优先从OAP程序中找逻辑的问题，而这边逻辑的问题，相对ES会更容易解决一些。
4.2 梳理接口代码
因为已经确定了queryTopoInfo调用会超时，从其接口实现梳理，调试定位源码过程比较繁杂，咱们忽略直接从结论说起，此接口实现中后边会多次调用MetricQuery#getValues方法，逻辑简单总结即为双层循环：
- 外层循环为：遍历多个metric ,如
service_cpm、service_resp_time、service_sla，每个metric 执行一次MetricQuery#getValues - 内层循环为：遍历每个metric中的id列表，对每个id执行一次
MetricsQuery#readMetricsValue
通过分析http请求的数据可知，这个id列表可能是成百上千个；并通过一次模拟确认了此处的确耗时
4.3 改造
确定此处双循环逻辑的耗时后，首先考虑内、外层循环如何调整，外层循环次数不可减少（可考虑并行），内层循环可以考虑把多次变少次，也可考虑并行；这个过程咱们跳过直接从结论说出:
原逻辑是每个id查询，最终进入图中所示的terms方法，但只传入了1个参数，而terms可以传入数组,即多个参数，于是尝试开辟另外一个执行链路，将第二层循环里的id数组传入到这个terms中。
4.4 效果
为了对比新老逻辑的差异，并留个后路达到快速回滚，代码中专门增加走新老逻辑的开关，执行4次请求看效果：
上图4次请求中，第二次的请求是原始逻辑，1分钟后超时，而其他三次是执行优化后的逻辑，耗时都是毫秒级的；从分钟级到毫秒级的，随已是老码农，但仍然会开心难抑，或许正是这种简单的快乐让咱坚持到今天变成老码农一枚吧。
五、其他措施与效果
web页还是要有一些改造处理的
- 拓扑的服务清单中去除了所有服务
- 增加查询按钮，只有点击查询按钮才能触发查询
目前的效果已初步满足需求，或许在后续数据量增大后，其他的优化项就会被启用。
六、最后说一句
我是石页兄，如果这篇文章对您有帮助，或者有所启发的话，欢迎关注笔者的微信公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。
