三年架构设计：从0到10亿的分布式追踪演进之道

　　去年6月份那会儿，监控大屏突然飘红，产品经理冲进工位喊“用户报错量翻三倍”，我盯着控制台那串“Trace ID not found”的报错，键盘上的F键都差点被我按裂——这破追踪系统，三年前刚上线时明明能扛住日均百万的调用量，怎么现在连个峰值都撑不住？

文章配图，仅供参考

　　第二年咬咬牙上了自研追踪系统，采样率提到30%，存储从ES换成了ClickHouse——别问，问就是“ES太贵”。结果新问题来了：ClickHouse的MergeTree表引擎在合并小分区时，CPU直接飙到90%，监控面板上“merge_delay”的指标红得刺眼。更离谱的是，有次线上故障，我们想查某个Trace的完整链路，结果发现部分Span因为ClickHouse的写入延迟，居然比下游服务的调用时间还晚——这追踪追了个寂寞，产品经理在会议室拍桌子：“你们这系统比用户反馈还慢！”

　　第三年学乖了，搞了个“混合存储”：最近7天的数据存ClickHouse，7天前的转存到S3，用Presto做查询。采样率动态调整，高峰期降到10%，低谷期提到50%。结果新问题又来了：Presto查询S3上的冷数据，首屏要转圈12秒，用户点“查看详情”跟点彩票似的，不知道啥时候能出来。更绝的是，有次跨机房调用，因为网络延迟，某个Span的timestamp比父Span还大，追踪链路图直接画成了“莫比乌斯环”，测试小妹看着图问我：“这是你们新设计的循环依赖检测功能？”

　　现在回头看，这三年踩的坑，80%都跟“预估不足”有关。第一年觉得“日均百万够用了”，结果第二年就打脸；第二年觉得“ClickHouse能扛”，结果第三年被写入延迟和查询性能双重暴击；第三年搞混合存储，又低估了冷数据查询的延迟。最搞笑的是，去年6月份那次故障，根本不是追踪系统本身的问题——是某个下游服务把日志级别从INFO调成了DEBUG，导致追踪数据量暴涨10倍，直接把存储打崩了。我们在会议室复盘了俩小时，最后发现是运维小哥手滑改错了配置文件——他工位的显示器还是竖着的，说“这样看日志方便”，结果方便到把系统看崩了。

　　现在我们的追踪系统，采样率能根据QPS自动调整，存储层加了熔断机制，查询层搞了缓存预热，连UI都重写了——之前那个Vue2的页面，点个按钮要等3秒，现在换成React+Webpack5，首屏加载大概1秒（具体没测，反正比之前快）。但问题还是不少：比如跨机房的时钟同步，偶尔还会漂移个几毫秒，导致追踪链路图里偶尔冒出个“时间旅行者”；比如某些老服务，追踪代码还是硬编码的，改一次要发版，运维小哥现在看到“trace”相关的工单就头疼；比如最近产品经理又提需求，说“要能按用户ID聚合追踪数据”，我盯着他工位上那杯凉了的外卖，心想：“您这需求，怕是要再等三年。”

　　下一步打算把追踪数据和APM数据打通——现在这两套系统是分开的，查个问题要在两个页面来回跳，比玩“大家来找茬”还累。另外，想把采样率再往上提提，现在30%的采样率，偶尔还是会漏掉关键链路，上次用户报错，我们查了半天，最后发现是某个未采样的Span里抛了异常——这感觉就像你拿着金属探测器找金子，结果金子刚好在探测器没扫到的地方。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!