软件需求规格说明指导书.docx

<任务调度中心后台管理系统>

需求规格说明书

作 者：

完成日期：

修订历史统计
日期
版本
说明
作者

V1.0

目录
1. 引言 4
1.1 目的 4
1.2 背景 4
1.3 概述 4
1.4参考文献 4
2. 项目概述 5
2.1 产品特性 5
2.2 产品设计理念 6
2.3 用户特点 6
2.4 一般约束 6
2.5 假设与依据 6
3.总体设计 7
3.1架构设计 7
3.1.1 设计思想 7
3.1.2 系统组成 7
3.1.3 架构图 8
3.1.4 调度中心HA(集群) 8
3.1.5 调度线程池 8
3.1.6 日志回调任务 9
3.1.7 调度日志 9
3.1.8 任务依赖 9
3.1.9 通讯数据加密 10
3.2.0 分片广播、动态分片 10
3.2.1 访问令牌（AccessToken） 10
3.2.2 故障转移、失败重试 10
3.2.3 任务超时控制 11
4.系统功能 11
4.1 功能需求 11
4.1.1系统角色及登陆 11
4.1.2 工作流程 11
4.2 外部接口需求 12
4.2.1 用户接口 12
4.2.2 硬件接口 12
4.2.3 软件接口 12
4.2.4 通信接口 12
4.3 性能需求 12
4.4 属性 13
4.4.1 可用性 13
4.4.2 安全性 13

1. 引言
1.1 目标
该文档首先给出项目标整体结构和功效结构概貌，试图从总体架构上给出整个系统轮廓。同时对功效需求、性能需求进行了具体描述。便于用户、开发人员进行了解和交流，反应出用户问题结构，能够作为软件开发工作基础和依据和确定测试和验收依据。
本文档面向多个读者对象：
（1）项目经理：项目经理能够依据该文档了解预期产品功效，并据此进行系统设计、项目管理。
（2）设计员：对需求进行分析，并设计出系统，包含数据库设计。
（3）程序员：了解系统功效，编写《用户手册》。
（4）测试员：依据本文档编写测试用例，并对软件产品进行功效性测试和非功效性测试。
（5）用户：了解预期产品功效和性能，并和分析人员一起对整个需求进行讨论和协商。
在阅读本文档时，首先要了解产品功效概貌，然后能够依据本身需要对每一功效进行合适了解。
1.2 背景
此次待开发软件为任务调度中心后台管理系统。
用户经过使用该系统在移动终端完成任务分配等操作。
1.3 概述
该平台是一个轻量级分布式任务调度平台，其关键设计是统一管理任务调度平台上调度任务，负责出发调度实施，而且提供任务管理平台。
1.4参考文件
[1] GB-T8567-，《计算机软件文档编制规范》[S]

2. 项目概述
2.1 产品特征
1、简单：支持经过Web页面对任务进行CRUD操作，操作简单，轻易上手；
· 2、动态：支持动态修改任务状态、暂停/恢复任务，和终止运行中任务，即时生效；
· 3、调度中心HA（中心式）：调度采取中心式设计，“调度中心”基于集群Quartz实现并支持集群布署，可确保调度中心HA；
· 4、实施器HA（分布式）：任务分布式实施，任务"实施器"支持集群布署，可确保任务实施HA；
· 5、注册中心: 实施器会周期性自动注册任务, 调度中心将会自动发觉注册任务并触发实施。同时，也支持手动录入实施器地址；
· 6、弹性扩容缩容：一旦有新实施器机器上线或下线，下次调度时将会重新分配任务；
· 7、路由策略：实施器集群布署时提供丰富路由策略，包含：第一个、最终一个、轮询、随机、一致性HASH、最不常常使用、最近最久未使用、故障转移、忙碌转移等；
· 8、故障转移：任务路由策略选择"故障转移"情况下，假如实施器集群中某一台机器故障，将会自动Failover切换到一台正常实施器发送调度请求。
· 9、失败处理策略；调度失败时处理策略，策略包含：失败告警、失败重试；
· 10、失败重试：调度中心调度失败且启用"调度失败重试"策略时，将会自动重试一次；实施器实施失败且启用"实施失败重试"策略，或回调失败重试状态时，也将会自动重试一次；
· 11、阻塞处理策略：调度过于密集实施器来不及处理时处理策略，策略包含：单机串行（默认）、丢弃后续调度、覆盖之前调度；
· 12、任务超时控制：支持设置任务超时时间，任务运行超时情况下，将会主动中止任务；
· 13、分片广播任务：实施器集群布署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发集群中全部实施器实施一次任务，可依据分片参数开发分片任务；
· 14、动态分片：分片广播任务以实施器为维度进行分片，支持动态扩容实施器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
· 15、事件触发：除了"Cron方法"和"任务依靠方法"触发任务实施之外，支持基于事件触发任务方法。调度中心提供触发任务单次实施API服务，可依据业务事件灵活触发。
· 16、任务进度监控：支持实时监控任务进度；
· 17、Rolling实时日志：支持在线查看调度结果，而且支持以Rolling方法实时查看实施器输出完整实施日志；
· 18、GLUE：提供Web IDE，支持在线开发任务逻辑代码，动态公布，实时编译生效，省略布署上线过程。支持30个版本历史版本回溯。
· 19、脚本任务：支持以GLUE模式开发和运行脚本任务，包含Shell、Python、NodeJS等类型脚本;
· 20、任务依靠：支持配置子任务依靠，当父任务实施结束且实施成功后将会主动触发一次子任务实施, 多个子任务用逗号分隔；
· 21、一致性：“调度中心”经过DB锁确保集群分布式调度一致性, 一次任务调度只会触发一次实施；
· 22、自定义任务参数：支持在线配置调度任务入参，即时生效；
· 23、调度线程池：调度系统多线程触发调度运行，确保调度正确实施，不被堵塞；
· 24、数据加密：调度中心和实施器之间通讯进行数据加密，提升调度信息安全性；
· 25、邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；
· 26、推送maven中央仓库: 将会把最新稳定版推送到maven中央仓库, 方便用户接入和使用;
· 27、运行报表：支持实时查看运行数据，如任务数量、调度次数、实施器数量等；和调度报表，如调度日期分布图，调度成功分布图等；
· 28、全异步：系统底层实现全部异步化，针对密集调度进行流量削峰，理论上支持任意时长任务运行；

2.2 产品设计理念
目前各大行业人群密集，因大量繁琐任务分配不立即而困扰，繁琐根源便是邮件收发、电话沟通，需要人工分配任务，最终人工汇总表格，工作量大且犯错率高。
任务调度中心系统致力于经过平台便捷地完成此项工作，且大大降低犯错率。
2.3 用户特点
本系统最终用户群体普遍接收高等教育，学习及适应能力强。能快速适应该软件，并充足感受到在任务调度中心效能改变，提出合理改善意见。
操作人员及维护人员为了解该工作整体步骤，深入用户交流，便于调整软件功效，实现用户需求。
2.4 通常约束
进行本系统开发工作约束条件以下：
1.开发周期短：两个月开发时间需要开发者合理计划时间，做到多项任务并发。
2.所采取方法和技术有限：项目团体组员技术水平不够成熟，需要在开发中并发学习多个技术和能力。
2.5 假设和依据
本项目是否能够成功实施，关键取决于以下条件：
（1）团体组员主动合作配合，为了项目标开发和实施，对个人时间进行合理计划同时为团体做出合理牺牲，配合队友完成任务。
（2）完整具体功效和性能需求资料，方便于团体对其进行分析，从而形成完善软件需求。
（3）团体掌握优异能够适适用于该项目标技术，这是系统性能是否优化和项目能否成功确保。
3.总体设计
3.1架构设计
3.1.1 设计思想
将调度行为抽象形成“调度中心”公共平台，而平台本身并不负担业务逻辑，“调度中心”负责提议调度请求。
将任务抽象成份散JobHandler，交由“实施器”统一管理，“实施器”负责接收调度请求并实施对应JobHandler中业务逻辑。
所以，“调度”和“任务”两部分能够相互解耦，提升系统整体稳定性和扩展性；
3.1.2 系统组成
调度模块（调度中心）： 负责管理调度信息，根据调度配置发出调度请求，本身不负担业务代码。调度系统和任务解耦，提升了系统可用性和稳定性，同时调度系统性能不再受限于任务模块； 支持可视化、简单且动态管理调度信息，包含任务新建，更新，删除，GLUE开发和任务报警等，全部上述操作全部会实时生效，同时支持监控调度结果和实施日志，支持实施器Failover。
实施模块（实施器）： 负责接收调度请求并实施任务逻辑。任务模块专注于任务实施等操作，开发和维护愈加简单和高效； 接收“调度中心”实施请求、终止请求和日志请求等。

3.1.3 架构图

3.1.4 调度中心HA(集群)
基于Quartz集群方案，数据库选择Mysql；集群分布式并发环境中使用QUARTZ定时任务调度，会在各个节点会上报任务，存到数据库中，实施时会从数据库中取出触发器来实施，假如触发器名称和实施时间相同，则只有一个节点去实施此任务。

3.1.5 调度线程池
调度采取线程池方法实现，避免单线程因阻塞而引发任务调度延迟。
任务调度中心系统中业务逻辑在远程实施器实施，全异步化设计，调度中心每次触发调度时仅发送一次调度请求，实施器会将请求存入实施队列而且立即响应调度中心，异步运行；相比直接在quartzQuartzJobBean中实施业务逻辑，极大降低了调度线程占用时间；
任务调度中心系统中每个逻辑很 “轻”，单个一次运行平均耗时基础在 "10ms" 之内（基础为一次请求网络开销）；所以，能够确保使用有限线程支撑大量并发运行；
理论支撑任务量公式以下：
理论支撑任务量 = 线程数配置 / 平均调度频率（每秒） * 平均触发耗时（单位s）
实际场景中，因为调度中心和实施器ping延迟不一样、DB读写耗时不一样、任务调度密集程度不一样，会造成任务量上限会上下波动。
如若需要支撑更多任务量，能够经过 "调大调度线程数" 、"降低调度中心和实施器ping延迟" 和 "提升机器配置" 多个方法实现。
3.1.6 日志回调任务
调度模块“调度中心”作为Web服务布署时，首先负担调度中心功效，其次也为实施器提供API服务

3.1.7 调度日志
调度中心每次进行任务调度，全部会统计一条任务日志，任务日志关键包含以下三部分内容：
任务信息：包含“实施器地址”、“JobHandler”和“实施参数”等属性，点击任务ID按钮可查看，依据这些参数，能够正确定位任务实施具体机器和任务代码。
调度信息：包含“调度时间”、“调度结果”和“调度日志”等，依据这些参数，能够了解“调度中心”提议调度请求时具体情况。
实施信息：包含“实施时间”、“实施结果”和“实施日志”等，依据这些参数，能够了解在“实施器”端任务实施具体情况；
调度日志，针对单次调度，属性说明以下：
实施器地址：任务实施机器地址；
JobHandler：Bean模式表示任务实施JobHandler名称；
任务参数：任务实施入参；
调度时间：调度中心，提议调度时间；
调度结果：调度中心，提议调度结果，SUCCESS或FAIL；
调度备注：调度中心，提议调度备注信息，如地址心跳检测日志等；
实施时间：实施器，任务实施结束后回调时间；
实施结果：实施器，任务实施结果，SUCCESS或FAIL；
实施备注：实施器，任务实施备注信息，如异常日志等；
实施日志：任务实施过程中，业务代码中打印完整实施日志。

3.1.8 任务依靠
任务调度中心每个任务全部对应有一个任务ID，同时，每个任务支持设置属性“子任务ID”，所以，经过“任务ID”能够匹配任务依靠关系。
当父任务实施结束而且实施成功时，将会依据“子任务ID”匹配子任务依靠，假如匹配到子任务，将会主动触发一次子任务实施。
在任务日志界面，点击任务“实施备注”“查看”按钮，能够看到匹配子任务和触发子任务实施日志信息，如无信息则表示未触发子任务实施。

3.1.9 通讯数据加密
调度中心向实施器发送调度请求时使用RequestModel和ResponseModel两个对象封装调度请求参数和响应数据, 在进行通讯之前底层会将上述两个对象对象序列化，并进行数据协议以立即间戳检验,从而达成数据加密功效;

3.2.0 分片广播、动态分片
实施器集群布署时，任务路由策略选择"分片广播"情况下，一次任务调度将会广播触发对应集群中全部实施器实施一次任务，同时传输分片参数；可依据分片参数开发分片任务；
"分片广播" 以实施器为维度进行分片，支持动态扩容实施器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显著提升任务处理能力和速度。
" 分片广播" 和一般任务开发步骤一致，不一样之处于于能够能够获取分片参数，获取分片参数进行分片业务处理。

3.2.1 访问令牌（AccessToken）
为提升系统安全性，调度中心和实施器进行安全性校验，双方AccessToken匹配才许可通讯；
调度中心和实施器，可经过配置项 "xxl.job.accessToken" 进行AccessToken设置。
调度中心和实施器，假如需要正常通讯，只有两种设置；
一：调度中心和实施器，均不设置AccessToken；关闭安全性校验；
二：调度中心和实施器，设置了相同AccessToken；

3.2.2 故障转移、失败重试
一次完整任务步骤包含"调度（调度中心） + 实施（实施器）"两个阶段
"故障转移"发生在调度阶段，在实施器集群布署时，假如某一台实施器发生故障，该策略支持自动进行Failover切换到一台正常实施器机器而且完成调度请求步骤。
"失败重试"发生在"调度 + 实施"两个阶段，以下
调度失败重试：调度中心调度失败且启用"调度失败重试"策略时，将会自动重试一次；
实施失败重试：实施器实施失败且启用"实施失败重试"策略，或回调失败重试状态（IJobHandler.FAIL_RETRY）时，也将会自动重试一次；

3.2.3 任务超时控制
支持设置任务超时时间，任务运行超时情况下，将会主动中止任务；

4.系统功效
4.1 功效需求
4.1.1系统角色及登陆
该系统共有三种角色：JobClient（作业用户机）, JobTracker（作业跟踪器）, TaskTracker（守护进程者）。全部角色全部含有登陆功效，依据角色不一样登陆后进入各个角色所对应页面。
1.登录界面
用户经过输入账号密码，点击登录，登录不一样账号自动判定角色，进入不一样界面。

2. JobClient: 关键负责提交任务和接收任务实施反馈结果。
3. JobTracker : 负责接收并分配任务，任务调度。
4. TaskTracker: 负责实施任务，实施完反馈给JobTracker。

4.1.2 工作步骤
1.JobClient 提交一个 任务 给 JobTracker, 这里我提供了两种用户端API, 一个是假如JobTracker 不存在或提交失败，直接返回提交失败。另一个用户端是重试用户端, 假如提交失败，先存放到当地leveldb(能够使用NFS来达成同个节点组共享leveldb文件目标,多线程访问，做了文件锁处理)，返回给用户端提交成功信息，待JobTracker可用时候，再将任务提交。
2.JobTracker 收到JobClient提交来任务，先生成一个唯一JobID。然后将任务储存在Mongo集群中。JobTracker 发觉有（任务实施）可用TaskTracker节点(组) 以后，将优先级最大，最先提交任务分发给TaskTracker。这里JobTracker会优先分配给比较空闲TaskTracker节点，达成负载均衡。
3.TaskTracker 收到JobTracker分发来任务以后，实施。实施完成以后，再反馈任务实施结果给JobTracker（成功or 失败[失败有失败错误信息]），假如发觉JobTacker不可用，那么存放当地leveldb，等候TaskTracker可用时候再反馈。反馈结果同时，问询JobTacker有没有新任务要实施。
4.JobTacker收到TaskTracker节点任务结果信息，生成并插入(mongo)任务实施日志。依据任务信息决定要不要反馈给用户端。不需要反馈直接删除, 需要反馈（一样JobClient不可用存放文件，等候可用重发）。
5.JobClient 收到任务实施结果，进行自己想要逻辑处理。

4.2 外部接口需求
4.2.1 用户接口
本系统采取B/S架构，全部界面使用APP风格，用户界面具体细在功效需求文档中描述。
4.2.2 硬件接口
无特殊需求。
4.2.3 软件接口
无特殊需求。
4.2.4 通信接口
无特殊需求。
4.3 性能需求
非功效性需求目前还未形成完整文档。
4.4 属性
4.4.1 可用性
（1）方便操作，操作步骤合理。尽可能从用户角度出发，以方便使用本产品。如：新增信息时，敲入回车键光标自动跳转、输入法自动转换，信息检索时输入汉语简拼快速检索到结果等。
（2）控制必录入项。本系统能够对必需录入项目进行控制，使用户能够确保信息录入完整。同时对必录入项进行有效统一提醒。
（4）容错能力。系统含有一定容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够确保正常运行，并有足够提醒信息帮助用户有效正确地完成任务。
（5）操作完成时有统一规范提醒信息。比如删除操作时，系统可提醒警示框“您确定删除统计吗？操作不可恢复！”，用户点击确定后，系统才实施删除操作，删除后可直接返回相关页面。
4.4.2 安全性
（1）权限控制
依据不一样用户角色，设置对应权限，用户关键操作全部做对应日志统计以备查看，没有权限用户严禁使用系统。
（2）关键数据加密
对部分关键数据按一定算法进行加密，如用户口令、关键参数等。
（3）数据备份
许可用户进行数据备份和恢复，以填补数据破坏和丢失。
（4）统计日志
本系统应该能够统计系统运行时所发生全部错误，包含本机错误和网络错误。这些错误统计便于查找错误原因。日志同时统计用户关键性操作信息。
4.4.3 可维护性
目前还未形成完整文档。

5. 系统开发计划和时间计划
该系统分为5个阶段实施，系统为期六个月，项目参与总人数为20人。

5.1 系统开启阶段
此阶段处于整个项目实施工作最前期，由成立项目组、前期调研、编制总体项目计划、开启会四个阶段组成（大致为以上四个阶段） 。
5.1.1 成立项目组
通常项目协议签署完成后，企业会经过《项目实施步骤表》先经过“市场管理中心”审核检阅，关键包含协议相关款项及系统签署对应功效模块是否符合要求；审核结束后到项目部部门经理接到实施申请后，任命该项目标项目经理，指定项目目标，由项目经理指定项目组组员及组员任务，并报相关分管副总或总经理。
5.1.2 前期需求调研
项目经理及项目组组员，在商务人员或销售人员配合下，建立和用户联络，对协议中签署系统关键功效模块进行调研。确定用户她们需求和期望，怎样修改完善满足和影响这些需求、期望以确保项目能够成功。若包含到相关硬件设备，在做需求调研同时，需协调系统集成部门完成硬件服务器及网络环境搭建。
5.1.3制订《项目总体计划》
《项目总体计划》文档关键介绍项目建设目标、关键项目实施阶段、里程碑、可交付结果。通常包含以下几方面内容：项目建设背景描述，项目建设目标、关键项目阶段、里程碑、可交付结果。所计划职责分配参与配合对应用户人员；沟通管理计划，确定用户人员沟通需要。
5.1.3 开启会
项目组组员和用户共同召开宣告该项目正式开始会议
5.2 需求调研确定阶段
此阶段关键工作是项目实施人员向用户调研后用户对系统需求，包含系统步骤调研、功效需求调研、数据查询需求调研等，实施人员调研完成后，会编写相关文档，并交付用户进行确定而且签字确定，待用户对文档上所提到需求确定签字完成后，项目实施人员将提交该需求调研分析书给相关副总或总经理签字，签字完成后以此为依据提交开发进行软件功效修改完善。
5.2.1进行需求调研前期准备
5.2.2 制订《需求文档》
5.2.3 内部评审是否经过《需求文档》
项目组、项目经理、销售等人员依据协议要求和项目实际情况对《需求文档》初稿进行评审，如评审经过，领导签字确定，如评审不经过则重新修改和用户再次确定相关细节。
5.2.4签署《需求文档》
签署《需求调研计划》，则作为以后需求调研工作证实手段
5.2.5 《需求文档》是否有变更
假如计划存在变更，则再次确定变更相关需求，不然按计划进行后续工作。

5.2.6 需求开发实现阶段
此阶段关键是用户需求得到企业领导及经过企业内部评审经过后转交开发部门修改阶段，开发部门依据需求调研分析计划书具体要求去修改软件系统对应功效模块。
5.2.7 软件测试阶段
此阶段关键是在开发完成后进行系统功效测试阶段，以确保开发修改后模块实现用户相关要求及修改后是否存在对应程序bug及功效性错误。
5.3 系统布署安装阶段
此阶段关键是实施人员及测试部门人员共同完成，实施人员提供系统布署硬件环境及网络环境。测试人员依据其环境要求先对系统进行性能型测试，满足要求后进行远程布署安装或现场安装。
5.4 系统培训阶段
系统培训阶段工作是整个项目实施工作中比较关键工作，用户对软件操作功效是否熟练将直接影响到后面软件应用效果，所以企业和用户双方要对此阶段工作给足够重视。要充足认识培训关键性和艰巨性。在项目实施之前对用户相关人员进行系统和规范产品培训是很必需，达成让用户了解软件产品具体操作，最终自己能够处理使用中具体问题。
5.4.1培训前准备
在培训开始前3天和用户沟通协调参与培训相关人员及部门。
5.4.2签署培训计划
署《培训计划》，深入确定培训安排工作
5.4.3培训通知
将培训内容、时间，场地，人员等信息通知给她们，由她们经过具体参与人员。
5.4.4搭建培训环境
企业项目组在培训开始前，将培训环境搭建及检验妥当（投影仪、电脑），将培训提要及培训手册准备好。
5.4.5培训考评
企业项目组培训工程师和用户（操作者）沟通，经过现场提问方法考评参训人员。
5.5系统安装测试及试运行阶段
5.5.1签署计划
用户签署《测试及试运行计划》，深入确定测试及试运行安排。
5.5.2测试及试运行通知
当系统培训完成后，测试部门会进行二轮回归测试，关键确定系统布署完成后是否存在问题，同时用户已经完成培训，进行试运行阶段。
5.5.3组织测试及试运行
用户相关各级领导给全方面配合，组织相关人员进行测试及试运行。企业项目组负责担当指挥，检验用户人员组织情况并给指导，跟踪检验以下情况： 功效模块操作步骤情况。