Служба Windows vs запланированное задание
Каковы преимущества и недостатки служб Windows по сравнению с запланированными задачами для повторного запуска программы (например, каждые две минуты)?
10 ответов
Обновить:
Спустя почти четыре года после моего первоначального ответа, и этот ответ очень устарел. С появлением TopShelf разработка служб Windows стала легкой. Теперь вам просто нужно выяснить, как поддерживать отказоустойчивость...
Оригинальный ответ:
Я действительно не фанат Windows Scheduler. Пароль пользователя должен быть указан, как указано выше @moodforall, что очень удобно, когда кто-то меняет пароль этого пользователя.
Другой большой недостаток планировщика Windows заключается в том, что он работает в интерактивном режиме, а не в качестве фонового процесса. Когда каждые 20 минут во время сеанса RDP появляются 15 окон MS-DOS, вы пинаете себя, что вместо этого не установили их как службы Windows.
Что бы вы ни выбрали, я, безусловно, рекомендую вам отделить код обработки в другом компоненте от приложения консоли или службы Windows. Затем у вас есть выбор: либо вызвать рабочий процесс из консольного приложения и подключить его к планировщику Windows, либо использовать службу Windows.
Вы обнаружите, что планирование службы Windows не весело. Довольно распространенным сценарием является то, что у вас есть длительный процесс, который вы хотите периодически запускать. Но если вы обрабатываете очередь, то вам не нужно, чтобы два экземпляра одного и того же работника обрабатывали одну и ту же очередь. Таким образом, вам нужно управлять таймером, чтобы убедиться, что ваш длительный процесс запущен дольше, чем назначенный интервал таймера, он не запускается снова, пока не завершится существующий процесс.
После того, как вы все это написали, вы думаете, почему я просто не использовал Thread.Sleep? Это позволяет мне позволить текущему потоку продолжать работу до тех пор, пока он не завершится, а затем начинается интервал паузы, поток переходит в спящий режим и снова запускается через требуемое время. Ухоженная!
Затем вы читаете все советы в Интернете с большим количеством экспертов, рассказывающих, как это действительно плохая практика программирования:
Таким образом, вы почесаете голову и подумаете про себя, WTF, Отменить ожидающие проверки -> Да, я уверен -> Отменить всю сегодняшнюю работу..... черт, черт, черт....
Тем не менее, мне нравится этот шаблон, даже если все думают, что это дерьмо:
Метод OnStart для однопоточного подхода.
protected override void OnStart (string args) { // Create worker thread; this will invoke the WorkerFunction // when we start it. // Since we use a separate worker thread, the main service // thread will return quickly, telling Windows that service has started ThreadStart st = new ThreadStart(WorkerFunction); workerThread = new Thread(st); // set flag to indicate worker thread is active serviceStarted = true; // start the thread workerThread.Start(); }Код создает отдельный поток и присоединяет к нему нашу рабочую функцию. Затем он запускает поток и позволяет завершить событие OnStart, чтобы Windows не думала, что служба зависла.
Рабочий метод для однопоточного подхода.
/// <summary> /// This function will do all the work /// Once it is done with its tasks, it will be suspended for some time; /// it will continue to repeat this until the service is stopped /// </summary> private void WorkerFunction() { // start an endless loop; loop will abort only when "serviceStarted" // flag = false while (serviceStarted) { // do something // exception handling omitted here for simplicity EventLog.WriteEntry("Service working", System.Diagnostics.EventLogEntryType.Information); // yield if (serviceStarted) { Thread.Sleep(new TimeSpan(0, interval, 0)); } } // time to end the thread Thread.CurrentThread.Abort(); }Метод OnStop для однопоточного подхода.
protected override void OnStop() { // flag to tell the worker process to stop serviceStarted = false; // give it a little time to finish any pending work workerThread.Join(new TimeSpan(0,2,0)); }
Источник: http://en.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1:_Use_a_Separate_Thread (Мертвая ссылка)
Я много лет запускал Windows Services, и это работает для меня. Я все еще не видел рекомендуемый образец, с которым люди соглашаются. Просто делай то, что работает для тебя.
Некоторая дезинформация здесь. Планировщик Windows прекрасно способен выполнять задачи в фоновом режиме без всплывающих окон и без пароля. Запустите его под учетной записью NT AUTHORITY\SYSTEM. Используйте этот переключатель schtasks:
/ ru СИСТЕМА
Но да, для доступа к сетевым ресурсам рекомендуется использовать служебную учетную запись с отдельной политикой паролей без истечения срока действия.
РЕДАКТИРОВАТЬ
В зависимости от вашей ОС и требований самой задачи вы можете использовать учетные записи с меньшими правами, чем у Localsystem с /ru вариант.
Из прекрасного руководства,
/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.
Планировщик заданий 2.0 доступен в Vista и Server 2008.
В XP и Server 2003 system это единственный вариант.
При разработке.NET я обычно начинаю с разработки консольного приложения, которое будет запускать все записи журнала в окне консоли. Тем не менее, это только консольное приложение, когда оно запускается с аргументом команды /console, Когда он запускается без этого параметра, он действует как служба Windows, которая будет работать в моем собственном кодированном таймере.
Я считаю, что службы Windows обычно используются для управления другими приложениями, а не как долго работающие приложения. ИЛИ.. это постоянно работающие тяжелые приложения, такие как SQL Server, BizTalk, RPC-соединения, IIS (даже если IIS технически разгружает работу для других процессов).
Лично я предпочитаю запланированные задачи, а не Windows Services, для выполнения задач и приложений для повторяющегося обслуживания, таких как копирование / синхронизация файлов, массовая отправка электронной почты, удаление или архивирование файлов, исправление данных (когда другие обходные пути недоступны).
Для одного проекта я принимал участие в разработке 8 или 9 служб Windows, но они сидят в памяти, простаивают, потребляя 20 МБ или больше памяти на экземпляр. Запланированные задачи сделают свое дело и немедленно освободят память.
Каковы издержки запуска и выхода из приложения? Каждые две минуты довольно часто. Служба, вероятно, позволит системе работать более плавно, чем выполнение вашего приложения так часто.
Оба решения могут запускать программу, когда пользователь не вошел в систему, поэтому никакой разницы нет. Написание службы несколько сложнее, чем обычное приложение для настольного компьютера - вам может понадобиться отдельный клиент с графическим интерфейсом, который будет взаимодействовать с приложением-службой через TCP/IP, именованные каналы и т. Д.
Интересно, что из POV пользователя легче контролировать. И сервисы, и запланированные задачи практически недоступны для большинства нетехнических пользователей, то есть они даже не осознают своего существования и могут быть настроены / остановлены / перепланированы и т. Д.
Слово "serv'ice" имеет нечто общее с "serv'er". Ожидается, что он всегда будет запущен, и 'serv'e. Задача есть задача.
Ролевая игра. Если я являюсь другой операционной системой, приложением или устройством и вызываю службу, я ожидаю, что она будет запущена, и ожидаю ответа. Если мне (os, app, dev) просто нужно выполнить изолированное задание, тогда я выполню задание, но если я ожидаю связи, возможно, двухсторонней связи, я хочу услугу. Это связано с наиболее эффективным способом общения двух вещей или единственной вещью, которая хочет выполнить одну задачу.
Тогда есть аспект планирования. Если вы хотите что-то запустить в определенное время, запланируйте. Если вы не знаете, когда вам это понадобится, или вам это нужно "на лету", сервис.
Мой ответ носит более философский характер, потому что это очень похоже на то, как люди взаимодействуют и работают с другим. Чем больше мы понимаем искусство общения и "сущности" понимают свою роль, тем легче становится это решение.
Если оставить в стороне всю философию, когда вы "быстро создаете прототипы", как часто делает мой ИТ-отдел, вы делаете все, что вам нужно, чтобы сводить концы с концами. После того, как создание прототипов и подтверждение концепции ушли с пути, как правило, на раннем этапе планирования и обнаружения, вы должны решить, что является более надежным для обеспечения долгосрочной устойчивости.
Итак, в заключение, это сильно зависит от многих факторов, но, надеюсь, это дало понимание, а не путаницу.
- Проще настроить и заблокировать службы Windows с правильными разрешениями.
- Сервисы более "видимы", что означает, что каждый (например, технический специалист) знает, где искать.
Службе Windows не нужно, чтобы кто-либо входил в систему, а в Windows есть средства для остановки, запуска и регистрации результатов службы.
Запланированное задание не требует от вас обучения написанию службы Windows.
Это старый вопрос, но я хотел бы поделиться тем, с чем я столкнулся.
Недавно мне было предложено сделать снимок экрана радара (с метеорологического сайта) и сохранять его на сервере каждые 10 минут.
Это потребовало от меня использовать WebBrowser. Я обычно делаю службы Windows, поэтому я решил сделать эту службу тоже, но она будет продолжать падать. Это то, что я увидел в Путь к модулю " Просмотр событий ": C:\Windows\system32\MSHTML.dll
Поскольку задача была срочной, и у меня было очень мало времени на исследования и эксперименты, я решил использовать простое консольное приложение и запустил его как задачу, и оно выполнялось гладко.
Мне очень понравилась статья Джона Галлоуэя, рекомендованная в принятом ответе Марком Рэнсомом.
Недавно пароли на серверах были изменены без подтверждения, и все службы не удалось выполнить, так как они не могли войти в систему. Таким образом, в статье утверждается, что это проблема. Я думаю, что службы Windows могут столкнуться с той же проблемой (пожалуйста, поправьте меня, если я ошибаюсь, я просто новичок)
Также упомянутая вещь, если вы используете всплывающие окна планировщика задач или окно консоли. Я никогда не сталкивался с этим. Это может всплыть, но это, по крайней мере, очень мгновенно.
Почему бы не предоставить оба?
В прошлом я помещал "основные" биты в библиотеку и заключал в себе вызов Whither.GoGoGo() как в сервисе, так и в консольном приложении.
С чем-то, что вы запускаете каждые две минуты, шансы приличные, но это мало что делает (например, просто функция типа "ping"). Оболочки не должны содержать намного больше, чем один вызов метода и некоторое журналирование.
Как правило, основная идея заключается и должна заключаться в том, что сам код должен исполняться от каждого "триггера / клиента". Так что переход от одного подхода к другому не должен быть ракетной наукой.
Раньше мы более или менее всегда использовали службы Windows, но так как все больше и больше наших клиентов переходят на Azure шаг за шагом, а переход с консольного приложения (развернутого как запланированная задача) на веб-задание в Azure намного проще, чем из Служба Windows, мы пока сосредоточены на запланированных задачах. Если мы сталкиваемся с ограничениями, мы просто расширяем проект службы Windows и вызываем ту же логику оттуда (пока клиенты работают с OnPrem..):)
BR,y
Службы Windows хотят больше терпения, пока это не будет сделано. Он имеет немного сложную отладку и установку. Это безлико. Если вам нужна задача, которую нужно выполнять каждую секунду, минуту или час, вам следует выбрать Windows Service.
Запланированная задача быстро развивается и имеет лицо. Если вам нужно ежедневное или еженедельное задание, вы можете использовать запланированное задание.