作者：千习
背景简介
什么是守时使命
守时使命是事务使用体系中存在守时周期性运转的事务逻辑。由于其运转于后端进程中往往存在履行状态和履行链路的不行见性《常见守时使命技能方案》。
developer.aliyun.com/article/882…
什么是链路追寻
随着分布式微服务化架构在企业中大规划运用，事务运转的使用渠道是一个由各个事务研制团队不同事务使用组合而成的杂乱体系工程，相互之间存在各种形式的拜访交互。
面临上述如此杂乱的体系结构，对于事务进口端使用而言一切的下流服务状态都是黑盒不行知的存在。相应的运维问题也随之而来：
- 进口服务不行用时，怎么快速定位详细是哪个服务节点不行用及原因？
- 怎么快速定位剖析事务链路中功用瓶颈点？
- 怎么掌控事务链路完好履行过程？
面临上述问题，从 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 接入全链路追寻
help.aliyun.com/document_de…
[ 2] 企业级分布式使用服务 EDAS
help.aliyun.com/document_de…
[ 3] 使用实时监控服务 ARMS
help.aliyun.com/product/343…
