软件需求规格说明书

＜任务调度中心后台管理系统＞需求规格说明书作者： 完成日期： 修订历史记录日期版本说明作者V1.0目录TOC\o"1-5"\h\z\o"CurrentDocument"引言 4\o"CurrentDocument"1.1目的 4\o"CurrentDocument"1.2背景 4\o"CurrentDocument"1.3概述 4\o"CurrentDocument"1.4参考文献 4\o"CurrentDocument"项目概述 5\o"CurrentDocument"2.1产品特性 5\o"CurrentDocument"2.2产品设计理念 6\o"CurrentDocument"2.3用户特点 6\o"CurrentDocument"2.4一般约束 6\o"CurrentDocument"2.5假设与依据 7\o"CurrentDocument"总体设计 7\o"CurrentDocument"3.1架构设计 7\o"CurrentDocument"3.1.1设计思想 7\o"CurrentDocument"3.1.2系统组成 7\o"CurrentDocument"3.1.3架构图 8\o"CurrentDocument"3.1.4调度中心HA（集群） 8\o"CurrentDocument"3.1.5调度线程池 8\o"CurrentDocument"3.1.6日志回调任务 8\o"CurrentDocument"3.1.7调度日志 9\o"CurrentDocument"3.1.8任务依赖 9\o"CurrentDocument"3.1.9通讯数据加密 10\o"CurrentDocument"3.2.0分片广播、动态分片 10\o"CurrentDocument"3.2.1访问令牌(AccessToken) 10\o"CurrentDocument"3.2.2故障转移、失败重试 10\o"CurrentDocument"3.2.3任务超时控制 11\o"CurrentDocument"系统功能 11\o"CurrentDocument"4.1功能需求 11\o"CurrentDocument"4.1.1系统角色及登陆 11\o"CurrentDocument"4.1.2工作流程 11\o"CurrentDocument"4.2外部接口需求 12\o"CurrentDocument"4.2.1用户接口 12\o"CurrentDocument"4.2.2硬件接口 12\o"CurrentDocument"4.2.3软件接口 12\o"CurrentDocument"4.2.4通信接口 12\o"CurrentDocument"4.3性能需求 12\o"CurrentDocument"4.4属性 13\o"CurrentDocument"4.4.1可用性 13\o"CurrentDocument"4.4.2安全性 13[1]GB-T8567-2006[1]GB-T8567-2006，《计算机软件文档编制规范》 [S]引言1.1目的该文档首先给出项目的整体结构和功能结构概貌， 试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。 便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及 确认测试和验收的依据。本文档面向多种读者对象：（1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。（2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。（3）程序员：了解系统功能，编写《用户手册》。（4） 测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。（5） 用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。在阅读本文档时，首先要了解产品的功能概貌， 然后可以根据自身的需要对每一功能进行适当的了解。1.2背景本次待开发的软件为任务调度中心后台管理系统。用户通过使用该系统在移动终端完成任务分配等操作。1.3概述该平台是一个轻量级分布式任务调度平台，其核心设计是统一管理任务调度平台上调度任务，负责出发调度执行，并且提供任务管理平台。1.4参考文献项目概述2.1产品特性1、 简单：支持通过Web页面对任务进行CRUD操作，操作简单，容易上手；2、动态：支持动态修改任务状态、暂停 /恢复任务，以及终止运行中任务，即时生效；3、调度中心HA（中心式）：调度采用中心式设计，“调度中心”基于集群 Quartz实现并支持集群部署，可保证调度中心 HA4、执行器HA（分布式）：任务分布式执行，任务 ”执行器”支持集群部署，可保证任务执行HA5、 注册中心：执行器会周期性自动注册任务，调度中心将会自动发现注册的任务并触发执行。同时，也支持手动录入执行器地址；6、弹性扩容缩容：一旦有新执行器机器上线或者下线， 下次调度时将会重新分配任务；7、 路由策略：执行器集群部署时提供丰富的路由策略，包括：第一个、最后一个、轮询、随机、一致性HASH最不经常使用、最近最久未使用、故障转移、忙碌转移等；8、故障转移：任务路由策略选择"故障转移”情况下，如果执行器集群中某一台机器故障，将会自动Failover切换到一台正常的执行器发送调度请求。9、 失败处理策略；调度失败时的处理策略，策略包括：失败告警、失败重试；10、失败重试：调度中心调度失败且启用 ”调度失败重试”策略时，将会自动重试一次；执行器执行失败且启用”执行失败重试”策略，或回调失败重试状态时， 也将会自动重试一次；11、 阻塞处理策略：调度过于密集执行器来不及处理时的处理策略，策略包括：单机串行（默认）、丢弃后续调度、覆盖之前调度；12、 任务超时控制：支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；13、分片广播任务：执行器集群部署时，任务路由策略选择 ”分片广播"情况下，一次任务调度将会广播触发集群中所有执行器执行一次任务，可根据分片参数开发分片任务；14、 动态分片：分片广播任务以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显着提升任务处理能力和速度。15、 事件触发：除了"Cron方式"和"任务依赖方式”触发任务执行之外，支持基于事件的触发任务方式。调度中心提供触发任务单次执行的 API服务，可根据业务事件灵活触发。16、 任务进度监控：支持实时监控任务进度；17、Rolling实时日志：支持在线查看调度结果，并且支持以 Rolling方式实时查看执行器输出的完整的执行日志；18、 GLUE提供WeblDE，支持在线开发任务逻辑代码，动态发布，实时编译生效，省略部署上线的过程。支持30个版本的历史版本回溯。19、脚本任务：支持以GLUE模式开发和运行脚本任务， 包括Shell、Python、NodeJS等类型脚本；20、 任务依赖：支持配置子任务依赖，当父任务执行结束且执行成功后将会主动触发一次子任务的执行，多个子任务用逗号分隔；21、一致性：“调度中心”通过DB锁保证集群分布式调度的一致性，一次任务调度只会触发一次执行；22、 自定义任务参数：支持在线配置调度任务入参，即时生效；23、 调度线程池：调度系统多线程触发调度运行，确保调度精确执行，不被堵塞；24、数据加密：调度中心和执行器之间的通讯进行数据加密， 提升调度信息安全性；25、 邮件报警：任务失败时支持邮件报警，支持配置多邮件地址群发报警邮件；26、推送maven中央仓库：将会把最新稳定版推送到 maven中央仓库，方便用户接入和使用；27、 运行报表：支持实时查看运行数据，如任务数量、调度次数、执行器数量等；以及调度报表，如调度日期分布图，调度成功分布图等；28、 全异步：系统底层实现全部异步化，针对密集调度进行流量削峰，理论上支持任意时长任务的运行；2.2产品设计理念当前各大行业人群密集， 因大量繁琐的任务分配不及时而困扰， 繁琐的根源便是邮件的收发、电话沟通，需要人工分配任务，最终人工汇总表格，工作量大且出错率高。任务调度中心系统致力于通过平台便捷地完成此项工作，且大大降低出错率。2.3用户特点本系统的最终用户群体普遍接受高等教育， 学习及适应能力强。能快速适应该软件，并充分感受到在任务调度中心的效能变化，提出合理改进意见。操作人员及维护人员为了解该工作的整体流程，深入用户交流，便于调整软件功能，实现客户需求。一般约束进行本系统开发工作的约束条件如下:开发周期短：两个月的开发时间需要开发者合理规划时间，做到多项任务并发。所采用的方法与技术有限：项目团队成员的技术水平不够成熟，需要在开发中并发学习多种技术和能力。2.5假设与依据本项目是否能够成功实施，主要取决于以下的条件：（1） 团队成员的积极合作配合，为了项目的开发和实施，对个人时间进行合理规划同时为团队做出合理牺牲，配合队友完成任务。（2） 完整详细的功能和性能需求资料，以便于团队对其进行分析，从而形成完善的软件需求。（3） 团队掌握先进的能够适用于该项目的技术，这是系统的性能是否优化和项目能否成功的保证。总体设计3.1架构设计3.1.1设计思想将调度行为抽象形成“调度中心”公共平台，而平台自身并不承担业务逻辑，“调度中心”负责发起调度请求。将任务抽象成分散的JobHandler，交由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业务逻辑。因此，“调度”和“任务”两部分可以相互解耦，提高系统整体稳定性和扩展性；3.1.2系统组成调度模块（调度中心）：负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。调度系统与任务解耦，提高了系统可用性和稳定性， 同时调度系统性能不再受限于任务模块； 支持可视化、简单且动态的管理调度信息，包括任务新建，更新，删除，GLUE开发和任务报警等，所有上述操作都会实时生效，同时支持监控调度结果以及执行日志，支持执行器Failover。执行模块（执行器）：负责接收调度请求并执行任务逻辑。任务模块专注于任务的执行等操作，开发和维护更加简单和高效； 接收“调度中心”的执行请求、终止请求和日志请求等。3.1.3架构图3.1.4调度中心HA（集群）基于Quartz的集群方案，数据库选用Mysql;集群分布式并发环境中使用 QUART定时任务调度，会在各个节点会上报任务， 存到数据库中，执行时会从数据库中取出触发器来执行，如果触发器的名称和执行时间相同，则只有一个节点去执行此任务。3.1.5调度线程池调度采用线程池方式实现，避免单线程因阻塞而引起任务调度延迟。任务调度中心系统中业务逻辑在远程执行器执行， 全异步化设计，调度中心每次触发调度时仅发送一次调度请求，执行器会将请求存入执行队列并且立即响应调度中心， 异步运行；相比直接在quartz的QuartzJobBean中执行业务逻辑，极大的降低了调度线程占用时间；任务调度中心系统中每个逻辑非常 “轻”，单个一次运行平均耗时基本在 "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分片广播、动态分片执行器集群部署时，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时传递分片参数；可根据分片参数开发分片任务；"分片广播”以执行器为维度进行分片，支持动态扩容执行器集群从而动态增加分片数量，协同进行业务处理；在进行大数据量业务操作时可显着提升任务处理能力和速度。" 分片广播”和普通任务开发流程一致，不同之处在于可以可以获取分片参数， 获取分片参数进行分片业务处理。访问令牌（AccessToken）为提升系统安全性，调度中心和执行器进行安全性校验， 双方AccessToken匹配才允许通讯；调度中心和执行器，如果需要正常通讯，只有两种设置；一：调度中心和执行器，均不设置 AccessToken;关闭安全性校验；二：调度中心和执行器，设置了相同的AccessToken；3.2.2故障转移、失败重试一次完整任务流程包括”调度（调度中心）+执行（执行器）"两个阶段"故障转移”发生在调度阶段，在执行器集群部署时， 如果某一台执行器发生故障， 该策略支持自动进行Failover切换到一台正常的执行器机器并且完成调度请求流程。"失败重试”发生在”调度+执行"两个阶段，如下调度失败重试：调度中心调度失败且启用”调度失败重试”策略时，将会自动重试一次;执行失败重试：执行器执行失败且启用”执行失败重试”策略，或回调失败重试状态（IJobHandler.FAIL_RETRY）时，也将会自动重试一次；3.2.3任务超时控制支持设置任务超时时间，任务运行超时的情况下，将会主动中断任务；系统功能4.1功能需求4.1.1系统角色及登陆该系统共有三种角色： JobClient （作业客户机） ，JobTracker （作业跟踪器）TaskTracker（守护进程者）。所有角色都具有登陆功能，根据角色不同登陆后进入各个角色所对应的页面。登录界面用户通过输入账号密码，点击登录，登录不同的账号自动判断角色，进入不同的界面。JobClient: 主要负责提交任务和接收任务执行反馈结果。JobTracker: 负责接收并分配任务，任务调度。TaskTracker: 负责执行任务，执行完反馈给 JobTracker。4.1.2工作流程JobClient 提交一个任务给JobTracker, 这里我提供了两种客户端 API,一种是如果JobTracker不存在或者提交失败，直接返回提交失败。另一种客户端是重试客户端 ，如果提交失败，先存储到本地leveldb（可以使用NFS来达到同个节点组共享leveldb文件的目的，多线程访问，做了文件锁处理），返回给客户端提交成功的信息，待 JobTracker可用的时候，再将任务提交。JobTracker收到JobClient提交来的任务，先生成一个唯一的 JoblD。然后将任务储存在Mongo集群中。JobTracker发现有（任务执行的）可用的TaskTracker节点（组）之后，将优先级最大，最先提交的任务分发给TaskTracker这里JobTracker会优先分配给比较空闲的TaskTracker节点，达到负载均衡。TaskTracker收到JobTracker分发来的任务之后，执行。执行完毕之后，再反馈任务执行结果给JobTracker（成功or失败［失败有失败错误信息］）,如果发现JobTacker不可用，那么存储本地leveldb，等待TaskTracke河用的时候再反馈。反馈结果的同时，询问JobTacker有没有新的任务要执行。JobTacker收到TaskTracker节点的任务结果信息，生成并插入（mongo）任务执行日志。根据任务信息决定要不要反馈给客户端。不需要反馈的直接删除 ,需要反馈的（同样JobClient不可用存储文件，等待可用重发）。JobClient收到任务执行结果，进行自己想要的逻辑处理。外部接口需求用户接口本系统采用B/S架构，所有界面使用APP风格，用户界面的具体细在功能需求文档中描述。硬件接口无特殊需求。软件接口无特殊需求。通信接口无特殊需求。性能需求非功能性需求当前尚未形成完整文档。属性可用性（1）方便操作，操作流程合理。尽量从用户角度出发，以方便使用本产品。如：新增信息时，敲入回车键光标的自动跳转、输入法的自动转换，信息检索时输入汉语简拼快速检索到（2）控制必录入项。本系统能够对必须录入的项目进行控制，使用户能够确保信息录入的完整。同时对必录入项进行有效的统一的提示。（4）容错能力。系统具有一定的容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够保证正常运行，并有足够的提示信息帮助用户有效正确地完成任务。（5）操作完成时有统一规范的提示信息。例如删除操作时，系统可提示警示框“您确认删除记录吗操作不可恢复！”，用户点击确认后，系统才执行删除操作，删除后可直接返回相关页面。安全性（1）权限控制根据不同用户角色，设置相应权限，用户的重要操作都做相应的日志记录以备查看，有权限的用户禁止使用系统。（2）重要数据加密对一些重要的数据按一定的算法进行加密，如用户口令、重要参数等。（3）数据备份允许用户进行数据的备份和恢复，以弥补数据的破坏和丢失。（4）记录日志本系统应该能够记录系统运行时所发生的所有错误，包括本机错误和网络错误。这些错误记录便于查找错误的原因。日志同时记录用户的关键性操作信息。4.4.3可维护性当前尚未形成完整文档。系统开发计划和时间规划该系统分为5个阶段执行，系统为期六个月，项目参与总人数为20人。系统启动阶段此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成（大体为以上四个阶段）。成立项目组一般项目合同签署完成后，公司会通过《项目实施流程表》先通过“市场管理中心”审核检阅，主要包括合同相关款项及系统签署的相应功能模块是否符合要求；审核结束后到项目部部门经理接到实施申请后，任命该项目的项目经理，指定项目目标，由项目经理指定项目组成员及成员任务，并报相关分管副总或者总经理。前期需求调研项目经理及项目组成员，在商务人员或者销售人员配合下，建立与用户的联系，对合同中签订的系统主要功能模块进行调研。确定客户他们的需求和期望，如何修改完善满足和影响这些需求、期望以确保项目能够成功。若涉及到相关的硬件设备，在做需求调研的同时，需协调系统集成部门完成硬件服务器及网络环境的搭建。《项目总体计划》文档主要介绍项目建设目标、主要项目实施阶段、里程碑、可交付成果。通常包括以下几方面内容：项目建设背景描述，项目建设目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配参与配合的相应客户人员；沟通管理计划，确定客户人员沟通的需要。启动会项目组成员与用户共同召开的宣布该项目正式开始的会议需求调研确定阶段此阶段的主要工作是项目实施人员向用户调研后用户对系统的需求，包括系统流程调研、功能需求调研、数据查询需求调研等，实施人员调研完成后，会编写相关文档，并交付用户进行确认并且签字确认，待用户对文档上所提到的需求确认签字完毕后，项目实施人员将提交该需求调研分析书给相关副总或总经理签字，签字完成后以此为依据提交开发进行软件功能的修改完善。进行需求调研前期准备制定《需求文档》内部