软件需求规格说明书

1、_<任务调度中心后台管理系统>需求规格说明书-可编辑修改 -_作者：完成日期：-可编辑修改 -_修订历史记录日期版本说明作者V1.0-可编辑修改 -_目录-可编辑修改 -_1.引言.71.1目的 .71.2背景 .81.3概述 .81.4参考文献 .82.项目概述 .82.1产品特性 .82.2产品设计理念 .112.3用户特点 .112.4一般约束 .112.5假设与依据 .123.总体设计 .123.1架构设计 .123.1.1 设计思想 .123.1.2系统组成 .123.1.3架构图 .133.1.4调度中心 HA( 集群 ) .133.1.5调度线程池 .143.1.6日

2、志回调任务 .143.1.7调度日志 .153.1.8任务依赖 .163.1.9通讯数据加密 .16-可编辑修改 -_3.2.0分片广播、动态分片 .163.2.1访问令牌（ AccessToken ） .173.2.2故障转移、失败重试 .173.2.3任务超时控制 .184.系统功能 .184.1功能需求 .184.1.1系统角色及登陆 .184.1.2工作流程 .194.2外部接口需求 .204.2.1用户接口 .204.2.2硬件接口 .204.2.3软件接口 .204.2.4通信接口 .204.3性能需求 .204.4属性 .214.4.1可用性 .214.4.2安全性 .21-可编

3、辑修改 -_1. 引言1.1 目的该文档首先给出项目的整体结构和功能结构概貌，试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。本文档面向多种读者对象：（ 1 ）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。（ 2 ）设计员：对需求进行分析，并设计出系统，包括数据库的设计。（ 3 ）程序员：了解系统功能，编写用户手册。（ 4 ）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。（ 5 ）用户：了

4、解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。-可编辑修改 -_1.2 背景本次待开发的软件为任务调度中心后台管理系统。用户通过使用该系统在移动终端完成任务分配等操作。1.3 概述该平台是一个轻量级分布式任务调度平台，其核心设计是统一管理任务调度平台上调度任务，负责出发调度执行，并且提供任务管理平台。1.4 参考文献1 GB-T8567-2006，计算机软件文档编制规范S2. 项目概述2.1 产品特性1、简单：支持通过Web 页面对任务进行CRUD 操作，操作简单，容易上手；2 、动态

5、：支持动态修改任务状态、暂停/恢复任务，以及终止运行中任务，即时生效；3、调度中心HA （中心式）：调度采用中心式设计，“调度中心”基于集群Quartz 实现并支持集群部署，可保证调度中心HA；4、执行器HA （分布式）：任务分布式执行，任务"执行器 "支持集群部署，可保证任务执行 HA ；-可编辑修改 -_5、注册中心 : 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；6、弹性扩容缩容： 一旦有新执行器机器上线或者下线，下次调度时将会重新分配任务；7、路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后

6、一个、轮询、随机、一致性HASH 、最不经常使用、最近最久未使用、故障转移、忙碌转移等；8、故障转移：任务路由策略选择"故障转移 "情况下，如果执行器集群中某一台机器故障，将会自动Failover 切换到一台正常的执行器发送调度请求。9、失败处理策略；调度失败时的处理策略，策略包括：失败告警、失败重试；10、失败重试：调度中心调度失败且启用" 调度失败重试"策略时，将会自动重试一次；执行器执行失败且启用"执行失败重试" 策略，或回调失败重试状态时，也将会自动重试一次；11、阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包

7、括：单机串行（默认）、丢弃后续调度、覆盖之前调度；12、任务超时控制：支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；13、分片广播任务：执行器集群部署时，任务路由策略选择"分片广播 "情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；14、动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。-可编辑修改 -_15、事件触发：除了"Cron 方式 " 和"任务依赖方式"触发

8、任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的API服务，可根据业务事件灵活触发。16、任务进度监控：支持实时监控任务进度；17、 Rolling 实时日志：支持在线查看调度结果，并且支持以Rolling 方式实时查看执行器输出的完整的执行日志；18、 GLUE ：提供 Web IDE ，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30 个版本的历史版本回溯。19、脚本任务：支持以 GLUE 模式开发和运行脚本任务，包括 Shell 、Python 、NodeJS等类型脚本 ;20、任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功

9、后将会主动触发一次子任务的执行, 多个子任务用逗号分隔；21、一致性： “调度中心”通过DB 锁保证集群分布式调度的一致性, 一次任务调度只会触发一次执行；22、自定义任务参数：支持在线配置调度任务入参，即时生效；23、调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；24、数据加密： 调度中心和执行器之间的通讯进行数据加密，提升调度信息安全性；25、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；26、推送maven中央仓库 : 将会把最新稳定版推送到maven中央仓库 , 方便用户接入和使用 ;27、运行报表：支持实时查看运行数据，如任务数量、调度次数、

10、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；-可编辑修改 -_28、全异步：系统底层实现全部异步化，针对密集调度进行流量削峰，理论上支持任意时长任务的运行；2.2 产品设计理念当前各大行业人群密集，因大量繁琐的任务分配不及时而困扰，繁琐的根源便是邮件的收发、电话沟通，需要人工分配任务，最终人工汇总表格，工作量大且出错率高。任务调度中心系统致力于通过平台便捷地完成此项工作，且大大降低出错率。2.3 用户特点本系统的最终用户群体普遍接受高等教育，学习及适应能力强。能快速适应该软件，并充分感受到在任务调度中心的效能变化，提出合理改进意见。操作人员及维护人员为了解该工作的整体流程，

11、深入用户交流，便于调整软件功能，实现客户需求。2.4 一般约束进行本系统开发工作的约束条件如下：1.开发周期短：两个月的开发时间需要开发者合理规划时间，做到多项任务并发。2.所采用的方法与技术有限：项目团队成员的技术水平不够成熟，需要在开发中并发学习多种技术和能力。-可编辑修改 -_2.5 假设与依据本项目是否能够成功实施，主要取决于以下的条件：（ 1 ）团队成员的积极合作配合，为了项目的开发和实施，对个人时间进行合理规划同时为团队做出合理牺牲，配合队友完成任务。（ 2 ）完整详细的功能和性能需求资料，以便于团队对其进行分析，从而形成完善的软件需求。（ 3 ）团队掌握先进的能够适用于该项目的技

12、术，这是系统的性能是否优化和项目能否成功的保证。3.总体设计3.1 架构设计设计思想将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。将任务抽象成分散的JobHandler ，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；系统组成调度模块（调度中心）： 负责管理调度信息，按照调度配置发出调度请求，自身不承-可编辑修改 -_担业务代码。 调度系统与任务解耦，提高了系统可用性和稳定性，同时调度系统性能不再受限于任务模块；支持可视化、

13、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE 开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器Failover 。执行模块（执行器）： 负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效；接收“调度中心”的执行请求、终止请求和日志请求等。架构图调度中心 HA( 集群 )基于 Quartz 的集群方案， 数据库选用Mysql ；集群分布式并发环境中使用QUARTZ定时任务调度， 会在各个节点会上报任务，存到数据库中， 执行时会从数据库中取出触发器来-可编辑修改 -_执行，如果触发器的名称和执行时间相同，

14、则只有一个节点去执行此任务。调度线程池调度采用线程池方式实现，避免单线程因阻塞而引起任务调度延迟。任务调度中心系统中业务逻辑在远程执行器执行，全异步化设计， 调度中心每次触发调度时仅发送一次调度请求，执行器会将请求存入执行队列并且立即响应调度中心，异步运行；相比直接在quartz 的 QuartzJobBean中执行业务逻辑，极大的降低了调度线程占用时间；任务调度中心系统中每个逻辑非常“轻”，单个一次运行平均耗时基本在"10ms"之内（基本为一次请求的网络开销）；因此，可以保证使用有限的线程支撑大量的并发运行；理论支撑任务量公式如下：理论支撑任务量= 线程数配置/ 平均调度

15、频率（每秒）* 平均触发耗时（单位s）实际场景中， 由于调度中心与执行器ping 延迟不同、 DB 读写耗时不同、 任务调度密集程度不同，会导致任务量上限会上下波动。如若需要支撑更多的任务量，可以通过"调大调度线程数" 、 " 降低调度中心与执行器ping 延迟 " 和 "提升机器配置" 几种方式实现。日志回调任务调度模块的“调度中心”作为 Web 服务部署时，一方面承担调度中心功能，另一方面也-可编辑修改 -_为执行器提供API 服务调度日志调度中心每次进行任务调度，都会记录一条任务日志，任务日志主要包括以下三部分内容：任务信息：包

16、括 “执行器地址 ”、 “JobHandler ”和 “执行参数 ”等属性，点击任务ID 按钮可查看，根据这些参数，可以精确的定位任务执行的具体机器和任务代码。调度信息：包括 “调度时间 ”、“调度结果 ”和“调度日志 ”等，根据这些参数，可以了解“调度中心 ”发起调度请求时具体情况。执行信息：包括 “执行时间 ”、“执行结果 ”和“执行日志 ”等，根据这些参数，可以了解在“执行器 ”端任务执行的具体情况；调度日志，针对单次调度，属性说明如下：执行器地址：任务执行的机器地址；JobHandler ： Bean 模式表示任务执行的JobHandler名称；任务参数：任务执行的入参；调度时间：调度

17、中心，发起调度的时间；调度结果：调度中心，发起调度的结果，SUCCESS 或 FAIL ；调度备注：调度中心，发起调度的备注信息，如地址心跳检测日志等；执行时间：执行器，任务执行结束后回调的时间；执行结果：执行器，任务执行的结果，SUCCESS或 FAIL ；执行备注：执行器，任务执行的备注信息，如异常日志等；-可编辑修改 -_执行日志：任务执行过程中，业务代码中打印的完整执行日志。任务依赖任务调度中心每个任务都对应有一个任务ID ，同时，每个任务支持设置属性“子任务ID ”，因此，通过“任务 ID ”可以匹配任务依赖关系。当父任务执行结束并且执行成功时，将会根据“子任务 ID ”匹配子任务依

18、赖， 如果匹配到子任务，将会主动触发一次子任务的执行。在任务日志界面，点击任务的“执行备注”的“查看”按钮，可以看到匹配子任务以及触发子任务执行的日志信息，如无信息则表示未触发子任务执行。通讯数据加密调度中心向执行器发送的调度请求时使用RequestModel和 ResponseModel两个对象封装调度请求参数和响应数据, 在进行通讯之前底层会将上述两个对象对象序列化，并进行数据协议以及时间戳检验,从而达到数据加密的功能;分片广播、动态分片执行器集群部署时，任务路由策略选择"分片广播 "情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可

19、根据分片参数开发分片任务；-可编辑修改 -_"分片广播 " 以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。" 分片广播 " 和普通任务开发流程一致， 不同之处在于可以可以获取分片参数， 获取分片参数进行分片业务处理。访问令牌（ AccessToken ）为提升系统安全性，调度中心和执行器进行安全性校验，双方AccessToken匹配才允许通讯；调度中心和执行器，可通过配置项进行 AccessToken的设置。调度中心和执行器，如果需要正常通讯，只有两种设置；一：

20、调度中心和执行器，均不设置AccessToken；关闭安全性校验；二：调度中心和执行器，设置了相同的AccessToken；故障转移、失败重试一次完整任务流程包括"调度（调度中心）+ 执行（执行器）"两个阶段"故障转移 "发生在调度阶段，在执行器集群部署时，如果某一台执行器发生故障，该策略支持自动进行Failover 切换到一台正常的执行器机器并且完成调度请求流程。"失败重试 "发生在 "调度+ 执行 " 两个阶段，如下-可编辑修改 -_调度失败重试：调度中心调度失败且启用" 调度失败重试 "策

21、略时，将会自动重试一次；执行失败重试：执行器执行失败且启用" 执行失败重试 "策略，或回调失败重试状态（ IJobHandler.FAIL_RETRY ）时，也将会自动重试一次；任务超时控制支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；4.系统功能4.1 功能需求系统角色及登陆该系统共有三种角色：JobClient（作业客户机） , JobTracker （作业跟踪器） , TaskTracker（守护进程者） 。所有角色都具有登陆功能，根据角色不同登陆后进入各个角色所对应的页面。1.登录界面用户通过输入账号密码，点击登录，登录不同的账号自动判断角色，进入不

22、同的界面。2. JobClient: 主要负责提交任务和接收任务执行反馈结果。-可编辑修改 -_3. JobTracker : 负责接收并分配任务，任务调度。4.TaskTracker:负责执行任务，执行完反馈给JobTracker 。工作流程1.JobClient提交一个 任务 给 JobTracker, 这里我提供了两种客户端API,一种是如果 JobTracker不存在或者提交失败，直接返回提交失败。另一种客户端是重试客户端, 如果提交失败， 先存储到本地 leveldb( 可以使用 NFS 来达到同个节点组共享leveldb文件的目的, 多线程访问，做了文件锁处理)，返回给客户端提交成

23、功的信息，待JobTracker可用的时候，再将任务提交。2.JobTracker 收到 JobClient提交来的任务， 先生成一个唯一的JobID 。然后将任务储存在 Mongo 集群中。 JobTracker发现有（任务执行的）可用的TaskTracker节点(组) 之后，将优先级最大，最先提交的任务分发给TaskTracker 。这里 JobTracker会优先分配给比较空闲的 TaskTracker 节点，达到负载均衡。3.TaskTracker收到 JobTracker分发来的任务之后，执行。执行完毕之后，再反馈任务执行结果给JobTracker （成功 or 失败 失败有失败错误

24、信息 ），如果发现JobTacker不可用，那么存储本地leveldb ，等待 TaskTracker可用的时候再反馈。反馈结果的同时，询问 JobTacker有没有新的任务要执行。4.JobTacker收到 TaskTracker节点的任务结果信息，生成并插入(mongo) 任务执行日志。根据任务信息决定要不要反馈给客户端。不需要反馈的直接删除, 需要反馈的（同样-可编辑修改 -_JobClient不可用存储文件，等待可用重发）。5.JobClient收到任务执行结果，进行自己想要的逻辑处理。4.2 外部接口需求用户接口本系统采用B/S 架构，所有界面使用APP 风格，用户界面的具体细在功能

25、需求文档中描述。硬件接口无特殊需求。软件接口无特殊需求。通信接口无特殊需求。4.3 性能需求非功能性需求当前尚未形成完整文档。-可编辑修改 -_4.4 属性可用性（ 1 ）方便操作，操作流程合理。尽量从用户角度出发，以方便使用本产品。如：新增信息时，敲入回车键光标的自动跳转、 输入法的自动转换， 信息检索时输入汉语简拼快速检索到结果等。（ 2 ）控制必录入项。本系统能够对必须录入的项目进行控制，使用户能够确保信息录入的完整。同时对必录入项进行有效的统一的提示。（ 4 ）容错能力。系统具有一定的容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够保证正常运行，并有足够的提示信息帮助用户有效正确地完成任务。（ 5 ）操作完成时有统一规范的提示信息。 例如删除操作时，系统可提示警示框“您确认删除记录吗？操作不可恢复！”，用户点击确认后，系统才执行删除操作，删除后可直接返回相关页面。安全性（1 ）权限控制根据不同用户角色，设置相应权限， 用户的重要操作都做相应的日志记录以备查看，没有权限的用户禁止使用系统。（ 2 ）重要数据加密对一些重要的数据按一定的算法进行加密，如用户口令、重要参数等。（ 3 ）数据备份允许用户进行数据的备份和恢复，以弥补数据的破坏和丢失。-可编辑修改 -_（ 4 ）