分布式错误处理 第四部分 为什么定位慢？-- 分布式错误 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,�

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层

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产生，贯穿请求的各个阶段。

context Trace落地—结合滴滴情况落地 Trace应用 —调用链路跟踪 Trace应用 —调用链路跟踪 Trace应用 —场景还原 ③ 时间顺序还原操作序列 ① 业务id和traceid关联 ② 根span具有业务代表性 ④ 可下钻到具体trace 透传通路 存储检索优化 能力建设 规划 Thanks

服务拓扑图 正交，模块化 相关性 多租户 天机阁2.0 架构 13 天机阁2.0 实践 14 分布式追踪 天机阁2.0 实践 15 分布式追踪 Log详情 点击Log详情中traceID字段的按 钮拉起Trace详情。 天机阁2.0 实践 16 分布式追踪 监控面板 监控到错误码111，点击面板跳转 到相关时间段的分布式追踪 感谢倾听

or via Kubernetes Autoscaler Observability - Logging • Based on Uber zap • Auto logging with TraceID、ServiceName、Framework Version… • Structured logging for friendly searching • Extract business

(Resource Timing & Navigation Timing API) 报告: ⻚⾯性能 Ajax性能 ⻚⾯错误 特点: ⽆埋点的实现⽅案 运⾏时拓扑 访问明细: TraceId SpanId 报告: 实时⽹络拓扑图 实时调⽤延迟展示 特点: 实时反应系统状况 运营决策 视⻆: 系统资源使⽤，系统健康度 报告: 周报 ⽇报 ⼤盘 特点: 提供⾼视⻆的IT运营决策分析

x:port, 进行开发调试，上云后 需要与Mesher使用时，改为http://ServiceName • 服务调用层级不要超过3层 • 若调用层级超过2层，业务代码想要用上调用链追踪需要将TraceID转发 • 想要根据某些业务数据进行路由的话，将数据放在请求的header当中 • 业务开发期不要上云后就打开容错功能，容错会掩盖业务问题 6/30/2018 Take Away • 一个商用级SERVICE