摘要：在传统的单体架构应用中，由于系统规模相对较小，服务调用链路简单，追踪系统的建设和使用相对容易。但随着微服务架构的流行，服务之间的交互和调用复杂度急剧增加。此时，传统的追踪系统已无法满足对多服务、跨系统的全链路追踪需求，因此需要引入分布式追踪系统。

在传统的单体架构应用中，由于系统规模相对较小，服务调用链路简单，追踪系统的建设和使用相对容易。但随着微服务架构的流行，服务之间的交互和调用复杂度急剧增加。此时，传统的追踪系统已无法满足对多服务、跨系统的全链路追踪需求，因此需要引入分布式追踪系统。

分布式追踪系统可以帮助实现对全链路的完整追踪和监控，跟踪服务之间的调用关系和数据流动，帮助发现潜在问题和优化性能。同时也可以帮助快速定位跨服务的调用问题，缩短故障排查时间，提高系统可用性。

作业帮的分布式追踪系统与云原生建设相伴相生，支撑着全公司的云原生微服务体系，一套优秀的分布式追踪系统应当满足以下几点要求：

低开销：追踪系统对运行服务的影响需要微乎其微，在一些高性能要求的服务中，即使是很小的监控开销也会对服务产生额外的性能负担，并且可能迫使部署团队关闭追踪系统。

应用透明：应用的开发者不需要关注追踪系统，尽量以非侵入或最小侵入的方式去进行追踪。

可扩展性：随着企业发展业务规模也在不断扩大，这要求追踪系统能够随着集群规模的增长，支持快速横向扩展。

低延迟：追踪数据产生后可以快速导出数据进行分析, 在最短时间内定位系统异常。

成本优势：能够以较小的机器预算支撑起全公司大规模追踪数据的处理与存储落地，且性能表现良好。

作业帮追踪体系现状

目前作业帮线上有数万个活跃服务，调用链路错综复杂，在业务高峰期，每秒产生的追踪跨度 (spans) 数据量超过 1000 万，平均每天新增的追踪数据写入量达到 20TB，并随着业务规模的不断扩大持续增长。

这种数据规模给追踪系统建设带来了巨大的挑战，需要追踪系统必须具备强大的数据实时处理能力，从采集到可检索的延迟需控制在分钟级以内，以保障故障排查的时效性；同时也需要对成本和收益进行权衡，将成本控制在合理范围内。

为应对以上挑战，作业帮选择基于 Jaeger 构建分布式追踪系统，采用以下技术方案：

Jaeger：作为追踪体系的核心组件，其多语言支持特性能够完美适配作业帮混合技术栈，且与云原生技术栈深度集成，易于部署管理、按需扩展。

Kafka：充当数据缓冲中枢，利用 Kafka 强大的吞吐能力，确保数据在高峰期间不丢不漏。

ClickHouse：作为一种高性能的列式数据库，其灵活的的索引和分区策略，使其非常适宜作为作业帮大规模追踪数据的存储，能够为追踪系统提供高效、可靠的数据存储和查询能力。

Prometheus：用于存储和分析链路及拓扑数据，Prometheus 强大的监控能力结合智能告警机制，能够实现系统异常分钟级感知。

目前该体系已稳定运行超过 2 年，并成功支持多次业务大促活动。在保障系统稳定性的同时，我们也在探索追踪数据与 AIops 的结合应用，在根因分析（故障传播链挖掘）、异常预测（多维指标关联预警）等场景实现智能化突破。

作业帮追踪系统实践

作业帮的追踪系统是伴随其云原生架构的发展而逐步建立完善的，属于服务治理体系的一个重要组成部分。截至目前，作业帮已有 97%+ 的服务完成了容器化改造，统一采用了基础架构提供的服务网格及各种基础组件。此外，主流开发语言均已成功接入公司内部的应用框架，确保了底层技术栈的高度一致性和标准化。这种统一的底层架构设计，不仅促进了内部资源的有效整合，更为构建企业级的分布式链路追踪系统奠定了坚实的基础。

得益于基建能力的建设，作业帮建成了如下所示的分布式追踪系统，并作为一项关键的基础观测能力提供出来，从架构层面支持了对服务间通信和基础服务访问进行追踪，能够实现实时监控与深度分析系统的运行状态及性能指标，为作业帮的技术运维提供了强有力的支持，同时也为优化用户体验、提升服务质量创造了条件。

业务无感接入

作业帮的追踪系统依托于其他云原生基建能力：统一的服务网格和服务框架，采用边车 + 日志 + 服务的采集模式构建，业务无需关心具体实现即可自动接入使用。

基于 MESH 的追踪（MESHTracing）

mesh 边车会对服务的所有出入流量做追踪打点, 这部分对服务是完全无感的。追踪数据上报到本机上的 jaeger-agent 服务上, 之后再批量传输到 jaeger-collctor 服务上，jaeger-collctor 服务负责统一将追踪数据写到 Kafka 中。另外我们最新版本的 mesh 在追踪埋点上的开销几乎可以忽略不计，对服务的性能影响极小。

基于日志的追踪（Log-Based Tracing）

对一些业务小众或者特殊的网络调用, 我们通过约定日志规范的方式做追踪数据采集，如部分服务出流量（服务访问 ck、表存储的流量）、网关的入流量等。log-trace 服务负责做日志的追踪数据采集, 它会从日志 kafka 订阅所有业务日志, 解析后封装成标准的追踪数据直接写入到 kafka 中，这里没有先上报到 jaeger-agent 再由 jaeger-collctor 统一采集，避免了中转开销。

日志采集模式基于底层语言框架同样对服务无感，是作为 MESH 采集模式的补充，当前公司主流的语言框架均已完成支持。

基于服务的追踪（Service-Based Tracing）

以上的两类采集方式专注于对服务边界的观测, 如果服务有对内部的观测需求则通过服务自定义打点的方式上报追踪数据，按需增加追踪深度。服务通过接入追踪 SDK 方式上报追踪数据到本机上的 jaeger-agent 服务上, 再通过 jaeger-collceror=>kafka 的链路完成上报。

存储效率与成本的权衡

作业帮的追踪系统对数据不做采样, 使用全采样的策略。在当研发遇到线上问题时，就可以通过请求 ID 来快速排查整个链路, 快速定位问题。但这会导致追踪数据量极其庞大，作业帮早期使用 ES 作为存储，实践发现 ES 的写入性能不够理想，尤其是在晚高峰的时候总是会出现写入延迟，影响追踪服务的使用。

在综合考虑成本与存储效率后，我们选择使用 ClickHouse 替代 ES 来存储和索引追踪数据，并将数据保留 3 天。由于 Jaeger

来源：极客邦科技