ScheduleMaster(分布式任务调度系统)

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

软件功能

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

　　简易的Web UI操作；

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

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

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

　　支持自定义参数设置；

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

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

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

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

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

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

　　用户访问控制；

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

　　调度报表统计；

　　任务分组管理；

　　计划表拆分实现复用；

　　指定节点运行；

　　支持http任务配置；

　　支持延时任务；

　　任务监控；

　　资源监控；

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

　　接入redis缓存；

　　多数据库类型支持；

　　用户权限更加精细化；

　　报表统计完善；

软件特色

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

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

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

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

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

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

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

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

官方教程

　　一、部署方式介绍

　　由于.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`、`--protocol`、`--ip`、`--port`、`--priority`、`--maxc`，这种模式下还是要依赖于配置文件，只是动态参数有更高的优先级。

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

　　- 使用环境变量，设置 **`SMCORE_AUTOR=false`** 和 **`SMCORE_WORKEROF=你的master节点名称`**。

　　- 使用命令行参数，设置 **`--autor=false`** 和 **`--workerof=你的master节点名称`**。

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

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

　　二、动态参数启动

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

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

　　### 自动注册节点

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

　　禁用方式为使用环境变量 **`SMCORE_AUTOR=false`** 或者命令行参数 **`--autor=false`** ，禁用的同时必须指定要连接的Master节点名称： **`SMCORE_WORKEROF=你的master节点名称`** 或者 **`--workerof=你的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

　　[root@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

　　[root@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

　　[root@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.Controllers.QuartzController[0]

　　successfully 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进程的`/wwwroot/plugins/`目录下，大文件包推荐这种方式。

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

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

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

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

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

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