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

　　上周三凌晨三点，监控大屏的绿光刺得我眼疼，某库某表的写入延迟突然飙到十八秒——这破事在三年前根本不会发生，那时候我们连分布式追踪的采样率都控制在千分之一，生怕撑不住流量。现在倒好，采样率调到百分百，每天处理十亿条链路数据，结果被一个慢查询干趴了。老张蹲在工位上啃煎饼，嘴里嘟囔“这架构演进就是个优胜劣汰的修罗场”，我原以为他在吐槽，结果翻日志发现，还真是这么回事。

文章配图，仅供参考

　　优胜劣汰这事儿，在存储层体现得最狠。第一年我们用MySQL存追踪数据，表结构改了十八版，最后还是跪在索引上——某张表的主键是“服务名+时间戳”，结果查询时发现，服务名里有特殊字符，索引直接失效。那会儿测试环境经常报“Duplicate entry”，我原以为是并发问题，结果一查，是测试数据里混了emoji表情。后来我们换了ClickHouse，以为能消停，结果发现ClickHouse的MergeTree引擎在高并发写入时，会莫名其妙丢数据。运维老王气得直拍桌子：“这破引擎，写个数据还要排队？”最后我们只能自己写了个补偿机制，每天凌晨跑脚本补数据，补了三个月才稳定。

　　最近两个月最离谱的是采样策略的迭代。去年我们为了省存储，把采样率从百分百降到百分之一，结果线上出了个概率性bug——某个服务的调用链偶尔会断，排查时发现，断链的那次请求刚好没被采样。产品经理在群里@我：“这追踪系统还不如没有，关键时候掉链子！”我盯着屏幕上的工单，第三杯咖啡已经凉了，手指在键盘上敲了半分钟，最后只回了句“在修了”。后来我们咬咬牙，把采样率调回百分百，结果存储成本翻了十倍，运维小哥看着账单直咧嘴：“这钱够买十台服务器了。”现在我们的策略是动态采样——根据服务的重要性和调用频率自动调整，重要服务全采样，边缘服务抽样。这方案听着美好，实现起来全是坑：采样率计算要实时，不能影响主链路性能；采样结果要持久化，不能重启就丢；采样策略要可配置，不能写死代码里。光是这些细节，就让我们改了七版代码，跟开发互怼的群聊记录能装满一个硬盘。

　　说到开发，上周五的架构评审会差点没吵起来。前端说追踪页面加载太慢，要我们优化；后端说追踪数据太大，要前端降级；运维说存储成本太高，要我们删数据。我夹在中间，听着他们互相甩锅，突然想起三年前那个凌晨——那时候我们连追踪系统都没有，出了问题只能靠猜。现在倒好，系统是有了，问题也多了十倍。最后我拍桌子：“都别吵了，先解决眼前的慢查询！”老张在旁边补刀：“对，优胜劣汰，先把最菜的优化掉。”

　　现在回头看，这三年架构演进的核心就俩字：折腾。存储换了三套，采样策略改了五版，连监控大屏都换了两次——第一次是液晶的，第二次是LED的，现在这个绿光刺得我眼疼。但折腾也有折腾的好处：那些经不住流量冲的、扛不住并发压的、容不了脏数据的组件，全被淘汰了。剩下的，都是硬骨头。我原以为“从0到10亿”是个技术问题，结果发现，它更像个生存问题——你得先活下来，才有资格谈优化。

　　下一步准备搞链路压缩。现在一条完整的调用链，平均要存三百个字段，其中一半是重复的。如果能压缩到五十个字段，存储成本能降六成。但压缩算法得自己写，开源的要么性能不行，要么压缩率不够。老张说：“这活儿够喝一壶的。”我点点头，盯着屏幕上的日志，心里默默盘算：这壶酒，得喝多久？

（编辑：站长网）

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