作者：千习
背景简介
什么是定时工作
定时工作是业务利用零碎中存在定时周期性运行的业务逻辑。因为其运行于后端过程中往往存在执行状态和执行链路的不可见性《常见定时工作技术计划》。
https://developer.aliyun.com/…
什么是链路追踪
随着散布式微服务化架构在企业中大规模使用，业务运行的利用平台是一个由各个业务研发团队不同业务利用组合而成的庞杂系统工程，相互之间存在各种模式的拜访交互。
面对上述如此简单的系统结构，对于业务入口端利用而言所有的上游服务状态都是黑盒不可知的存在。相应的运维问题也随之而来：
- 入口服务不可用时，如何疾速定位具体是哪个服务节点不可用及起因？
- 如何疾速定位剖析业务链路中性能瓶颈点？
- 如何掌控业务链路残缺执行过程？
面对上述问题，从 Google 分布式链路追踪零碎的 Dapper 论文开启了各类分布式链路追踪的实现，呈现了很多相干零碎，如：Zipkin、Skywalking、Pinpoint。所有这些其外围逻辑就是在一次业务申请开始时构建相应申请的链路上下文信息，并在服务调用过程中透传欠缺相应的链路节点信息，最终通过该申请 TraceId（本次申请的链路标识）和每个节点父子依赖关系构建出一个残缺的调用链数据结构。
整个分布式全链路追踪平台各项次要分工：
- 利用侧实现服务调用埋点，常见形式：手动调用 SDK 埋点、java agent 模式主动埋点
- 服务之间通信交互，相应通信协议上须要增加 Trace 信息进行传递，保障在整个调用链中 Trace 信息共享
- Trace 信息上报至全链路追踪平台进行存储展示
基于上述几个次要环节，各个开源计划别离实现了各自在采集、传输、存储环节的不同数据结构。为实现链路追踪畛域范畴内数据结构对立，呈现了 OpenTracing 和 OpenTelemetry 来定义相应的标准和协定。
为什么定时工作须要链路追踪
剖析工作为什么执行失败
当业务一直倒退，业务开发的定时工作也会越来越趋于复杂化，定时工作执行过程中会倒退出如下各种状态：
- 会调用其余业务方各类上游应用服务
- 会调用其余中间件服务（如：redis、mq 等）
- 会切分出 N 个子工作分发给不同机器进行分布式并行批处理，每个子工作解决又是一整套简单组合
当面对此类简单定时工作场景下工作执行如果出现异常，相应的问题定位将变得很简单。在残缺的全链路追踪能力反对下，问题将能被疾速定位解决。
剖析工作为什么执行慢
个别场景下离线工作往往承当着大批量数据处理的业务场景，因此很多定时离线工作有运行耗时长的特色，往往在这些耗时长的工作上存在着微小的性能优化空间，性能晋升能间接优化根底资源应用效率并节俭业务老本。
在任务调度平台上咱们可通工作执行超时报警，再联合工作执行链路追踪能力可无效地锁定业务解决的耗时瓶颈点供进一步业务性能优化作为参考。
全链路流量管制
在全链路追踪体系下，能够进行后续其余能力拓展：
- 灰度公布：定时工作利用公布过程中的工作全链路灰度能力
- 全链路压测：定时工作通过业务测试标签参加全链路压测
- 流量隔离：定时工作调用上游服务，上游服务依据流量起源进行隔离解决
定时工作链路追踪解决方案
开源解决方案
从开源定时工作平台看，目前常见开源计划都未反对工作执行链路可视化查问，对简单工作或分片工作执行异样下的问题剖析会比拟艰难。
另外在开源链路追踪平台，对应开源计划中局部采集端 agent 集成了定时工作框架执行入口埋点采集，但该模式下与任务调度平台侧较为割裂，从负责定时工作运维的视角登程想具体锁定某一次工作执行链路，须要通过日志或依据执行工夫检索匹配相应的执行记录，当链路追踪平台上数据繁多想疾速惟一锁定目标链路存在很多不便。
阿里解决方案
阿里分布式任务调度平台 SchedulerX 提供了一站式的链路追踪解决方案，能够将工作执行信息与链路追踪 Trace 信息绑定，用户能够很不便的从任务调度侧，查看某个工作、某次执行、某个分片的残缺调用链。
阿里 SchedulerX 计划劣势：
- 精准定位工作执行 Trace 信息：常见链路追踪平台只负责工作执行的时候生成 traceId，不提供和具体任务的绑定关系，想要从成千上万的 traceId 中剖析某个工作的调用链变得非常复杂；SchedulerX 无论是单机工作还是分布式工作的某个分片，每一次调度都能疾速定位到调用链。
- 调度侧反对管制采样率：手动运行一次反对必采样、动静配置采样率。
- 免运维低成本：通过 EDAS 部署的 Java 业务利用人造反对定时工作 Trace 能力，无需自建链路追踪服务端平台和 agent 采集，升高业务老本，并且能够从任务调度侧一键跳转到调用链。
定时工作链路追踪客户案例
某电商业务定位工作执行慢
用户案例：目前电商业务场景下都基于微服务架构体系，定时工作运行波及的利用较多且链路较深，用户对某个工作运行慢时，心愿能疾速定位哪个业务利用方哪个业务性能是执行链路瓶颈点。
以下将展现如何剖析工作的执行耗时，工作触发执行后会调用屡次上游业务应用服务以实现整个业务逻辑，整个工作执行耗时较长。
如上图所示，惯例状况下一次执行 <5 秒，但最近两次次执行耗时 >15s，通过工作配置超时报警可监测到该执行记录超过预期执行工夫，对该执行记录的调用链路进入下一步剖析。
如上图所示，通过链路追踪主动跳转获取残缺调用链（同样自建平台者可拷贝 TraceId 查问锁定），从上图可剖析取得执行耗时占比拟高的业务利用和 IP，可锁定在上游业务利用 ServiceApplication 的保留用户信息服务呈现显著耗时。
某金融账户批处理定位执行异样
用户案例：某金融机构对老业务系统升级，需将所有客户账户信息进行定期批量迁徙降级解决至新零碎，每天会从老零碎中加载一批次账户信息在业务集群中散发解决，实现每个账户信息降级迁徙；当某个账户出现异常时，须要能疾速定位执行异样的地位和起因。
通过 SchedulerX 的 MapReduce 模型进行分布式跑批，每个子工作对应一个客户账户信息业务解决，可展现每个子工作的执行列表，并提供链路追踪、重跑、日志查看等性能。
如上图所示，当整个工作执行出现异常失败，进入子工作列表锁定失败的子工作（如：账号 1000002 解决失败）。
如上图所示，通过链路追踪主动调整至该子工作的残缺执行调用链（自建平台可拷贝 TraceId 查问锁定），可疾速定位业务解决异样地位所在的业务利用和 IP。
如上图所示，开展失败节点详情即可进一步获取失败内容信息（如案例：账号 1000002 在更新名称信息时字段超长），至此一个分布式批处理工作且存在多方服务调用的业务执行异样即可被疾速定位。
某游戏业务剖析 Http 执行链路
用户案例：某游戏业务零碎中其外部采纳了 C++、Go 等技术栈，SchedulerX 未提供相应语言 SDK 间接接入，用户则通过裸露 http 服务形式接入 SchedulerX 定时触发运行，并反对其实现 http 工作执行残缺调用链查看。
以下展现一个 http 服务被定时调度后，其外部还会进行上游多个利用业务服务调用。
通过上述执行链路即可取得一个 http 定时工作在整个业务集群中残缺的执行链路。如果单纯在链路追踪平台上来查问该 http 服务的调用链路时，往往会列举一堆申请记录且无奈疾速辨别是否是某个定时工作触发而来的。因而比照上述形式，对任务调度平台侧运维定时工作执行情况的场景下，SchedulerX 提供了更为清晰的工作执行链路追踪剖析入口。
总结
分布式任务调度平台 SchedulerX 无效地将用于微服务场景下的可视化全链路追踪能力引入至定时工作解决场景，这将大大晋升定时工作在运行时可观测能力，无效地帮忙定时工作执行过程中异样、耗时、执行卡住等问题的定位剖析。
相干链接
[1] 分布式任务调度 SchedulerX 接入全链路追踪
https://help.aliyun.com/docum…
*[ 2] 企业级分布式应用服务 EDAS*
https://help.aliyun.com/docum…
*[ 3] 利用实时监控服务 ARMS*
https://help.aliyun.com/produ…