Windows 服务与计划任务

Question

Windows 服务与重复运行程序（例如每两分钟）的计划任务相比有何优缺点？

Answer 1

更新：

距离我原来的答案已经过去近四年了，这个答案已经非常过时了。 自从 TopShelf 出现以来，Windows 服务开发变得很容易。 现在你只需要弄清楚如何支持故障转移...

原始答案：

我真的不喜欢Windows Scheduler。 必须按照上面指出的 @moodforall 提供用户密码，当有人更改用户密码时，这很有趣。

Windows Scheduler 的另一个主要烦恼是它以交互方式运行，而不是作为后台进程运行。 当 RDP 会话期间每 20 分钟弹出 15 个 MS-DOS 窗口时，您会后悔没有将它们安装为 Windows 服务。

无论您选择什么，我当然建议您将处理代码从控制台应用程序或 Windows 服务中分离到不同的组件中。 然后您可以选择从控制台应用程序调用工作进程并将其挂接到 Windows Scheduler，或者使用 Windows 服务。

您会发现安排 Windows 服务并不有趣。 一个相当常见的场景是，您有一个长时间运行的进程，并且希望定期运行。 但是，如果您正在处理队列，那么您确实不希望同一工作线程的两个实例处理同一队列。 因此，您需要管理计时器，以确保长时间运行的进程运行时间超过指定的计时器间隔，它不会再次启动，直到现有进程完成。

写完所有这些后，您会想，为什么我不直接使用 Thread.Sleep？ 这允许我让当前线程继续运行直到完成，然后暂停间隔开始，线程进入睡眠状态并在所需时间后再次启动。 整洁的！

然后，您阅读互联网上的所有建议，许多专家告诉您这是非常糟糕的编程实践：

http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep -is-a-sign-of-a-poorly-Designed-program.aspx

所以你会摸不着头脑，心里想，WTF，撤消待处理结账 -> 是的，我确定 -> 撤消今天所有的工作......该死，该死，该死......

但是，我确实喜欢这种模式，即使每个人都认为这是垃圾：

单线程方法的 OnStart 方法。

受保护的覆盖 void OnStart (string args) { 

     // 创建工作线程；   这将调用 WorkerFunction 
     // 当我们启动它时。 
     // 由于我们使用单独的工作线程，所以主服务 
     // 线程会快速返回，告诉Windows服务已经启动 
     ThreadStart st = new ThreadStart(WorkerFunction); 
     工作线程=新线程（st）； 

     // 设置标志以指示工作线程处于活动状态 
     服务启动=真； 

     // 启动线程 
     工作线程.Start(); 
  } 
  

代码实例化一个单独的线程并附加我们的工作线程
对它起作用。 然后它启动线程并让 OnStart 事件
完整，这样 Windows 就不会认为该服务已挂起。

单线程方法的工作方法。

/// <摘要> 
  /// 该函数将完成所有工作 
  /// 一旦完成任务，它将暂停一段时间； 
  /// 它将继续重复此操作，直到服务停止 
  ///  
  私有无效 WorkerFunction() { 

     // 开始无限循环；   仅当“serviceStarted”时循环才会中止 
     // 标志=假 
     while (服务启动) { 

        // 做一点事 
        // 为了简单起见，这里省略了异常处理 
        EventLog.WriteEntry("服务正在运行", 
           系统.诊断.EventLogEntryType.信息); 

        // 屈服 
        如果（服务已启动）{ 
           Thread.Sleep(new TimeSpan(0, 间隔, 0)); 
        } 
     } 

     // 结束线程的时间 
     Thread.CurrentThread.Abort(); 
  } 
  

单线程方法的 OnStop 方法。

受保护的覆盖 void OnStop() { 

     // 告诉工作进程停止的标志 
     服务启动=假； 

     // 给它一点时间来完成任何未完成的工作 
     workerThread.Join(new TimeSpan(0,2,0)); 
  } 
  

来源：http://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread ( Dead Link）

多年来我一直在运行大量这样的 Windows 服务，它对我很有用。 我还没有看到人们同意的推荐模式。 只做对你有用的事情。

Answer 2

这里有一些错误信息。 Windows Scheduler 完全能够在后台运行任务，不会弹出窗口，也不需要密码。 在 NT AUTHORITY\SYSTEM 帐户下运行它。 使用这个 schtasks 开关：

/ru 系统

但是，是的，为了访问网络资源，最佳实践是使用具有单独的不过期密码策略的服务帐户。

编辑

根据您的操作系统和任务本身的要求，您可能可以通过 /ru 选项使用权限低于 Localsystem 的帐户。

从精美的手册，

/RU username

A value that specifies the user context under which the task runs. 
For the system account, valid values are "", "NT AUTHORITY\SYSTEM", or "SYSTEM". 
For Task Scheduler 2.0 tasks, "NT AUTHORITY\LOCALSERVICE", and 
"NT AUTHORITY\NETWORKSERVICE" are also valid values.

Task Scheduler 2.0 在 Vista 和 Server 2008 中可用。

在 XP 和 Server 2003 中，系统 是唯一的选项。

Answer 3

在 .NET 开发中，我通常首先开发一个控制台应用程序，该应用程序将运行所有日志输出到控制台窗口。 但是，当使用命令参数 /console 运行时，这仅是一个控制台应用程序。 当它在没有此参数的情况下运行时，它充当 Windows 服务，它将在我自己的自定义编码的计划计时器上保持运行。

我认为 Windows 服务通常用于管理其他应用程序，而不是长时间运行的应用程序。 或者..它们是连续运行的重量级应用程序，例如 SQL Server、BizTalk、RPC Connections、IIS（即使 IIS 在技术上将工作卸载到其他进程）。

就我个人而言，我更喜欢使用计划任务而不是 Window Services 来执行重复性维护任务和应用程序，例如文件复制/同步、批量电子邮件发送、文件删除或归档、数据更正（当其他解决方法不可用时）。

在一个项目中，我参与了 8 或 9 个 Windows 服务的开发，但这些服务都闲置在内存中，每个实例占用 20MB 或更多内存。 计划任务将执行其任务，并立即释放内存。

Answer 4

启动和退出应用程序的开销是多少？ 每两分钟一次是很常见的。 与如此频繁地执行应用程序相比，服务可能会让系统运行得更顺畅。

两种解决方案都可以在用户未登录时运行程序，因此没有区别。 不过，编写服务比常规桌面应用程序更复杂 - 您可能需要一个单独的 GUI 客户端，它将通过 TCP/IP、命名管道等与服务应用程序进行通信。

从用户的角度来看，我想知道哪个更容易控制。 对于大多数非技术用户来说，服务和计划任务几乎是遥不可及的，即他们甚至不会意识到它们的存在并且可以配置/停止/重新计划等等。

Answer 5

“service”一词与“serv”有一些共同点。 它预计将始终运行并“提供服务”。 任务就是任务。

角色扮演。 如果我是另一个操作系统、应用程序或设备，并且我调用一个服务，我期望它能够运行并且期望得到响应。 如果我（操作系统、应用程序、开发人员）只需要执行一个独立的任务，那么我将执行一个任务，但如果我期望进行通信，可能是双向通信，我需要一个服务。 这与两个事物或想要执行单个任务的单个事物进行通信的最有效方式有关。

然后是日程安排方面。 如果您希望某些内容在特定时间运行，请安排时间。 如果您不知道何时需要它，或者“即时​​”需要它，请提供服务。

我的回答本质上更具哲学性，因为这与人类互动和工作的方式非常相似。 我们越了解沟通的艺术，“实体”了解他们的角色，这个决定就越容易。

抛开所有的哲学不谈，当你“快速制作原型”时，就像我的 IT 部门经常做的那样，你会做任何你必须做的事情来维持收支平衡。 一旦原型设计和概念验证的内容完成（通常是在早期规划和发现过程中），您就必须决定什么对长期可持续性更可靠。

好吧，总而言之，它高度依赖于很多因素，但希望这能提供洞察力而不是混乱。

Answer 6

Windows 服务不需要任何人登录，并且 Windows 具有停止、启动和记录服务结果的功能。

计划任务不需要您学习如何编写 Windows 服务。

Answer 7

1. 使用正确的权限可以更轻松地设置和锁定 Windows 服务。
2. 服务更加“可见”，这意味着每个人（即：技术人员）都知道去哪里寻找。

Answer 8

这是一个老问题，但我想分享我所面临的问题。

最近我接到一个要求，每隔 10 分钟捕获一次雷达的屏幕截图（来自气象网站）并保存在服务器中。

这需要我使用网络浏览器。
我通常制作 Windows 服务，所以我决定也制作这一项服务，但它会不断崩溃。
这是我在事件查看器中看到的
故障模块路径：C:\Windows\system32\MSHTML.dll

由于任务紧急，我研究和实验的时间很少，所以我决定使用一个简单的控制台应用程序并将其触发为任务并顺利执行。

我真的很喜欢马克·兰塞姆接受的答案中推荐的乔恩·加洛韦的文章。

最近，服务器上的密码在未经我同意的情况下被更改，所有服务都无法执行，因为它们无法登录。
因此，有人在文章中声称这是一个问题。 我认为Windows服务也可能面临同样的问题（如果我错了，请纠正我，我只是一个新手）

另外提到的事情，如果使用任务计划程序窗口弹出或控制台窗口弹出。
我从来没有遇到过这样的情况。 它可能会弹出，但至少是瞬时的。

Answer 9

为什么不两者都提供呢？

过去，我将“核心”部分放入库中，并将对 Whatever.GoGoGo() 的调用包装在服务和控制台应用程序中。

对于每两分钟发射一次的东西，很有可能它没有做太多事情（例如，只是一个“ping”类型的函数）。 包装器不必包含比单个方法调用和一些日志记录更多的内容。

Answer 10

一般来说，核心信息是并且应该是代码本身必须可以从每个“触发器/客户端”执行。 因此，从一种方法转向另一种方法不应该是一件复杂的事情。

过去，我们或多或少总是使用 Windows 服务，但由于越来越多的客户逐步切换到 Azure，并且从控制台应用程序（作为计划任务部署）到 Azure 中的 WebJob 的交换比从Windows 服务，我们现在关注计划任务。 如果我们遇到限制，我们只需加强 Windows 服务项目并从那里调用相同的逻辑（只要客户在 OnPrem 上工作..）:)

BR,
y

Answer 11

Windows 服务需要更多耐心，直到完成。
它的调试和安装有点困难。 真是不要脸了
如果您需要一项必须每秒、每分钟或每小时完成的任务，
你应该选择Windows服务。

计划任务发展很快，有面子。
如果您需要每日或每周任务，可以使用计划任务。