计划任务或Windows服务

Question

我的团队正在进行一场辩论，讨论哪种方式更好：Windows服务还是计划任务。 我们有一台专门用于运行作业的服务器，目前所有作业都是计划任务。 有些作业需要文件，将它们重命名并将它们放在网络上的其他目录中。其他作业从SQL中提取数据，对其进行修改，并将其传送到其他地方。其他作业将文件FTP出去。 尽管工作内容各不相同，但总的来说，它们都相当简单。

我倾向于将每个作业作为 Windows 服务运行，而不是计划任务，因为监视 Windows 服务比监视计划任务要容易得多。 有些人则持完全相反的观点。 最终，我们都没有那么多经验可以提供两种方法之间的实际比较。 我想听听其他人的经验和反馈。

- user177213

Answer 1

定时任务 -

1. 在固定/预定义的时间表上执行活动。
2. 占用较少的内存和操作系统资源。
3. 不需要安装。
4. 可以有用户界面（例如，向拖欠款项的人发送提醒邮件）。

Windows服务 -

1. 需要持续监控时使用。
2. 通过消耗更多的资源使操作系统忙碌。
3. 在更改版本时需要安装/卸载。
4. 没有用户界面（例如，一封邮件到达时立即处理）。

明智地使用它们

- Sumit Kapadia

Answer 2

如果需要持续运行 - Windows服务。

如果需要在不同的时间间隔内运行 - 计划任务。

- wefwfwefwe

Answer 3

使用内置功能进行作业调度是完全有效的用途。如果要创建一个好的服务，您将不得不重新创建全部功能，除非您想要对特定事件做出反应，否则我认为没有理由将夜间作业转移到服务中。

当您想要在文件发布到文件夹后处理该文件时，情况就不同了，这是我会创建一个服务的情况，即使用文件系统监视器监视文件夹。

我认为这是重复造轮子。

- Heiko Hatzfeld

Answer 4

虽然使用任务计划程序没有问题，但它本身就是一个服务。但我们在工作中有相同的要求，我们有一个通用程序可以完成多个任务。我理解你的帖子是说你会为每个任务运行单独的服务，我建议编写一个单一的、数据库驱动的（服务）程序来完成所有任务，这样，当你添加一个新任务时，只需进行数据输入即可，而不是编写一个全新的程序。如果你实践变更控制，这种差异可能会很大。如果你有多个任务，这种方法的努力可能是可比较的。这种方法还允许你制定最适合你操作的日志记录机制。

以下是我们任务程序需求文档的一部分，以便给你一个起点：

这个程序需要与数据库连接。它需要作为Windows服务运行。程序需要能够按以下方式处理“作业”： - 作业需要检查源文件是否存在，并根据源文件的存在与否采取相应措施（即进行处理、报告文件不存在或忽略文件因不重要而不存在）。 - 作业需要能够将文件从源位置复制到目标位置，或者 - 将文件从源位置复制到暂存位置，执行“处理”，然后将原始文件或“处理”结果复制到目标位置，或者 - 将文件从源位置复制到暂存位置，执行“处理”，并以此结束。 - 可以从各种不同的来源和目标复制作业：UNC、SFTP、FTP等。 - “处理”可以是加密/解密文件、解析数据文件以确保格式正确、通过终端仿真将文件传输到主机等，通常通过调用命令行传递参数给.exe来实现。 - 作业需要根据需要自行清理，例如删除中间或原始文件，将文件复制到归档位置等。 - 程序需要能够确定每个作业阶段的成功和失败，并采取适当的行动，如记录日志、可能的其他通知、在失败时中止进一步处理等。 - 作业需要配置为在特定的时间或间隔（可选地在特定的小时内）激活，例如每15分钟从9:00 - 5:00。 - 需要有一个UI来添加新的作业。 - 需要一个按钮来触发作业，就像定时器事件已激活它一样。 - 程序的标准显示应向操作员显示正在进行的情况以及程序是否正常运行。

所有这些都是建立在您编写自己的软件的前提下。市场上有几个企业任务调度程序可供选择，购买现成的可能是更好的解决方案。

- Ken Lange

---

听起来SQL Server Integration Services可能非常适合您提到的要求，只需使用一些自定义的ScriptTasks来执行那些没有提供开箱即用操作。如果您已经实现了这些任务的.exe文件（正如您所提到的），那么您可以在SSIS框架内使用它们。部署可以使用SQL Server Jobs进行管理，可以根据需要或按计划进行。 - Caleb Bell

当然，这是建立在您已经使用SQL Server的假设之上的 - 我不知道其他供应商提供了什么替代品... - Caleb Bell