先说个真事。2018年我们团队刚上微服务，一百多个节点，部署完谁也不知道请求到底走到了哪。当时引入Zipkin，觉得这东西真是神器——直到某天夜里线上突然雪崩，原因竟然是Zipkin的采集器把jvm内存打满了。我守着那台机器，看着日志里满屏的Brave span flush失败，骂了一句：优雅个屁。
好了，平复一下。其实Zipkin依然是我最推荐的分布式追踪系统之一，只是它远不是你装好就完事儿的玩意儿。它是个精密仪器，用得好事半功倍，用不好就是生产事故的定时炸弹。我今天不打算教你从头搭Zipkin，那种文档多的是。我想聊聊它底层的那些设计选择，那些让你在深夜拍大腿的美妙机制，以及那些必须提前避开的坑。
Span与Trace：它比你想的更“重”
很多人把Span当做一个简单的日志条目，错。Zipkin的Span数据结构是精心设计的，它承载了时间戳、标签、注解，还有parentId这种维系追踪树的关键。Trace的生成靠的是服务间的headers传递：X-B3-TraceId、X-B3-SpanId、X-B3-ParentSpanId……这些名字是不是眼熟？但背后的id生成逻辑很讲究。
最早我们用随机数，结果发现TraceId碰撞率在一天几十亿请求下高得离谱。后来才明白，Zipkin默认的brave实现用的是基于随机数和时间戳的64位id，碰撞概率虽低，但在极端场景仍需小心。我压测过一个网关，QPS十万，用了随机64位，运行一周出现了两次重复TraceId，导致两个不同请求被错误合并——排查到几乎疯掉。后来换成了雪花算法变种，世界清净了。
存储选型：一场赌局
Zipkin支持四种后端：内存、MySQL、Cassandra、Elasticsearch。内存只能演示；MySQL扛不住高写入，我用过，写入超过3000span/s就开始full gc；Cassandra是官方推荐，但运维成本高；ES最灵活，可也是坑最多的。
我们公司的链路数据每天2TB，起初用ES 5.x，每天的分片merge能把CPU吃满。后来切到Cassandra，按traceId范围做分区，写入性能飞跃，单节点轻松吃下2万span/s。但Cassandra也有毛病：读trace列表时，如果时间范围太大，会触发全表扫描，慢到令人发指。我们被迫在应用层加缓存。说到底，没有银弹。
我还实测过Jaeger，它的写入路径更短，默认用Cassandra时比Zipkin吞吐高15%左右，但Zipkin那套span store的抽象层让你能轻松适配各种存储，这种扩展性让我最终留下了。性能不是一切，对吧？
三个差点要命的坑
一、采样率：非黑即白是自杀
开始我设了10%采样，觉得足够分析问题了。直到一次大促，某个慢服务只采到2条trace，因为那服务调用量只有每秒几十次，10%的采样导致大量请求没被采，故障根因根本看不清。后来改成了自适应采样：针对错误、高延迟强制采样，正常请求按流量动态调节。实现不难，但思想转变很重要。只设固定比例？太傻了。
二、异步报告器的秘密
Zipkin的reporter默认是异步的，有个有界队列。我遭遇过队列满了直接丢弃span的情况。那个微服务正好是支付链的一环，丢了几个小时的关键链路数据，导致故障定位延迟，损失惨重。解决方案？监控队列剩余容量，必要时用断路降级：如果队列满，暂时采不到的数据存本地，或者干脆限制业务线程的发送速度。别依赖默认的无界行为，那根本不安全。
三、TTL与清理：沉默的磁盘杀手
不管你用ES还是Cassandra，数据清理都会让你头疼。我们用ES时设置了30天TTL，结果用Date math索引，滚动时没处理好，一个索引的alias丢失，导致所有查询走默认索引，那个索引有90天数据，查询一跑就是分钟级。磁盘还被撑爆过一次。后来定了铁律：必须用索引模板，必须用curator或ilm策略，必须监控磁盘用量。Cassandra用ttl倒是简单，但过期数据的compaction可能瞬间打高IO，要分散在业务低谷执行。
Zipkin本身不负责清理，它把问题都留给了你——这就是架构师的取舍之美，也是运维的噩梦。
但还是要说句公道话
Zipkin的代码写得真好。Brave库的插桩方式几乎无侵入，spring-cloud-sleuth把它封装得更顺手。它不像Jaeger那样追捧云原生，但你把它和Kafka一结合，处理海量数据时的稳重感，会让你觉得那些坑都值了。现在我们的系统每天采集百亿span，靠着Zipkin支撑起整个故障定位体系。每次半夜排障，看着那张trace树一点一点展开，我还是会心里感慨：这玩意儿，真他妈精巧。
