分布式错误处理 第四部分 为什么定位慢？-- 分布式错误 TraceId 分布式信息 在微服务体系中，每个应用会涉及多种组件和调用多个业务API， 导致调用链变得复杂，整体架构的复杂度也随之增加。 A服务出现了问题，可能是由其他B，C，F,G等服务引起的 错误尽早失败 串联信息 为什么定位慢？-- 分布式错误 TraceId 分布式信息 错误尽早失败 串联信息 A B C A 为什么定位慢？-- 分布式错误 TraceId 分布式信息 错误尽早失败 串联信息 方式一，仍然启动b服务 • b服务核心错误信息会藏在了某些日志，如下图所示 • 引入流量后，a服务中接口因为调用b服务报错，但a服务日志里不是根因 • 这种错误被隐藏，我们排查的时候需要很久 • 影响线上功能 为什么定位慢？-- 分布式错误 TraceId 分布式信息 错误尽早失败 串联信息 。 • 错误信息高亮，显示红色让错误更加明显。 • 核心错误中断系统启动，让错误显示在最后一行。 • 不让报错传递到别的服务 TraceId 分布式信息 错误尽早失败 串联信息 Fail Fast 为什么定位慢？-- 分布式错误 TraceId 分布式信息 错误尽早失败 串联信息 击鼓传花 a服务发现报错 --> 查看a日志--> b服务负责人 查看b日志--> c服务负责人

��C1 ��C2 ��C3 traceid�10000 traceid�10000 Spanid�1 traceid�10000 Spanid�2 traceid�10000 Spanid�1.1 traceid�10000 Spanid�1.2 traceid�10000 Spanid�2.1 traceid�10000 Spanid�2.2 • • ��Dapper�Dapper, a Large-Scale Distributed Systems Tracing Infrastructure • traceid�����������traceid ������������������ ��������� • spanid�������������� ���spanid������������ ����� 24 ���� javaagent���! javaagent���! ������! ������! http�mq! thrift! gRPC! http/tcp! ������! ���! ��! ��! ��! traceid��! ��! ���! ��! ���! ��! ���! ��! ��! ��! JVM��! ���! ���! ��! ��! ����! ES�mysql,Cassandra,�

30x 2M 18mon 18mon 18mon Metrics Tracing Logging Tag, Exemplars Tag Tag, Exemplars Tag Tag, TraceID Tag, TraceID “Index-free” “Index-free” “Cardinality-free” 稀疏索引、冷热分离 simplify the growing complexity © 性能指标 调用日志 网络链路 由业务代码驱动的可观测性数据、云API数据 调用关系 知识图谱 链路追踪 黄金指标 关联 应用链路（Tracing） 应用日志（Logging） 应用链路 TraceID 私 有 云 物 理 公 有 云 企业混合云 控制器 10W采集器 20+云平台 采集器 1% CPU 0.01% 带宽开销 ︹ 零 侵 入 ︺ 流 量 采 集 性能指标 调用日志 网络链路 由业务代码驱动的可观测性数据、云API数据 调用关系 知识图谱 链路追踪 黄金指标 关联 应用链路（Tracing） 应用日志（Logging） 应用链路 TraceID 私 有 云 物 理 公 有 云 企业混合云 控制器 10W采集器 20+云平台 采集器 1% CPU 0.01% 带宽开销 ︹ 零 侵 入 ︺ 流 量 采 集

4 Mysql、Redis mysql、redis组件采集请求中包含的traceid 3 RocketMq mq通过消息属性字段透传traceid 2 LSF框架 微服务框架通过RPC调用上下文透传traceid 1 Api-gateway、CGI、Job调度 在源头为每次请求生产唯一标识traceid 混合云&同城双活 Nginx-Proxy 机房1 web层 service层

看云网更清晰 Simplify the growing complexity. OpenTelemetry的方法 Tag, Exemplars (TraceID, SpanID) Tag, TraceID, SpanID TraceID & Tag 看云网更清晰 Simplify the growing complexity. 数据打通并不简单 ① Trace与「非Request scope」的Metrics 性能指标 调用日志 网络链路 由业务代码驱动的可观测性数据、云API数据 调用关系 知识图谱 链路追踪 黄金指标 关联 应用链路（Tracing） 应用日志（Logging） 应用链路 TraceID N F V 公 有 云 / 私 有 云 企业混合云 控制器 10W采集器 20+云平台 采集器 1% CPU 1% 带宽开销 原 始 数 据 采 集 云平台API 容器编排API

os/exec 日志跟踪 l 触发点生成TraceId l 通过context.WithValue保存TraceId l 然后Context作为参数在多个groutine或者其他函数间 传递 l 达到日志跟踪的目的 日志跟踪调用链 n 关键节点的ParentId n Context Value存储 n 反串就是调用链 n TraceId Timeline跟踪；ParentId调用链跟踪

每个请求都生成一个全局唯一的 traceid，端到端透传到上下游所有节点，每一层生成一个 spanid， 通过traceid 将不同系统孤立的调用日志和异常信息串联一起，通过 spanid 和 parentid 表达节点 的父子关系 链路追踪 在分布式系统中请求的路径经常很凌乱且无法预测，为了构建我们想要的任何路 径的视图，无论多么复杂，每个组件都需要五段数据： • TraceID：请求唯一标识符，由根span产生，贯穿请求的各个阶段。

低消耗 智能分析 定义了四个具体的设计目标 JTrace数据结构 核心数据结构由Span, Trace, 和 TraceId组成： • Trace: 多个Span的集合; • Span: RPC跟踪的基本单元; • SpanEvent：内部方法调用基本单元 • TraceId: • TransactionId (TxId) : 全局唯一消 息的ID • SpanId • ParentSpanId

CGO 调用 开销呈线性增长；CGO 中 增加 Go 自身计算逻辑时,其 Go 的计算消耗也呈线性增 长 CGO 开销调研 MoE 方案介绍 MoE 整体架构 MoE 功能职责 MoE TraceID 事例分析 MoE 方案优势 MoE 方案介绍 — 整体架构 GoLang L7 extension filter shim manager Stream filter Router 复用 Cluster LB • 复用 State 统计 Proxy-golang 扩展能力 • Proxy-golang API • Filter manager MoE 方案介绍 — TraceID 事例 Other http filter AntVip/Pilot Trace ID filter Other http filter(via GoLang) Header to metadata

网关处理身份验证、授权和将请求转发到分布式或查询前端服务。 Distributor - Distributor 接受多种格式（包括 Jaeger、OpenTelemetry 和 Zipkin）的 span。它通过哈希 traceID 并将分布式一致的哈希环路由到 Ingester。 Ingester - Ingester 将 trace 批处理到块中，创建 bloom 过滤器和索引，然后将其全部刷新 到后端。 Query ID。根据设置的参数，querier 组件可以查询 ingesters，并从后端拉取 bloom 或索引，以便在对象存储中搜索块。querier 组件在 GET /querier/api/traces/<traceID> 公开 HTTP 端点，但不预期直接使用它。查询必须发送到查询前端。 表 表 4.5. querier 组 组件的配置参数 件的配置参数 参数 参数 描述 描述 值 值 nodeSelector Platform 4.14 分布式追踪 分布式追踪 86 查询前端组件负责为传入的查询对搜索空间进行分片。查询前端通过简单的 HTTP 端点公开 trace：GET /api/traces/<traceID>。在内部，查询 frontend 组件将 blockID 空间分成可配置的分片数量，然后对这 些请求进行队列。querier 组件通过流 gRPC 连接连接到查询 frontend 组件，以处理这些分片查询。