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

苏宁大数据离线任务开发调度平台实践：任务调度模块架构设计2019-02-01 08:00:00 375 收藏 2作为国内最大的电商平台之一，苏宁每天要处理数量巨大的数据。为了更快速高效地处理这 些数据，苏宁调度平台采取了哪些措施呢本文是苏宁大数据离线任务开发调度平台实践系列文章之上篇，详解苏宁的任务调度模块目录1. 绪言tl2设计目标与主要功能t23. 专业术语t34. 调度架构设计t55. 服务重启和任务状态恢复t6Mas ter Act ive 组合服务t7Mas ter HA髙可用设计t7Recover任务状态恢复设计t7API接口服务t97.后续tlO1.绪言在上一篇文章苏宁大数据离线任务开发调度平台实践中，从用户交互功能、任务调度 任务执行、任务运维和对外服务等几方面，宏观层面进行了理论和实践的概述。产品的用户功能重点需要把握用户实际的任务开发运维需求，合理的规划设计产品功能，在 使用和运维上便于用户操作，降低用户的开发使用成本。简单的说就是主要保证用户任务 任务流等关键元数据的配置信息的准确性，以及任务状态的查询和干预能力，技术上实现不 存在难点，在此不再详细说明。任务执行模块侧重于任务被领取后，如何根据任务类型选择不同的执行器(Executer)提交 任务执行，并将任务的执行状态及时准确的返回，由任务调度服务根据返回状态做相应的下 一步处理，除此以外还涉及到任务资源加载、任务配置解析与转换、自身健康状态检查与汇 报、worker进程与任务子进程通信、任务隔离、对外接口服务等，这块将在后面一节再跟 大家详细分享。【任务运维模块主要关注平台的自身稳定性、健壮性等各个指标的监控与预警、平台任务执行 异常的监控、任务运行诊断分析、动态扩缩容和应急降级等方面，涉及到的内容也很多，后 续章节会陆续跟大家分享。今天我们重点详细阐述苏宁大数据离线任务调度开发平台的核心模块任务调度模块的架 构设计以及开发实践过程中的关键功能点。2. 设计目标与主要功能 调度模块的核心目标要保证任务能够按照用户配置的调度时间、依赖关系准实时调度和执行， 同时也允许用户根据实际需要随时启动和停止任务调度，调整任务执行计划。所谓准时实调 度，指的是调度模块会按照各个上线的任务流的调度时间生成调度执行计划，当触发时间到 了，平台会按照调度执行计划精确的生成任务流实例和任务实例。但是在任务执行上，并不 保证准实时的分配机器执行。实际上平台以整体资源使用情况为最高原则，并按照一定的限 流策略控制任务的执行，比如：任务优先级、任务组并发度、平台任务并发数、任务特定执 行时间等因素。在保证平台资源允许的情况下，尽量按时执行任务。为了保障任务的实时性， 必须保障任务资源的可用性和计划可控性。#调度模块的主要核心服务功能包括以下几点：服务重启和任务状态恢复功能 在调度服务重启、主备切换后，系统状态以及任务运行状态能否准确的恢复。比如，主节点 崩溃或维护期间，发生状态变更的任务在主节点恢复以后，能否正确更新状态等等。Web API接口服务用户通过Web控制后台管理作业，而Web控制后台与Mas ter服务器之间的交互透过Rest 服务来执行，Rest服务也可以给Web控制后台以外的其它系统提供服务(用于支持外部系 统和调度系统的对接)。另外为了便于监控和调查分析调度异常和问题，提供Mas ter内存关 键信息的查询和人工干预的接口能力。(数据信息缓存服务 缓存上线任务流、任务、事件、系统配置、服务器的关键元数据信息，这些信息一般在任务 流上线后不会经常发生变更，没必要实时从数据库中读取。并对外提供这些元数据信息的同 步接口服务，保证缓存信息与数据库的一致性。缓存任务流实例、任务实例、事件实例等中间状态信息，同时持久化到数据库中。便于在任 务状态切换、任务依赖执行快速找到对应的运行中的关键数据。并在任务实例数上升一定量 级以后可以快速的从内存中缓存的中间状态数据完成依赖检查和触发执行逻辑，降低对数据 库因为频繁访问造成的压力。任务调度服务 主要负责上线任务流的配置检查、生成任务流执行计划、按照执行计划生成任务流与任务实 例，生成任务实例状态机和节点之间的依赖触发关系。除了这些系统调用主要功能外，还提 供人工干预任务执行的服务功能，比如：任务流上下线、任务补数据、任务重跑、任务杀死、 失败重试等任务状态机管理 任务流按照调度服务的执行计划会在每个调度周期内生成需要执行的任务流实例和任务实 例信息，这些实例在调度过程中存在多种临时状态，并具备一定的生命周期。状态切换的时 候触发一定的业务逻辑，比如：任务实例由新建状态切换到待分配状态，由待分配状态切换 到已分配状态，由执行中状态切换到执行结束状态都可能需要完成一定的处理。这里我们采 用了状态机的管理机制来确保任务执行状态的持续性和完整性。任务状态分析服务 任务实例在调度过程中存在多种临时状态的切换，每次状态切换必须成功才能保证状态变化 的持续性和完整性，从而保证任务实例从生成到结束的完整生命周期。如果状态切换过程中 发生意外或者长时间停滞在某个状态不变，可能会导致调度异常和用户使用恐慌，为了准确 及时的分析任务实例的状态停滞原因，需要在任务状态生成和切换的时候进行检查校验，把 不能切换的原因及时记录，便于分析问题。任务状态发布服务 平台上的任务处理的是数据，数据处理的及时性和准确性对业务系统是有极大的影响。而平 台的任务运行状态往往只会记录在本平台数据库中，外部系统无法感知。在很多场景下，业 务系统需要根据任务的执行状态来执行自己的特定业务逻辑，通过传统的任务状态查询接口 又存在延迟性和性能问题，比如：任务状态的变更，执行时间长短会因为多种因素而变得不 确定；多个外部系统调用平台接口可能会导致平台自身压力的不确定性。可以在任务实例生 成和状态切换的时候，将任务实例状态按照用户的配置要求，及时的发布出去，业务系统根 据需要进行订阅，确保任务状态更新的及时性，又降低对平台的侵入和压力。任务分配与流控服务 主要负责满足执行条件的任务实例的分配，以及在任务执行高峰、资源紧张的情况下如何智 能有效的进行相应的流控。在以整体资源使用情况为最高原则，并按照一定的限流策略控制 任务的执行，比如：任务优先级、任务组并发度、平台任务并发数、任务特定执行时间等因 素。在保证平台资源允许的情况下，尽量按时执行任务。为了保障任务的实时性，必须保障 任务资源的可用性和计划可控性。事件触发服务 主要解决复杂业务场景里，跨任务流依赖、跨系统平台依赖的调度执行问题。比如：平台内 部多个系统多个任务流之间的依赖调度，以及外部业务系统在某种条件下需要通知调度平台 执行自己的任务。另外需要解决各种频率之间的依赖关系，比如：天依赖天、天依赖小时、 周月依赖天等.主机健康监控服务负责管理可以执行任务的机器资源 ,并根据各机器的健康度合理的分配任务。主要包括： worker机器的发现与管理、worker机器的健康度评估、worker检活、主机黑白名单（加入 黑名单的机器不能领取和执行任务）等异步更新服务 平台中存在大量的持久化操作，比如：任务实例的生成与状态更新、事件的触发实例生成、 任务流的启停状态、任务运行状态原因分析等。有些持久化操作需要伴随业务逻辑同步更新， 确保操作的事务完整性，比如：任务流上下线、任务实例的状态切换，必须保证内存和数据 库一致性。有些操作则不要求高度一致性和实时性，甚至有些数据的更新错误或者丢失也可 以忽略不计。同步更新在确保事务、数据的完整和一致性外，带来了平台性能的一定下降。 而异步更新服务可以提高平台的运行性能和并发能力，这些低有求的操作和数据同步服务就 可以采用异步更新服务来完成。比如：任务运行状态停滞原因分析、任务状态的对外发布等3. 专业术语 苏宁大数据离线任务开发调度平台具有和业内同款平台产品的共性，也具备自己的特殊性和 专业性。在理解和使用我们的平台之前，需要了解平台常见的专业术语，以免造成理解和使 用上的分歧。任务流实例的中间运行状态，主要包括：待调度、执行中、执行失败、执行成功。任务实例的中间运行状态，主要包括：待调度、待分配、已分配、已领取、参数检查错误、 资源准备失败、执行中、杀死、执行失败、失败重试、执行成功、忽略失败。4. 调度架构设计） 从系统架构的角度出发，模块化的设计有利于功能隔离，降低组件耦合度和单个组件的复杂 度，提升系统的可拓展性，一定程度上有利于提升系统稳定性，但带来的问题是开发调试会 更加困难，从这个角度来说又不利于稳定性的改进。所以各个功能模块拆不拆，怎么拆往往 是需要权衡考虑的。平台采用常见的主从式架构，按照功能模块划分清晰，职责单一而不紧耦合，避免繁重复杂 的业务耦合设计。调度模块在系统架构上分为web接口服务、重启恢复服务、数据缓存服务、 任务状态发布服务、事件触发服务、异步更新服务、任务调度服务、任务状态机管理、任务 分配服务、主机健康监控服务以及任务实例状态监听服务等十几个主要服务功能。每个服务 模块负责的功能清晰，互相耦合度低，具有良好的扩展性、稳定性和容错性。调度的整体架 构设计如下图所示。调度模块涉及到多种功能服务，这些功能服务内部涉及到大量复杂的、交互的事件处理、状 态转换，同时，这些事件调度和状态转换又对实时性和效率提出了极高的要求。可以想见， 没有一个规整的、通用型良好的调度器，平台代码无论是对读者，还是对开发者，都将变成 一场灾难，同时平台的运行效率也会变得无法忍受。统一的、设计良好的、通用的和共用的 调度器，对于调度模块不同组件的开发者来说是一种解脱，大大降低了平台在事件调度、状 态转换的底层出错的可能性，提高了代码稳定性和可读性。如何组装、如何进行有效的接口调用来支撑平台百万级的任务高效稳定的执行。在组装设计 上需要慎重选型。一般多服务调用分为函数调用和事件驱动两种模式。(2)对外服务方式除了 HAService服务外，只能有一个Mas ter节点可以托管和执行其他所有服务。另外一个 节点只能启动HAService监听主节点的状态。只有主节点停止服务后，才能启动其他服务进 行工作。Recover任务状态恢复设计 在调度服务重启、主备切换后，系统状态以及任务运行状态能否准确的恢复。比如，主节点 崩溃或维护期间，发生状态变更的任务在主节点恢复以后，能否正确更新状态等等是一个任 务调度平台的重要功能和考核指标。Recover不仅需要恢复各种实例信息的元数据信息和状态信息，确保每个任务实例状态切换 的连续性、完整性和正确性，还要保证每个任务流内部各个节点之间按照依赖关系及时的触 发和正确执行。在某些场景下，还需要对因为调度服务停止期间遗漏的任务流和任务实例 进行补偿。)第一步完成任务配置相关的元数据信息的恢复。即从数据库中同步必要的元数据信息到调度内存中。元数据信息在数据库中不是存放了一份 为什么还要从数据库中同步一份到调度的内存中呢在任务量很少的情况下每次读写数据库 不会对数据库造成压力。但是在任务量上升，任务实例的生成量和状态切换的量成几何级上 升，随着对数据库的读写TPS也会上升。这样一方面可能会造成数据库的压力偏大，另一方 面如果数据库服务不稳定、网络抖动等外部因素而导致调度服务卡住。在大多数情况下，任务流一旦上线后不会轻易发生变更。如果有部分变动，可以通过Mas ter 的web接口同步内存和数据库的配置信息。为了保证状态的一致统一，和任务相关的信息变 更，无论是用户发起的作业配置修改，还是执行器反馈的作业状态变更，都会提交给Mas ter 节点同步写入到数据库。具体参考下图。第二步完成实例信息和任务状态的恢复。实例信息的恢复主要包括：任务流实例、任务实例、事件实例的状态恢复，已经结束的任务 流实例信息不作为恢复的对象。这一步不仅仅的单纯同步实例的信息到调度内存里，更重要 的是要恢复任务实例的状态，确保任务执行按照计划和依赖关系正确的执行下去。任务流实例是按照任务流的执行计划不断生成的运行个体。当重启扫描数据中“未执行结束” 的任务流实例时，可能会存在大量的实例个体，执行恢复的时候，智能根据“未执行结束” 的任务流实例个数启动一定数量的线程，按照任务流实例进行切分，进行批量恢复。第三步补偿丢失的任务实例批次Mas ter调度重启或者服务器宕机等因素造成任务调度计划被打断，再次恢复后需要对服务终止期间的丢失的任务实例进行补偿，否则会造成某些任务执行计划被错过而没有得到调度 执行，引发数据故障。） 根据故障恢复的时间长短，结合每个频率的任务做出不同的补偿措施。下表是根据不同频率 类型按照对应策略进行补偿。对于一些复杂的业务场景的任务，也不是必须要把所有遗漏的批次都补偿完毕，可以适当补 偿一些遗漏批次，其他遗漏批次在服务重启后人工补偿。如果把历史遗漏批次都补偿，可能 会因为补偿的实例数过多而导致当前批次被延后执行。API接口服务用户通过Web控制后台管理作业，而Web控制后台与Mas ter服务器之间的交互透过Rest 服务来执行，Rest服务也可以给Web控制后台以外的其它系统提供服务（用于支持外部系 统和调度系统的对接）。另外为了便于监控和调查分析调度异常和问题，提供Mas ter内存关 键信息的查询和人工干预的接口能力。考虑到调度模块的代码部署不依赖外部容器，比如：Tomcat、JBoss等，又要对外提供Web 接口服务，因此在技术选型上需要注意这一点。目前市场上流行的SpringBoot、内嵌Jettty 等其他 Servlet 容器方案都可以解决这个问题。我们的平台使用的架构是 Jersey+Guice+Jetty+ Mybatis, jersey 作为 Rest 服务框架，Guice 作为 DI 框架，使用内 嵌Jetty作为应用容器，Mybatis负责数据库的持久化操作，并舍弃配置，这样使得开发和 部署十分轻量和简单。下图是调度模块里各个服务、容器、上下文之间的访问交互图。Master 上下文承载了配置文件、注册服务的查找与发现、元数据和实例数据信息以及各个 服务的调用转发器(Dispa tcher)。其他服务组件通过Mas ter上下文可以很方便的获取系统 配置信息，调用其他组件接口。Guice框架目前主要托管了数据库相关操作类以及web服务 接口类，被托管的服务类以单例的形式保存。整个调度模块内嵌了 Jetty容器，部署和启动 了 Webserver服务，提供外部与Mas ter内部服务的交互入口。7.后续上述文章讲述了调度模块的架构设计、恢复和web服务，后续文章会接着讲述调度服务的设 计细节。调度服务是整个调度模块非常核心的服务组件，涉及到任务流上下线、任务状态机 管理、任务重跑补数据等运维操作，限于篇幅和时间问题，本次的调度模块的分享先写这么 多，后续会陆续对其他服务组件进行详细阐述，敬请期待。作者桑强：苏宁易购IT总部大数据平台研发中心离线计算工具研发部经理。10年软件行业从业 背景，13 年开始接触大数据，有着 5 年多的大数据应用和平台开发经验。现在负责苏宁大 数据基础工具平台的研发工作，主要包括离线计算工具、实时计算工具、数据资产与质量平 台的架构、研发和项目管理等工作。在对接大数据底层和大数据业务线之间，如何做好平台 工具化，降低用户使用难度，支撑大数据应用的实践和研发上有着丰富的研发经验。原文链接：