分布式链路追踪初探
微服务架构 作为云原生核心技术之一,提倡将单体应用程序(巨石架构)划分成一组小的服务(微服务),服务之间互相协调、互相配合,为用户提供最终价值。 微服务架构设计中,通常由多个微服务组件组成,有 1) API 网关 ( apisix, kong, traefik ) 负责认证鉴权、负载均衡、限流和静态响应处理; 2) 服务注册发现中心( ZooKeeper、Consul 、ETCD ) ,负责服务的注册和发现。3)可观测性 负责日志收集查看的ELK、Loki,负责服务性能指标告警的指标 Metrics 监控 Prometheus, 负责追踪请求的 Tracing 链路追踪。在多个组件的组成下,才能顺利组成一个好的微服务架构。 今天我就来简单的讲一讲微服务组成中可观测性的分布式链路追踪。 OpenTracing 介绍 OpenTracing是一个新的、开放的分布式追踪标准,用于应用程序和OSS包。有过大规模构建微服务经验的开发者都知道分布式追踪的作用和重要性:每个进程的日志和指标监控都有它们的用武之地,但它们都无法重建事务在分布式系统中传播时的复杂旅程。分布式跟踪就是这些旅程。 OpenTracing 项目定义了一套分布式追踪的标准,以统一各种分布式追踪系统的实现。OpenTracing 中包含了一套分布式追踪的标准规范,各种语言的 API,以及实现了该标准的编程框架和函数库。 OpenTracing 提供了平台无关、厂商无关的 API,因此开发者只需要对接 OpenTracing API,无需关心后端采用的到底是什么分布式追踪系统,Jager、Skywalking、LightStep 等都可以无缝切换。 数据模型 OpenTracing 定义了以下数据模型: Trace (调用链):一个 Trace 代表一个事务或者流程在(分布式)系统中的执行过程。例如来自客户端的一个请求从接收到处理完成的过程就是一个 Trace。 Span(跨度):Span 是分布式追踪的最小跟踪单位,一个 Trace 由多段 Span 组成。可以被理解为一次方法调用, 一个程序块的调用, 或者一次 RPC/数据库访问。只要是一个具有完整时间周期的程序访问,都可以被认为是一个 Span。 SpanContext(跨度上下文):分布式追踪的上下文信息,包括 Trace id,Span id 以及其它需要传递到下游服务的内容。一个 OpenTracing 的实现需要将 SpanContext 通过某种序列化协议 (Wire Protocol) 在进程边界上进行传递,以将不同进程中的 Span 关联到同一个 Trace 上。对于 HTTP 请求来说,SpanContext 一般是采用 HTTP header 进行传递的。 ...