Служба Windows или планировщик задач для задач обслуживания?
У меня есть приложение C#, которое выполняет некоторые задачи по обслуживанию. Он должен работать примерно каждый час, хотя это не слишком важно, если он немного выключен. И он должен работать на Win2003 Server, когда никто не вошел в систему.
В основном, мне интересно, должен ли я написать службу Windows, и если да, если Thread.Sleep() является правильным способом приостановить поток на час, или есть ли лучшие способы убедиться, что поток остается бездействующим и не помещает любая загрузка сервера? (ака. что является самой противоположностью Спинлока)
Альтернативой является планировщик заданий Windows, но я не уверен, что это хорошо для использования сервера, так как а) мне нужно было бы хранить расписание в нем, а не в моем app.config, б) я не могу легко контролировать службу через запуск / остановка / перезапуск и c) я не знаю, настолько ли безопасны учетные данные пользователя Windows, как при вводе его в оснастку MMC службы.
Каковы ваши мнения? Возможно ли и полезно иметь неработающий Сервис или вы бы порекомендовали вместо него планировщик задач?
6 ответов
Вы можете найти это видео интересным. Хорошее собеседование с инженером, отвечающим за службы Windows, а также выясняет, когда выбрать службу или задачу. В двух словах, если ваша функция попадает в категорию периодического обслуживания, переходите к задаче.
Я предпочитаю сам Планировщик заданий, так как его легче обслуживать и вносить изменения в расписание, если это необходимо.
Кроме того, утилиты, которые работают непрерывно и "спят", рискуют вызвать проблемы, если разработчик "забывает" делать такие вещи, как закрытые соединения, файлы и т. Д., Которые могут накапливаться со временем. Наличие программы "беги и выходи" является дополнительным защитным покрывалом.:-)
Служба Windows более безопасна: никто не может ее отбросить и никогда не работает. Я обнаружил много проблем с задачами Windows (не выполняются, ...).
Планировщик заданий Windows предназначен для задач конечного пользователя, а не для задач приложения. В любом случае, Windows Backup использует его;-)
Я полагаю, что потратить мои 5 центов стоит, использование планировщика задач сэкономит память, когда ваша задача не выполняется.
Я думаю, что служба Windows, вероятно, более надежна и ее легче отслеживать, но она не будет предлагать такую же гибкость планирования, как запланированная задача из коробки. В любом случае, я бы, вероятно, воспользовался сервисом, так как большинство корпоративных приложений обычно работают как сервисы, а не как запланированные задачи.
Для последних проектов я использовал Quartz.NET для настройки обработки по расписанию в службах Windows. Это на самом деле не так уж сложно в настройке (хороший учебник), и CronTrigger даст вам тонну гибкости с минимальными настройками. Мне нравится это лучше, чем сырой.NET Timer.
Если вы идете по пути обслуживания, то я бы порекомендовал использовать System.Threading.Timer. При этом вы можете настроить его на запуск события один раз в час. Вы можете поместить интервал в app.config, если считаете, что вам когда-нибудь понадобится его изменить.
Службы также запускаются под локальной системной учетной записью (по умолчанию), в то время как вы должны указать имя пользователя / пароль при использовании запланированных задач. Если вы используете свое имя пользователя, оно становится проблемой обслуживания, если вы когда-нибудь измените свой пароль и забудете обновить задачу.
У меня есть ситуация, когда я использую комбинацию обоих на самом деле. Служба работает постоянно в течение дня, но каждую ночь они выполняют обслуживание сети и базы данных. Итак, я использую две запланированные задачи. Один, чтобы отключить службу в полночь, и один, чтобы включить его в 4 часа утра. Это делается путем вызова файлов.BAT с помощью команд NET STOP/ NET START.