龙华建设发展有限公司网站,企业大全官网,网站备案证件,软件开发项目管理工具背景简介
什么是定时任务
定时任务是业务应用系统中存在定时周期性运行的业务逻辑。由于其运行于后端进程中往往存在执行状态和执行链路的不可见性《常见定时任务技术方案》。
什么是链路追踪
随着分布式微服务化架构在企业中大规模运用#xff0c;业务运行的应用平台是一…背景简介
什么是定时任务
定时任务是业务应用系统中存在定时周期性运行的业务逻辑。由于其运行于后端进程中往往存在执行状态和执行链路的不可见性《常见定时任务技术方案》。
什么是链路追踪
随着分布式微服务化架构在企业中大规模运用业务运行的应用平台是一个由各个业务研发团队不同业务应用组合而成的庞杂系统工程相互之间存在各种形式的访问交互。 面对上述如此复杂的系统结构对于业务入口端应用而言所有的下游服务状态都是黑盒不可知的存在。相应的运维问题也随之而来
入口服务不可用时如何快速定位具体是哪个服务节点不可用及原因如何快速定位分析业务链路中性能瓶颈点如何掌控业务链路完整执行过程
面对上述问题从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有效地将用于微服务场景下的可视化全链路追踪能力引入至定时任务处理场景这将大大提升定时任务在运行时可观测能力有效地帮助定时任务执行过程中异常、耗时、执行卡住等问题的定位分析。
原文链接
本文为阿里云原创内容未经允许不得转载。
