ScheduleMaster提供分布式任务调度功能，可以帮助用户在软件上配置工作方案，让复杂、多线程的任务运行更加流畅，对于需要建立任务调度系统的朋友很有帮助，您可以在软件上管理设备，可以建立设备任务执行流程，可以设置任务依赖以及触发条件，可以实时监控项目运行过程，可以在软件查看运行状态，可以实时监控报警项目，让用户可以更好远程，更好配置调度方案；ScheduleMaster可以快速创建新的工作任务，您可以控制任务启动和停止，可以设置异常报警提醒方案，可以对调度任务统计，提供的功能非常多！

ScheduleMaster软件功能

基于.NET Core 3.1平台构建，支持跨平台多节点部署运行。

简易的Web UI作；

任务动态管理:创建、启动、停止、暂停、恢复、删除等；

高可用支持，跨平台多节点部署。

数据安全，不会出现多实例并发调度。

支持自定义参数设置；

支持.NET Core和.net framework（4.6.1+）；

支持自定义配置文件和热更新；

支持设置监护人，运行异常时邮件告警；

支持设置任务依赖，自动触发，共享任务结果；

插件式开发，任务运行环境隔离；

全链路志系统，运行轨迹轻松掌控；

用户访问控制；

提供开放REST API，业务系统可以无缝集成；

调度报表统计；

任务分组管理；

计划表拆分实现复用；

指定节点运行；

支持http任务配置；

支持延时任务；

任务监控；

资源监控；

支持异常策略配置（失败重试、超时控制等）；

接入redis缓存；

多数据库类型支持；

用户权限更加精细化；

报表统计完善；

ScheduleMaster软件特色

1、ScheduleMaster可以帮助用户配置任务调度方案

2、可以设置工作方案，可以对复杂的数据访问流程调度

3、支持系统配置功能，可以在软件对节点设置，可以对响应方式设置

4、支持邮件功能，您可以在软件配置邮件提醒方案

5、支持HTTP设置功能，可以设置HTTP任务执行时的超时时间。

6、可以在软件配置任务，可以添加任务节点

7、支持参数配置，在软件设置任务配置方案，设置参数

8、支持动态参数启动，支持配置文件启动，支持志跟踪

ScheduleMaster教程

一、部署方式介绍

由于.NET Core天生就对云原生的友好支持，本项目针对各种部署场景提供了多种简单有效的方式。

从不同角度来看，它又支持不同的形式。

– 按应用配置角度：支持**静态配置文件**和**运行时动态参数**。

– 按应用启动角度：支持**自动注册模式**和**手动连接模式**。

以上几种方式都是互相结合使用，相辅相成的。

再稍微解释下本项目涉及的几个核心概念：

– **Master**：系统主控制台，表现上是一个ASP.NET Core MVC的web应用，它是所有任务和节点的控制中心，是用户和调度系统的交互窗口。

– **Worker**：任务执行器，也就是实际执行任务的载体，由Master通过HTTP的方式进行管理。

– **Node(节点)**：运行了Master或Worker的一个web进程，系统要运行必须要至少启动2个节点，也就是1个Master和至少1个Worker。

> 要注意的是，Master和Worker必须使用同一个数据库。

### 静态配置文件启动

这是项目早期唯一支持的启动方式，在节点启动前通过修改配置文件`appsettings.json`中指定配置项`NodeSetting`的参数实现节点配置。

在自动注册模式下，这些配置将被注册到数据库中，成为节点间互相访问的依据。

在手动连接模式下，配置将会失效，这时候节点间访问完全依赖于在控制台中手动配置的。

> 要注意的是，Master只提供了自动注册模式，也就是必须要在启动前配置好参数，而Worker可以支持上面提到的2种模式，下同。

这种启动方式适合节点数不是很多，并且使用传统部署方式的场景。

### 动态参数启动

在很多场景下，使用配置文件并不是一种好的方案，特别是参数中的IP和端口并不好提前预定，很典型的是在使用Docker部署的情况下需要根据不同的配置文件生成不同的镜像，又或者是使用Kubernetes进行节点弹伸缩时非常不便，这是不能忍受的。

为了充分适应容器部署，我设计了动态参数启动模式，支持使用运行时参数改变节点配置。

在自动注册模式下，可以使用命令行参数覆盖对应的配置文件参数，对应的参数名分别是：`–identity`、`–ptocol`、`–ip`、`–port`、`–poty`、`–maxc`，这种模式下还是要依赖于配置文件，只是动态参数有更高的优先级。

在手动连接模式下，节点依赖于控制台中的配置，**但是必须要使用动态参数告诉应用禁用自动注册**，有如下2种方式：

– 使用环境变量，设置 **`CORE_AUTOR=false`** 和 **`CORE_WORKEROF=你的master节点名称`**。

– 使用命令行参数，设置 **`–tor=false`** 和 **`–workef=你的master节点名称`**。

有了动态参数，我们可以使用一个Docker镜像，通过不同启动参数就能部署多个节点。而有了手动连接方式，可以非常方便的使用Kubernetes对节点做弹伸缩。

**系统默认情况下是以配置文件和自动注册模式启动。

二、动态参数启动

参考《配置文件启动》的步骤先获得项目的发布文件。

动态参数对自动注册模式和手动连接模式都有效，下面分别介绍这两种模式下的使用。

### 自动注册节点

这是系统默认的启动方式，适用于Master和Worker，除非显式声明禁用。

禁用方式为使用环境变量 **`CORE_AUTOR=false`** 或者命令行参数 **`–tor=false`** ，禁用的同时必须指定要连接的Master节点名称： **`CORE_WORKEROF=你的master节点名称`** 或者 **`–workef=你的master节点名称`**。注意：禁用只对Worker部署有效！

自动注册模式下支持配置文件+命令行参数的配置方式，如果设置了命令行参数则会覆盖对应的配置文件参数。

#### 在Windows中运行

演示如何使用命令行参数覆盖配置文件中的IP和端口字段(假设配置文件中的IP是localhost，端口是100)：

* 找到Master的发布目录，执行命令`dotnet Hos.ScheduleMaster.Web.dll –ip=192.168.8.27 –port=30000`启动程序。

* 找到Worker的发布目录，执行命令`dotnet Hos.ScheduleMaster.QuartzHost.dll –urls http://*:30001 –identity=worker1 –ip=192.168.8.27 –port=30001`启动程序。

“`

* 还是在这个Worker的发布目录，执行命令`dotnet Hos.ScheduleMaster.QuartzHost.dll –urls http://*:30002 –identity=worker2 –ip=192.168.8.27 –port=30002`即可再启动一个Worker进程。

“` shell

“`

打开Master的控制台，进入节点管理页面，发现命令行参数已生效。

#### 在Linux中运行

作步骤同上。

#### 在Docker中运行

* 在Master的发布目录中执行`docker build -t ms_master .`命令生成master镜像，再执行`docker run -d -p 30000:30000 –name=”mymaster” ms_master bash –ip=192.168.8.27 –port=30000`运行容器。

“` shell

[ot@master1 ms_master]# docker run -d -p 30000:30000 –name=”mymaster” ms_master –ip=192.168.8.27 –port=30000

3bbbec2398d9147f9aa1d9e57a4741385ffd33558f83320d62a92d011e9aa143

“`

* 在Worker的发布目录中执行`docker build -t ms_worker .`命令生成worker镜像，再执行`docker run -d -p 30001:80 –name=”myworker1″ ms_worker bash –identity=docker-worker1 –ip=192.168.8.27 –port=30001`运行容器启动worker1。

“` shell

[ot@master1 ms_worker1]# docker run -d -p 30001:80 –name=”myworker1″ ms_worker bash –identity=docker-worker1 –ip=192.168.8.27 –port=30001

5e446997d4a28b3c6ec0708a88d42a4d6baad1e5d5ae686d88c03e99c4e2003f

“`

* 继续执行`docker run -d -p 30002:80 –name=”myworker2″ ms_worker bash –identity=docker-worker2 –ip=192.168.8.27 –port=30002`运行容器启动worker2。

“` shell

[ot@master1 ms_worker2]# docker run -d -p 30002:80 –name=”myworker2″ ms_worker bash –identity=docker-worker2 –ip=192.168.8.27 –port=30002

0cad44660657d2251e71b73a46189117ec3aad1445c5176276d32fa06360d56e

“`

* 执行`docker ps`查看各容器运行状态，如果运行不起来请容器log。

可以看到不需要重复给不同的Worker生成镜像了，如果你不使用容器编排工具部署，以上方式已经足够了。

### 手动连接模式

手动连接模式要解决的核心问题是那些不能提前预知IP和端口以及Worker平滑伸缩的场景，使用命令行参数依然要给每个容器(应用)单独指定配置，使用Kubernetes Deployment做伸缩时还是不方便。

这时候可以禁用自动注册，采用手动连接方式和Worker建立通信。下面只介绍在Windows下的使用方式，其他平台也是类似。

* 第一步先启动Worker进程：

“` shell

“`

* 第二步在控制台创建一个节点(注意这里的主机地址要填Worker真实监听的地址)：


* 第三步对节点执行“连接”作，可以看到节点连接成功：

“` shell

info: Hos.ScheduleMaster.QuartzHost.Contllers.QuartzContller[0]

succesully connected to master-node!

“`

节点连接成功后是空闲状态，可以对它执行“启用”开启调度功能。

> 小提示：对于这种部署场景，最好的办法是在项目属中设置环境变量彻底禁用自动注册（或者在Dockerfile中设置环境变量），这样就不用每次通过命令行参数禁用了。

三、编写业务代码

只有在程序集任务下才需要编写自己的业务代码，这种方式虽然实施起来比较麻烦，但灵活更好。

接入流程为：**安装依赖包 -> 开发业务代码 -> 打包上传 -> 创建任务**

### 安装依赖包

– 编译项目后手动添加引用程序集文件`Hos.ScheduleMaster.Base.dll`。

– 在nuget中搜索`ScheduleMaster`直接安装到项目中。

– 程序包管理控制台中使用`install-package ScheduleMaster`安装。

– 在命令行中使用`dotnet add package ScheduleMaster`安装。

### 开发业务代码

业务代码类必须继承自任务基类`Hos.ScheduleMaster.Base.TaskBase`，其中的象方法`public abstract void Run(TaskContext context);`即是业务执行入口，所以只需要重写这个象方法即可。

下面是一个最简单的示例：

#### 使用自定义配置文件：

“`

#### 上下级任务结果传递：

#### 取消一个长任务：

“`

更多的代码示例可以参考源码中的`Hos.ScheduleMaster.Demo`项目，如果您发现了更好的使用场景，欢迎提PR和大家一起分享。

### 打包上传

业务代码开发完成后需要把项目编译成dll文件，并以项目名称为文件名把和业务有关的dll文件以及配置文件打包成一个.zip压缩包，您可以选择两种方式进行上传：

– 在控制台创建任务时通过上传入口上传文件包。

– 使用文件传输方式把文件包上传到master进程的`/wwwot/plugins/`目录下，大文件包推荐这种方式。

在打包和更新文件的过程中有几点要特殊注意下：

– 文件包的命名务必以任务所在的程序集名称命名，否则无法启动。

– 在一个项目中开发了多个任务入口，文件包只需要上传一次即可，但是要注意上传的版本是否覆盖到你所有的任务。

– 任务启动时会默认加载最新的文件包，如果不想使用最新版本可以用系统参数`程序集任务-文件包拉取策略`进行设置。

– 打包时不需要把`Hos.ScheduleMaster.Base.dll`包含进去，否则会启动失败。

– 业务代码尽量减少第三方dll依赖，否则会使得文件包太大导致启动时无法预估的异常。