大规模分布式链路分析计算在字节跳动的实践_UTF_8

飞鹏宇翔

动手点关注干货不迷路1. 综述微服务架构的快速发展使得分布式链路追踪系统成为观测体系中越来越重要的组件。字节跳动的分布式链路追踪系统经历了数年的发展后，已覆盖了字节的绝大部分在线业务，完成了对数万微服务和数百万微服务实例的在线链路追踪。在经典的指标观测分析和单请求链路追踪的基础上，如何从浩瀚如海的分布式链路数据中进一步挖掘出更高层次的信息，为业务的架构优化、服务治理、成本优化等场景提供更高效的数据支持，成为了下一步亟待回答的问题。本次分享主要介绍我们构建海量链路数据分析计算系统的实践经验，以及一些具体的落地场景。2. 可观测性与链路追踪2.1 基本概念为了方便读者更好的理解“链路分析”，首先浅聊一下什么是“可观测性”和“链路追踪”。对“可观测性”和“链路追踪”的概念已经熟悉的读者可以跳过本章节。随着微服务架构的快速发展，软件系统正在从单体应用发展为由大量微服务节点构成的复杂应用。为了更好的管控复杂的软件系统，“可观测性”工具正在变得越来越重要。“可观测性”工具构建的基础是可观测性数据，可观测性数据一般包括如下部分：链路追踪 Trace、日志 Logging、时序 Metrics、代码级 Profiling、事件 Event 和 元数据相关的 CMDB 等。为了帮助大家对可观测性工具有一个更直观的感受，这里用一个例子来阐述如何基于可观测性工具来解决工作中的实际问题：某值班人员收到告警通知服务的失败率正在上升，点击关联到错误指标对应的 Trace，在 Trace 中定位到错误的源头，在源头查看到关键的异常日志和代码栈，并发现源头报错服务正在执行一个变更操作，于是基本定位到此变更很可能就是导致此故障的原因。有了高质量的可观测性数据和工具，一个对此系统并不是非常熟悉的值班人员，就可能快速地完成此次故障的排查与止损。分布式链路追踪（Trace） 是可观测性系统的其中一个组件。狭义上讲 Trace 是对单次请求的明细追踪，记录请求在各环节上的调用关系，耗时，以及各类明细标签与事件。同时 Trace 还有一个角色是各类可观测性数据的链接纽带，即同一个 Request Context 的数据载体，分布式请求上的各类信息（Metrics/Logs..）通过 Trace 实现了可靠关联，进而可以构建各类可观测性数据的上卷下钻的跳转功能。2.2 字节链路追踪系统字节链路追踪系统经历了数年的发展，现已覆盖公司绝大部分在线业务。整体发展历程如下：2019： Trace 1.0 完成了 Trace 组件能力的构建。2020： Trace 2.0 实现了 Metrics/Trace/Log 的埋点一体化，对数据协议与技术架构进行了升级，并开始构建一站式观测平台 Argos。2021： 与字节绝大部分主流框架组件实现了默认集成，全司各业务线微服务覆盖度 > 80%。2022： 构建与探索场景化、智能化的场景，例如本分享聊的“链路分析”。字节链路追踪系统当前的现状数据（2022 年 10 月）：覆盖面： 5 万+ 微服务 /FAAS 数，300 万+ 容器实例数。使用量： 日 UV 6 千+ ，日 PV 4 万+。吞吐量： Span 数 2 千万+/s (默认 0.1% 采样)。资源配比： 100+ CPU cores 支撑 100 万 Span/s。SDK 性能： 单线程 40w Span/s。查询性能： TraceID 点查 P50 、实时性： nice to have为了尽可能满足数据的完整性和及时性需求，我们选择了流式计算模式，从数据流中选择带 Error 的 Trace 进行强弱依赖关系计算。需要注意短期的实时数据样本往往不够，需要结合历史累积数据共同判定再下结论。强弱依赖分析的主要挑战:准确率： 不同业务线判定业务稳态的规则较难统一，需要推动业务完善数据标记或规则录入。覆盖率： 部分路径线上常态化错误率极低，较难收集到足够的错误样本，需要配合混沌演练进行补充。强弱依赖分析的主要应用场景包括：限流降级预案配置指导： 强弱依赖数据可以回答紧急状况时哪些服务可以被降级，哪些服务必须被保障的问题。弱依赖可以进行限流降级，而强依赖则应当尽可能的保障高可用。超时漏斗配置指导： 强弱依赖数据可以指导业务更合理的配置超时漏斗。如下图所示，弱依赖配置超时时间过长是不合理的，可能会导致不必要的慢请求；如果强依赖配置的超时时间过短也是不合理的，可能会导致不必要的失败请求影响用户体验。辅助自动化故障归因： 准确的强弱依赖信息，对自动化故障归因可以起到较好的辅助作用。服务架构治理： 准确的强弱依赖信息，可以协助业务优化架构，治理不符合预期的强依赖，提前准备灾备方案，提升整体的稳定性和高可用。4.4 全链路性能反模式分析在实践的过程中，我们观察到有一些非常典型的性能反模式问题是可以从 Trace 数据中自动化的计算发掘，常见的性能反模式包括：调用放大： 单请求中，大量调用同一服务接口。如果在线链路中出现了调用放大比例极高的 case，往往不仅暴露出性能问题，还很可能会造成稳定性风险，需要及早治理掉。重复调用： 单请求中，多处使用相同 Request 调用同一个服务接口。这种情况常见于基础信息的重复获取，例如多处重复去请求 user info 或者 device info，是可以进行优化的。读写放大： 单请求中，从底层服务获取的数据量远大于最终返回给client的数据量。这种情况常见于滥用重接口获取轻信息，例如调用重接口请求了 user 的所有信息，却只取了 user name 一个字段。串行循环： 串行循环特征较为明显，其形态一般如下图所示，一般可优化为并行或批量调用。性能反模式问题的发掘还有如下两个需求：优先发现极值问题并提供 worst case 样本优先发现高流量+核心链路上的反模式问题因此性能反模式的分析任务需要自动化发现最严重的那些反模式问题，给出极值样本，并且关联出这些问题所在路径的流量和入口优先级，从而帮助业务对服务进行延迟优化和成本优化，及早解决掉相关的潜在稳定性风险。4.5 全链路性能瓶颈分析单请求的分布式 Trace 视图清晰直接，但是局限性在于观察者无法确定单请求所呈现出的 Trace Pattern 是普遍现象还是特殊现象。因此从大量的 Trace 数据中分析链路性能瓶颈，从而识别出整体性能 Pattern 和 worst case 样本也是链路分析的一个需求场景。从批量 Trace 中聚合计算出链路性能 Pattern，既有即兴模式的需求，也有离线模式的需求。即兴模式下可以满足对任意时段、灵活条件（各类tag，耗时区间）筛选批量 Trace 并快速获取分析结果的需求。离线订阅模式下可以满足更完整的对全量 Trace 数据的整体性能模式分析需求，并观察长期变化趋势。因此我们会将链路性能分析聚合算子复用在即兴和离线两种计算模式下。分析结果示例：4.6 错误传播链分析单条 Error Trace 可以观察出一条错误传播路径，但是观察者无法确认一条错误传播路径是否一定代表了普遍问题，也无法回答错误传播的影响面如何。因此聚合大量的 Error Trace 去分析整体的错误来源、传播路径和影响面也是链路分析的一个需求场景。和链路性能分析类似，从批量 Trace 中聚合计算出错误传播路径，既有即兴模式的需求，也有离线模式的需求。我们也会将错误传播链分析算子应用在即兴和离线两种计算模式下。即兴模式可以满足对任意时段、灵活条件（各类tag）筛选批量 Error Trace 并快速获取聚合分析结果的需求。离线订阅模式则可以满足更完整的对全量 Error Trace 数据的聚合分析需求，并观察长期变化趋势，辅助业务进行长期的稳定性优化工作。分析结果示例：5. 小结与展望本文主要介绍了在完成了从零到一的链路追踪基础能力的构建之后，如何对海量的链路数据进行聚合分析来回答更高层面的场景化问题。分享了我们的具体技术选型过程和落地的技术架构，以及一些较为成功的落地案例。最后分享后续的一些展望：数据质量持续建设： 数据质量对于链路数据分析的结果优劣起到极其重要的作用。不断完善业务语义规范，推进各层面接入覆盖会是我们后续持续投入的工作。场景化： 开放能力持续建设，沉淀业务知识和专家经验，打磨业务最佳实践。智能化： 基于数据+知识+算法，持续提升应对故障归因、稳定性优化、性能成本优化等场景的能效。拥抱云原生 ： 完善 OpenTelemetry 接入，打磨基础组件，更好的适应各类云上场景。6. 加入我们我们是字节跳动-基础架构-应用观测（服务端）团队，专注于 PB 级别海量数据的可观测性基础设施（Metrics、Tracing、Logging、Event、Profiling）和上层可观测性应用（E.g. 报警生命周期管理、异常检测、根因分析）的建设，为字节跳动整体业务的稳定性、性能优化、服务治理等方向保驾护航。● 深度解析字节跳动开源数据集成引擎● 【专访】Chrome HEVC 硬解背后的字节开源者● Android 插件化中资源错乱的解决方案● 【字节跳动技术沙龙】抖音 Android 基础技术大揭秘!