一、为什么Zipkin要选这两种存储后端？

微服务跑起来之后，请求像流水一样在各个服务里转，出问题时得靠Zipkin查整条链路的"行车记录仪"，选存储就像选仓库，小物件用小仓库够，大物件就得用大仓库。刚起步的小团队，服务也就3-5个，日均请求才几十万，用自带的内存存储重启就没；服务多了，日均请求破千万，就得选靠谱的持久化存储。目前主流的就是MySQL和Elasticsearch，刚好对应两种规模的团队，下面咱们分别展开说怎么适配，还有踩坑指南。

二、MySQL适配Zipkin的操作实践

2.1 技术栈说明

本次统一用栈为：MySQL 8.0、Zipkin 2.23，全程不混合其他技术，方便跟着操作。

2.2 前置准备

先给MySQL建个专门的Zipkin数据库，比如叫zipkin，再创建专属用户，别用root，权限最小化就行，比如用户名zipkin，密码设个好记的。然后去Zipkin官网拉MySQL的初始化脚本，执行后自动建表，省得自己写SQL。

2.3 核心配置示例

修改Zipkin的配置文件（application.yml），指定用MySQL存储，注释都标清楚：

spring:
  zipkin:
    storage:
      type: mysql # 明确指定存储类型为MySQL
      mysql:
        host: 127.0.0.1  # 填你的MySQL服务器IP，别用localhost
        port: 3306       # MySQL默认端口，没改的话不用动
        db: zipkin       # 刚才建的Zipkin数据库名
        username: zipkin # 专属用户的用户名
        password: 123456 # 刚才设的密码
        max-active: 10   # 连接数，服务器配置一般的话设10，高的话调20

2.4 MySQL的性能优化细节

建完表后一定要加索引，不然查trace慢到怀疑人生，比如查trace最常用的两个条件是trace_id和时间，加如下索引：

-- 给trace_id加索引，这是查询单条链路的核心
CREATE INDEX idx_trace_id ON zipkin.traces(trace_id);
-- 给时间戳加索引，查最近7天的链路会快很多
CREATE INDEX idx_ts ON zipkin.traces(ts DESC);

另外，MySQL的字符集一定要用utf8mb4，别用老的utf8，不然存中文或者特殊字符会乱码；引擎选InnoDB，别用MyISAM，稳定还支持事务。

2.5 MySQL的优缺点

优点是门槛低，所有开发者都会MySQL，运维简单，不用额外学新东西，成本低，适合服务数少于20、日均请求低于1000万的小团队。缺点是扛不住大流量，当请求破千万时，分页查询会变慢，全表扫的话能等十几秒，而且单机存储没法扩容，服务涨了就得换方案。

三、Elasticsearch适配Zipkin的操作实践

3.1 技术栈说明

本次统一用栈为：Elasticsearch（ES）7.10、Zipkin 2.23，全程不混合其他技术。

3.2 前置准备

ES得搭集群，至少3个节点，别单点，不然挂了就丢数据。每个节点的配置不用太高，2核8G就行，存trace足够。

3.3 核心配置示例

修改Zipkin的application.yml，指定用ES存储，关键参数标出来：

spring:
  zipkin:
    storage:
      type: elasticsearch # 明确指定存储类型为ES
      elasticsearch:
        hosts: http://es-node1:9200,http://es-node2:9200,http://es-node3:9200 # ES集群节点地址，至少填2个防单点
        index: zipkin     # ES里的索引前缀，自动生成类似zipkin-2024.05.20的索引
        username: admin   # ES开了安全的话要填，没开就删这行
        password: 654321  # ES的密码，没开安全就删
        shards: 5         # 分片数，集群3个节点，每个节点分1-2个分片，别超过10个
        replicas: 2        # 副本数，2个副本防数据丢失，别太多，浪费磁盘

3.4 ES的性能优化细节

最重要的是设置索引生命周期，让ES自动删旧数据，比如保留7天的trace，不然磁盘会被撑满。操作是在ES里开ILM（索引生命周期管理），规则设成7天后删除索引，不用手动操作。另外，分片数别太多，一个索引最多10个分片，太多的话查询要合并太多数据，速度反而慢；副本数设1-2个就行，够容错就行。

3.5 ES的优缺点

优点是天生分布式，能扛大流量，日均请求破亿都没问题，查询速度快，查1个月内的链路基本1秒出结果，适合服务数多于20、日均请求超1000万的中大型团队。缺点是运维复杂，得管集群、监控节点状态、处理集群脑裂，成本比MySQL高，需要懂ES的人维护。

四、选型要避的坑

选MySQL时别用Zipkin默认的表结构，官方的脚本是基础版，得手动加刚才说的两个索引；别用MySQL 5.7以下的版本，性能差很多；连接数别设太大，超过服务器最大连接数会崩。选ES时别分片太多，比如设50个分片，会导致查询变慢；别副本数超过节点数，浪费磁盘；一定要监控ES的磁盘使用率，超过70%就得扩容或者删旧索引；开ES安全，不然数据会泄露，毕竟链路数据可能带用户信息。

五、总结

选型核心看业务规模：小团队、低请求量用MySQL，配置简单成本低；中大型团队、高请求量用ES，查询快能扩容。不管选哪个，都要做性能优化，比如加对索引、调对参数、监控状态，这样Zipkin才能真正帮你快速排查微服务的问题，不用再对着一堆日志找半天。