大气物流网站模块,青海西宁学做网站在哪,南京华夏天成建设有限公司网站,内账免费的财务软件这是小卷对分布式系统架构学习的第6篇文章#xff0c;关于链路追踪#xff0c;之前写过traceId的相关内容#xff1a;https://juejin.cn/post/7135611432808218661#xff0c;不过之前写的太浅了#xff0c;且不成系统#xff0c;只是简单的理解#xff0c;今天来捋一下… 这是小卷对分布式系统架构学习的第6篇文章关于链路追踪之前写过traceId的相关内容https://juejin.cn/post/7135611432808218661不过之前写的太浅了且不成系统只是简单的理解今天来捋一下链路追踪的理论 1.为什么需要链路追踪
在复杂的分布式系统中系统通常由多个独立的服务组成几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。 这种复杂的系统会带来一系列问题 1.如何快速定位问题判断故障影响范围 2.如何梳理服务间的依赖关系 链路追踪的用途就是为了知道请求在系统中的流转路径定位性能瓶颈诊断故障等。
2.追踪与跨度
要理解链路追踪的原理先理解Trace追踪 和 Span跨度两个概念。
Trace追踪一个完整的用户请求流程从用户发起请求开始到请求结束。一个追踪包含多个 Span。Span跨度一种表示工作单元的结构通常对应着请求经过的某个服务或者操作每个Span包含以下信息 Span ID唯一标识当前SpanTrace ID标识属于同一个Trace的所有Span父Span ID如果当前Span由另一个Span引发则会记录父Span ID时间戳、标签和日志
每一次Trace是由若干个有顺序、有层级关系的Span组成的一棵追踪树结构图片来源Dapper论文 3.链路追踪的概念
从广义上分布式链路追踪系统可以分为三个部分数据收集、数据存储、数据展示。
从狭义上指链路追踪的数据收集部分
比如Spring Cloud Sleuth就属于狭义的追踪系统通常会搭配 Zipkin 作为数据展示搭配 Elasticsearch 作为数据存储来组合使用。
这里从Dapper论文的内容总结下链路追踪的设计目标如下
低开销追踪系统对正在运行的服务应该具备很小的性能影响应用层透明性开发人员无需关注追踪系统作为业务组件尽可能减少对业务系统的代码侵入性。使用时透明减少开发负担。如果需要依赖开发者配合才能使追踪系统生效这样是无法满足追踪系统“无所不在的部署”这个需求可扩展性支持分布式部署具备良好的扩展性能支持的组件越多越好至少在接下来几年内能处理服务和集群的规模数据的快速分析追踪数据生成后的数据分析要快分析维度尽可能多理想情况下是一分钟内数据的新鲜度能快速对生产异常做出反应。
4.功能模块
生产环境的链路追踪系统主要分为4个大模块
4.1 埋点与生成日志
分客户端埋点、服务端埋点、以及客户端和服务端双向埋点埋点日志通常包含了traceId、spanId、调用的开始时间协议类型、调用方ip和端口请求的服务名、调用耗时调用结果异常信息等 需要写log高并发服务中性能影响越重通常使用采样异步log的方式解决 4.2 收集和存储日志
特点是需支持分布式日志采集方案一般还会用MQ作为缓冲 每个机器上有个daemon这里的daemon指的后台服务进程专门用于日志收集和Trace转发 多级collector类似pub/sub架构可以负载均衡 聚合数据进行实时分析和离线存储 离线分析 需将同一条调用链的日志汇总在一起 4.3 分析和统计调用链数据
调用链跟踪分析把同一TraceID的Span收集起来按时间排序就是timeline。把ParentID串起来就是调用栈。
4.4数据展现以及决策支持
5.数据收集的三种实现方式
不论是狭义还是广义的链路追踪系统都必须包含数据收集的工作介绍三种主流的数据收集方式
5.1基于日志的追踪Log-based Tracing 思路是将 Trace、Span 等信息直接输出到应用日志中然后将日志归集过程汇聚到一起再从全局日志信息中反推出完整的调用链拓扑关系 日志追踪对网络消息完全没有侵入性对应用程序只有很少量的侵入性对性能的影响也非常低 缺点
依赖日志归集过程日志不求决对的一致和连续精准性较低。业务服务的调度和日志归集不是由同一个进程同时完成的存在日志延迟或丢失的问题从而产生追踪失真的情况
5.2基于服务的追踪
目前最常见的追踪实现方式如Zipkin、SkyWalking、Pinpoint 等主流追踪系统都采用这种方式其实现思路是通过某些手段给目标应用注入追踪探针Probe比如针对 Java 应用一般就是通过 Java Agent 注入的。 探针可以看作是目标服务身上的小型微服务系统有服务注册、心跳检测等功能有专门的数据收集协议可以把从目标系统收集的服务调用信息通过HTTP 或者 RPC 请求发送给追踪系统 该方式具备追踪的精确性和稳定性缺点是消耗的资源更多具备更强的侵入性
下图是pinpoint的调用栈示例 Pinpoint 本身就是比较重负载的系统运行它必须先维护一套 HBase服务追踪这方面国产开源的Skywalking更加轻量化
5.3基于边车代理的追踪
·基于边车代理的追踪是服务网格的专属方案也是最理想的分布式追踪模型对应用完全透明无论是日志还是服务本身都不会有任何变化
边车代理本身对应用透明的工作原理决定了它只能实现服务调用层面的追踪像前面 Pinpoint 截图那样的本地方法调用级别的追踪诊断边车代理是做不到的。
6.链路追踪协议
链路追踪协议的发展历史2016 年 11 月CNCF 技术委员会接受了 OpenTracing 作为基金会的第三个项目。OpenTracing 是一套与平台无关、与厂商无关、与语言无关的追踪协议规范。
但是Google 却在这个时候出来并提出了与 OpenTracing 目标类似的 OpenCensus 规范且得到了巨头 Microsoft 的支持这样就形成了OpenTracing 和 OpenCensus两大可观测性的阵营。
2019 年OpenTracing 和 OpenCensus 宣布握手言和共同发布了可观测性的终极解决方案OpenTelemetry并宣布会各自冻结 OpenTracing 和 OpenCensus 的发展。
6.1 OpenTracing
概述OpenTracing是一个开放的API规范旨在通过提供一套统一的接口帮助开发人员能够在其应用中实现分布式追踪
和一般的规范标准不同Opentracing 不是传输协议消息格式层面上的规范标准而是一种语言层面上的 API 标准。以 Go 语言为例只要某链路追踪系统实现了 Opentracing 规定的接口interface符合Opentracing 定义的表现行为那么就可以说该应用符合 Opentracing 标准。
官网https://opentracing.io/
6.2 OpenCensus
OpenCensus为微服务和单体应用提供可观测性通过追踪请求在服务之间传播并捕获关键的时间序列指标。其核心功能是从应用程序中收集追踪和指标能够在本地显示并将其发送到任何分析工具也称为“后端”
官网https://opencensus.io/
6.3 OpenTelemetry
官网https://opentelemetry.io/
OpenTelemetry 可以用于从应用程序收集数据。它是一组工具、API 和 SDK 集合我们可以使用它们来检测、生成、收集和导出遥测数据指标、日志和追踪以帮助分析应用的性能和行为。具体的解释为
一个可观测性框架和工具包旨在创建和管理遥测数据如追踪、指标和日志。与供应商和工具无关这意味着它可以与各种可观测性后端一起使用包括开源工具如Jaeger和Prometheus以及商业产品。不是像Jaeger、Prometheus或其他商业供应商那样的可观测性后端。专注于遥测的生成、收集、管理和导出。OpenTelemetry的一个主要目标是能够轻松地在应用程序或系统中插桩无论它们使用何种语言、基础设施或运行时环境。遥测的数据存储和可视化故意留给其他工具。
篇幅问题就不继续详细介绍这三个协议了感兴趣的小伙伴们可以自行去官方了解。
总结今天讲了链路追踪的理论知识包括追踪与跨度的概念一个追踪系统的模块划分数据收集的3种方式以及链路追踪协议的发展。了解这些概念后再更容易去理解开源的链路追踪框架。
