苏宁大数据平台任务调度模块架构设计

1、苏宁大数据离线任务开发调度平台实践:任务调度模块架构设计2019-02-01 08:00:00 375 收藏 2作为国内最大的电商平台之一，苏宁每天要处理数量巨大的数据。为了更快速高效地处理这 些数据，苏宁调度平台采取了哪些措施呢本文是苏宁大数据离线任务开发调度平台实践系列文章之上篇，详解苏宁的任务调度模块。目录1.绪言tl2设计目标与主要功能t23.专业术语t34调度架构设计t55.服务重启和任务状态恢复t6Master Active 组合服务t7Master HA高可用设计t7Recover任务状态恢复设计t7API接口服务t97.后续tl01.绪言在上一篇文章苏宁大数据离线任务开发调度平

2、台实践中，从用户交互功能、任务调度、 任务执行、任务运维和对外服务等几方面，宏观层面进行了理论和实践的概述。产品的用户功能重点需要把握用户实际的任务开发运维需求，合理的规划设计产品功能，在 使用和运维上便于用户操作，降低用户的开发使用成本。简单的说就是主要保证用户任务、 任务流等关键元数据的配置信息的准确性，以及任务状态的查询和干预能力，技术上实现不 存在难点，在此不再详细说明。任务执行模块侧重于任务被领取后，如何根据任务类型选择不同的执行器(Executer)提交 任务执行，并将任务的执行状态及时准确的返回，由任务调度服务根据返回状态做相应的下 一步处理，除此以外还涉及到任务资源加载、任务配

3、置解析与转换、自身健康状态检查与汇 报、worker进程与任务子进程通信、任务隔离、对外接口服务等，这块将在后面一节再跟 大家详细分享。任务运维模块主要关注平台的自身稳定性、健壮性等各个指标的监控与预警、平台任务执行 异常的监控、任务运行诊断分析、动态扩缩容和应急降级等方面，涉及到的内容也很多，后 续章节会陆续跟大家分享。今天我们重点详细阐述苏宁大数据离线任务调度开发平台的核心模块一任务调度模块的架 构设计以及开发实践过程中的关键功能点。2设计目标与主要功能调度模块的核心目标要保证任务能够按照用户配置的调度时间、依赖关系准实时调度和执行, 同时也允许用户根据实际需要随时启动和停止任务调度，调整

4、任务执行计划。所谓准时实调 度，指的是调度模块会按照各个上线的任务流的调度时间生成调度执行计划，当触发时间到 了，平台会按照调度执行计划精确的生成任务流实例和任务实例。但是在任务执行上，并不 保证准实时的分配机器执行。实际上平台以整体资源使用情况为最高原则，并按照一定的限 流策略控制任务的执行，比如：任务优先级、任务组并发度、平台任务并发数、任务特定执 行时间等因素。在保证平台资源允许的情况下，尽量按时执行任务。为了保障任务的实时性， 必须保障任务资源的可用性和计划可控性。调度模块的主要核心服务功能包括以下几点：服务重启和任务状态恢复功能在调度服务重启、主备切换后，系统状态以及任务运行状态能否

5、准确的恢复。比如，主节点 崩溃或维护期间，发生状态变更的任务在主节点恢复以后，能否正确更新状态等等。Web API接口服务用户通过Web控制后台管理作业，而Web控制后台与Master服务器之间的交互透过Rest 服务来执行，Rest服务也可以给Web控制后台以外的其它系统提供服务(用于支持外部系 统和调度系统的对接)。另外为了便于监控和调查分析调度异常和问題，提供Master内存关 键信息的查询和人工干预的接口能力。数据信息缓存服务缓存上线任务流、任务、事件、系统配置、服务器的关键元数据信息，这些信息一般在任务 流上线后不会经常发生变更，没必要实时从数据库中读取。并对外提供这些元数据信息的同

6、 步接口服务，保证缓存信息与数据库的一致性。缓存任务流实例、任务实例、事件实例等中间状态信息，同时持久化到数据库中。便于在任 务状态切换、任务依赖执行快速找到对应的运行中的关键数据。并在任务实例数上升一定量 级以后可以快速的从內存中缓存的中间状态数据完成依赖检查和触发执行逻辑，降低对数据 库因为频繁访问造成的压力。任务调度服务主要负责上线任务流的配置检查、生成任务流执行计划、按照执行计划生成任务流与任务实 例，生成任务实例状态机和节点之间的依赖触发关系。除了这些系统调用主要功能外，还提 供人工干预任务执行的服务功能，比如：任务流上下线、任务补数据、任务重跑、任务杀死、 失败重试等任务状态机管理

7、任务流按照调度服务的执行计划会在每个调度周期内生成需要执行的任务流实例和任务实 例信息，这些实例在调度过程中存在多种临时状态，并具备一定的生命周期。状态切换的时 候触发一定的业务逻辑，比如：任务实例由新建状态切换到待分配状态，由待分配状态切换 到已分配状态，由执行中状态切换到执行结束状态都可能需要完成一定的处理。这里我们釆 用了状态机的管理机制来确保任务执行状态的持续性和完整性。任务状态分析服务任务实例在调度过程中存在多种临时状态的切换，每次状态切换必须成功才能保证状态变化 的持续性和完整性，从而保证任务实例从生成到结束的完整生命周期。如果状态切换过程中 发生意外或者长时间停滞在某个状态不变，

8、可能会导致调度异常和用户使用恐慌，为了准确 及时的分析任务实例的状态停滞原因，需要在任务状态生成和切换的时候进行检查校验，把 不能切换的原因及时记录，便于分析问题。任务状态发布服务平台上的任务处理的是数据，数据处理的及时性和准确性对业务系统是有极大的影响。而平 台的任务运行状态往往只会记录在本平台数据库中，外部系统无法感知。在很多场景下，业 务系统需要根据任务的执行状态来执行自己的特定业务逻辑，通过传统的任务状态查询接口 又存在延迟性和性能问題，比如：任务状态的变更，执行时间长短会因为多种因素而变得不 确定；多个外部系统调用平台接口可能会导致平台自身压力的不确定性。可以在任务实例生 成和状态切

9、换的时候，将任务实例状态按照用户的配置要求，及时的发布出去，业务系统根 据需要进行订阅，确保任务状态更新的及时性，又降低对平台的侵入和压力。任务分配与流控服务主要负责满足执行条件的任务实例的分配，以及在任务执行高峰、资源紧张的情况下如何智 能有效的进行相应的流控。在以整体资源使用情况为最高原则，并按照一定的限流策略控制 任务的执行，比如：任务优先级、任务组并发度、平台任务并发数、任务特定执行时间等因 素。在保证平台资源允许的情况下，尽量按时执行任务。为了保障任务的实时性，必须保障 任务资源的可用性和计划可控性。事件触发服务主要解决复杂业务场景里，跨任务流依赖、跨系统平台依赖的调度执行问题。比如

10、：平台内 部多个系统多个任务流之间的依赖调度，以及外部业务系统在某种条件下需要通知调度平台 执行自己的任务。另外需要解决各种频率之间的依赖关系，比如：天依赖天、天依赖小时、 周月依赖天等.主机健康监控服务负责管理可以执行任务的机器资源，并根据各机器的健康度合理的分配任务。主要包括： worker机器的发现与管理、worker机器的健康度评估、worker检活、主机黑白名单（加入 黑名单的机器不能领取和执行任务）等异步更新服务平台中存在大量的持久化操作，比如：任务实例的生成与状态更新、事件的触发实例生成、 任务流的启停状态、任齐运行状态原因分析等。有些持久化操作需要伴随业务逻辑同步更新, 确保操

11、作的事务完整性，比如：任务流上下线、任务实例的状态切换，必须保证内存和数据 库一致性。有些操作则不要求高度一致性和实时性，甚至有些数据的更新错误或者丢失也可 以忽略不计。同步更新在确保事务、数据的完整和一致性外，带来了平台性能的一定下降。 而异步更新服务可以提高平台的运行性能和并发能力，这些低有求的操作和数据同步服务就 可以采用异步更新服务来完成。比如：任务运行状态停滞原因分析、任务状态的对外发布等3.专业术语苏宁大数据离线任务开发调度平台具有和业内同款平台产品的共性，也具备自己的特殊性和 专业性。在理解和使用我们的平台之前，需要了解平台常见的专业术语，以免造成理解和使 用上的分歧。任务流实例

12、的中间运行状态，主要包括：待调度、执行中、执行失败、执行成功。任务实例的中间运行状态，主要包括：待调度、待分配、已分配、已领取、参数检查错误、 资源准备失败、执行中、杀死、执行失败、失败重试、执行成功、忽略失败。4调度架构设计）从系统架构的角度出发，模块化的设计有利于功能隔离，降低组件耦合度和单个组件的复杂 度，提升系统的可拓展性，一定程度上有利于提升系统稳定性，但带来的问题是开发调试会 更加困难，从这个角度来说又不利于稳定性的改进。所以各个功能模块拆不拆，怎么拆往往 是需要权衡考虑的。平台釆用常见的主从式架构，按照功能模块划分清晰，职责单一而不紧耦合，避免繁重复杂 的业务耦合设计。调度模块在

13、系统架构上分为web接口服务、重启恢复服务、数据缓存服务、 任务状态发布服务、事件触发服务、异步更新服务、任务调度服务、任务状态机管理、任务 分配服务、主机健康监控服务以及任务实例状态监听服务等十几个主要服务功能。每个服务 模块负责的功能清晰，互相耦合度低，具有良好的扩展性、稳定性和容错性。调度的整体架 构设计如下图所示。调度模块涉及到多种功能服务，这些功能服务內部涉及到大量复杂的、交互的事件处理、状 态转换，同时，这些事件调度和状态转换又对实时性和效率提出了极高的要求。可以想见, 没有一个规整的、通用型良好的调度器，平台代码无论是对读者，还是对开发者，都将变成 一场灾难，同时平台的运行效率也

14、会变得无法忍受。统一的、设计良好的、通用的和共用的 调度器，对于调度模块不同组件的开发者来说是一种解脱，大大降低了平台在事件调度、状 态转换的底层出错的可能性，提高了代码稳定性和可读性。如何组装、如何进行有效的接口调用来支撑平台百万级的任务高效稳定的执行。在组装设计 上需要慎重选型。一般多服务调用分为函数调用和事件驱动两种模式。相比于基于函数调用的编程模型，这种编程方式具有异步、并发等特点，更加高效，因此更 加适合大型分布式系统。调度模块的十几个服务之间的大部分服务调用也基本是基于事件驱 动的编程模型进行设计。开发实践过程中，血doop的核心调度器AsyncDispatcher的设计 和实现同

15、Hadoop状态机一样，这个通用调度器设计得十分通用，完美可扩展可重用，我们 在自己的项目中完全可以使用Hadoop的调度器实现我们自己的事件调度逻辑。5.服务重启和任筝状态恢复该服务主要是将调度模块的所有服务组件进行统一的注册和管理，并按照平台的业务逻辑顺 序进行顺序初始化和启动。并通过HAService服务往ZK抢注Master的服务器节点目录，来 完成主备Master的状态切换。通过RecoverService服务完成从数据库中同步任务流、任 务、事件等元数据信息和任务实例、事件实例等实例信息的内存恢复操作。根据任务实例的 数据库和zk中保存的状态进行任务状态机的创建和后续状态的持续触发

16、操作。Master Active组合服务如前文所述，调度模块包括了十几个核心功能服务，如何有效的管理和协同这些服务的起停 顺序、服务之间的调度关系，我们在Java设计模式上采用了组合模式（Composite）,将这十 几个服务按照调度的业务关系进行了组合包装。Hadoop Yarn的CompositeService提供了 一个比较好的组合封装服务，包括服务的注册（添 加和移出）、服务的初始化和启停操作，这些服务被顺序的保存在一个List对象中，各个服 务会按照顺序进行逐个初始化和启停。调度模块的这十几个关键服务统一打包在 MasterActiveService 中。Master HA高可用设计

17、高可用性.（HighAvailability）指的是通过尽量缩短因日常维护操作（计划）和突发的系 统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。HA系统是目前企业防 止核心计算机系统因故障停机的最有效手段。在HA方面，按照准实时的设计目标，平台并没有打算做到秒级别的崩溃恢复速度，系统崩 溃时，只要能在分钟级别范围内，重建系统状态，就基本能满足系统的设计目标需求。所以其实高可用性设计的重点，关键在于重建的过程中，系统的状态能否准确的恢复。比如， 主节点崩溃或维护期间，发生状态变更的任务在主节点恢复以后，能否正确更新状态等等。 而双机热备份无缝切换，目前来看实现难度较大(太多流程需要

18、考虑原子操作，数据同步和 避免竞争冲突)，实际需求也不强烈，通过监控，自动重启和双机冷备的方式来加快系统重 建速度，基本也就足够了。本平台在设计的时候采用了 主从方式”实现HA,主要设计要点：(1) 一个状态管理功能模块实现一个zkFailover,常驻在每一个Master服务节点内，每一个failover负责监听自己 所在节点，利用zk进行状态标识。当需要进行状态切换时，由zkFailover实现状态切换, 切换时需要注意防止brain split现象发生。(2)对外服务方式除了 HAService服务外，只能有一个Master节点可以托管和执行其他所有服务。另外一个 节点只能启动HASer

19、vice监听主节点的状态。只有主节点停止服务后，才能启动其他服务进 行工作。Recover任务状态恢复设计在调度服务重启、主备切换后，系统状态以及任务运行状态能否准确的恢复。比如，主节点 崩溃或维护期间，发生状态变更的任务在主节点恢复以后，能否正确更新状态等等是一个任 务调度平台的重要功能和考核指标。Recover不仅需要恢复各种实例信息的元数据信息和状态信息，确保每个任务实例状态切换 的连续性、完整性和正确性，还要保证每个任务流内部各个节点之间按照依赖关系及时的触 发和正确执行。在某些场景下，还需要对因为调度服务停止期间遗漏的任务流和任务实例 进行补偿。第一步完成任务配置相关的元数据信息的恢

20、复。即从数据库中同步必要的元数据信息到调度内存中。元数据信息在数据库中不是存放了 一份, 为什么还要从数据库中同步一份到调度的内存中呢在任务量很少的情况下每次读写数据库 不会对数据库造成压力。但是在任务量上升，任务实例的生成量和状态切换的量成几何级上 升，随着对数据库的读写TPS也会上升。这样一方面可能会造成数据库的压力偏大，另一方 面如果数据库服务不稳定、网络抖动等外部因素而导致调度服务卡住。在大多数情况下，任务流一旦上线后不会轻易发生变更。如果有部分变动，可以通过辰ster 的web接口同步内存和数据库的配置信息。为了保证状态的一致统一，和任务相关的信息变 更，无论是用户发起的作业配置修改

21、，还是执行器反馈的作业状态变更，都会提交给Master 节点同步写入到数据库。具体参考下图。第二步完成实例信息和任务状态的恢复。实例信息的恢复主要包括：任务流实例、任务实例、事件实例的状态恢复，已经结束的任务 流实例信息不作为恢复的对象。这一步不仅仅的单纯同步实例的信息到调度内存里，更重要 的是要恢复任务实例的状态，确保任务执行按照计划和依赖关系正确的执行下去。任务流实例是按照任务流的执行计划不断生成的运行个体。当重启扫描数据中未执行结束” 的任务流实例时，可能会存在大量的实例个体，执行恢复的时候，智能根据“未执行结束” 的任务流实例个数启动一定数量的线程，按照任务流实例进行切分，进行批量恢复

22、。第三步补偿丢失的任务实例批次Master调度重启或者服务器宕机等因素造成任务调度计划被打断，再次恢复后需要对服务 终止期间的丢失的任务实例进行补偿，否则会造成某些任务执行计划被错过而没有得到调度 执行，引发数据故障。）根据故障恢复的时间长短，结合每个频率的任务做出不同的补偿措施。下表是根据不同频率 类型按照对应策略进行补偿。对于一些复杂的业务场景的任务，也不是必须要把所有遗漏的批次都补偿完毕，可以适当补 偿一些遗漏批次，其他遗漏批次在服务重启后人工补偿。如果把历史遗漏批次都补偿，可能 会因为补偿的实例数过多而导致当前批次被延后执行。API接口服务用户通过Web控制后台管理作业，而Web控制后台与Master服务器之间的交互透过Rest 服务来执行，Rest服务也可以给Web控制后台以外的其它系统提供服务（用于支持外部系 统和调度系统的对接）。另外为了便于监控和调查分析调度异常和问題，提供Master内存关 键信息的查询和人工干预的接口能力。考虑到调度模块的代码部署不依赖外部容器，比如：Tomcat, JBoss等，又要对外提供Web 接口服务，因此在技术选型上需要注意这一点。目前市场上流行的SpringBoot.内嵌Jettty 等其他Serv