前言

分布式trace系统在微服务满大街的今天被各大互联网公司广泛应用，其中zipkin作为google dapper这篇论文的开源实现是小厂试水分布式trace系统的一个不错的技术选择，我们组早在16年就开始尝试将trace系统落地到微博消息系统的上下链路服务跟踪中，如今由我们组负责维护的trace系统已经在微博消息和微博视频业务中两处开花。

从业务上来说，目前微博客户端上行发消息操作整条链路已经全量接入trace系统，拉取消息链路采样接入。工具组件上，已经支持了对http接口调用、motan RPC调用 (motan是微博开源的RPC框架)、redis、mc、mysql等通用组件的trace埋点。整体trace数据的体量如下：span数：80W per second , span字节大小: 200M+ per second，在zipkin的已知用户中超过netflix，仅此于twitter。

这篇文章将主要从整体trace系统架构、存储层技术选型、埋点方案、trace数据离线分析和实时处理等几个方面介绍微博消息业务中zipkin的一些实践和思考。

背景

写这篇博客的起因是我最近对微博消息箱长连推送服务进行了整体架构层面的重构，然后需要对新推送系统的消息推送能力进行压测。压测需要通过控制几个变量来对推送系统造成不同的负载压力，得出系统在不同负载水平下消息推送的各分位推送耗时、成功率等几个指标，这里主要的变量有：

• 长连接数
• 消息的字节大小
• 消息的扇出连接数(fanout)，控制每条消息需要推给几个长连接
• 写入推送系统的消息qps (write qps)，最终推送系统的推给客户端长连接消息qps是： write qps * fanout

这其中很重要一步是压测系统要去按照给定的write qps去生成消息流写给推送系统，怎么实现这步，最朴素的做法是通过给定的qps，计算一个固定的消息时间间隔，然后按照这个时间间隔生成消息流即可。这种做法显然能满足要求，但是不够真实，对系统造成的压力太regular。同样qps，系统在这种流量负载下的表现情况可能会和真实流量情况下表现不一致，因此我们希望能尽量模拟给定qps下的真实流量分布，随机变量的概率分布这时就派上用场了。