Служба windows vs запланированное задание - программирование
Подтвердить что ты не робот

Служба windows vs запланированное задание

Каковы преимущества и преимущества служб windows или запланированных задач для повторного запуска программы (например, каждые две минуты)?

4b9b3361

ОТВЕТЫ

Ответ 1

Update:

Спустя почти четыре года после моего первоначального ответа, и этот ответ очень устарел. Поскольку TopShelf пришла к разработке Windows Services, стало легко. Теперь вам просто нужно выяснить, как поддерживать переход на другой ресурс...

Оригинальный ответ:

Я действительно не поклонник Windows Scheduler. Пароль пользователя должен быть предоставлен как @moodforall, который является забавным, когда кто-то меняет этот пароль пользователя.

Другим серьезным раздражением в Windows Scheduler является то, что он работает интерактивно, а не как фоновый процесс. Когда 15 минут MS-DOS появляются каждые 20 минут во время сеанса RDP, вы будете пинать себя, не устанавливая их как службы Windows.

Независимо от того, что вы выберете, я, безусловно, рекомендую вам разделить код обработки на другой компонент из консольного приложения или службы Windows. Тогда у вас есть выбор: вызвать рабочий процесс из консольного приложения и подключить его к планировщику Windows или использовать службу 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, Undo Pending Checkouts → Да, я уверен → Отмените все сегодняшние работы..... черт побери, черт возьми, черт....

Однако мне нравится этот шаблон, даже если все думают, что это дерьмо:

Метод 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://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (Dead Link )

В течение многих лет я запускал множество Windows-сервисов, и это работает для меня. Я до сих пор не видел рекомендованной модели, о которой люди согласны. Просто делайте то, что работает для вас.

Ответ 2

Некоторая дезинформация здесь. Планировщик Windows отлично справляется с выполнением задач в фоновом режиме без всплывающих окон и без необходимости пароля. Запустите его в учетной записи NT AUTHORITY\SYSTEM. Используйте этот переключатель schtasks:

/ru SYSTEM

Но да, для доступа к сетевым ресурсам наилучшей практикой является учетная запись службы с отдельной политикой без истечения срока действия пароля.

ИЗМЕНИТЬ

В зависимости от вашей ОС и требований самой задачи вы можете использовать учетные записи, менее привилегированные, чем 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.

Task Scheduler 2.0 доступен из Vista и Server 2008.

В XP и Server 2003 единственная опция system.

Ответ 3

Какие накладные расходы на запуск и выход из приложения? Каждые две минуты довольно часто. Служба, вероятно, позволит системе работать более плавно, чем выполнение вашего приложения так часто.

Оба решения могут запускать программу, когда пользователь не входит в систему, поэтому никакой разницы нет. Написание услуги несколько более активно, чем обычное настольное приложение, но вам может понадобиться отдельный клиент GUI, который будет связываться с сервисным приложением через TCP/IP, именованные каналы и т.д.

От пользователя POV, мне интересно, что легче контролировать. Обе службы и запланированные задачи в значительной степени недоступны для большинства нетехнических пользователей, т.е. Они даже не поймут, что они существуют, и могут быть настроены/остановлены/перенесены и т.д.

Ответ 4

В .NET-разработке я обычно начинаю с разработки Консольного приложения, которое будет запускать все записи журнала в консольное окно. Однако это только консольное приложение, когда оно запускается с аргументом команды /console. Когда он запускается без этого параметра, он действует как служба Windows, которая будет работать на моем собственном запрограммированном запрограммированном таймере.

Службы Windows, я думаю, обычно используются для управления другими приложениями, а не для долгого приложения. OR.. они являются постоянно работающими тяжеловесными приложениями, такими как SQL Server, BizTalk, RPC Connections, IIS (хотя IIS технически разгружает работу с другими процессами).

Лично я выступаю за запланированные задачи над Window Services за повторяющиеся задачи обслуживания и приложения, такие как копирование/синхронизация файлов, массовая отправка электронной почты, удаление или архивирование файлов, коррекция данных (когда другие обходные пути недоступны).

Для одного проекта я участвовал в разработке 8 или 9 служб Windows, но они сидят в памяти, без дела, едят 20 МБ или больше памяти на один экземпляр. Запланированные задачи будут выполнять свою деятельность и немедленно освободить память.

Ответ 5

Слово "serv'ice" имеет нечто общее с "serv'er". Ожидается, что он всегда будет работать и "обслуживать". Задача - задача.

Ролевая игра. Если я другая операционная система, приложение или устройство, и я звоню в службу, я ожидаю, что она будет работать, и я ожидаю ответа. Если мне (os, app, dev) просто нужно выполнить изолированную задачу, тогда я выполню задачу, но если я ожидаю связи, возможно, двухсторонней связи, я хочу сервис. Это связано с наиболее эффективным способом взаимодействия двух вещей или с одной задачей, которая хочет выполнить одну задачу.

Затем есть аспект планирования. Если вы хотите, чтобы что-то запускалось в определенное время, расписание. Если вы не знаете, когда вам это понадобится, или вам нужно "на лету", служба.

Мой ответ более философский по своей природе, потому что это очень похоже на то, как люди взаимодействуют и работают с другим. Чем больше мы понимаем искусство общения, а "сущности" понимаем их роль, тем легче это решение становится.

Вся философия в стороне, когда вы "быстро прототипируете", как часто это делает мой ИТ-отдел, вы делаете все, что у вас есть, чтобы свести концы с концами. После того, как прототипирование и доказательство концептуального материала в стороне, как правило, в раннем планировании и обнаружении, вы должны решить, что более надежно для долгосрочной устойчивости.

ОК, поэтому в заключение он сильно зависит от множества факторов, но, надеюсь, это обеспечило понимание, а не путаницу.

Ответ 6

  • Легче настроить и заблокировать службы Windows с правильными разрешениями.
  • Услуги более "видимы", что означает, что все (т.е. технологии) знают, где искать.

Ответ 7

Службе Windows не нужно, чтобы кто-либо вошел в систему, а в Windows есть возможности для остановки, запуска и регистрации результатов службы.

Запланированное задание не требует, чтобы вы узнали, как писать службу Windows.

Ответ 8

Почему бы не обеспечить оба?

В прошлом я поместил "основные" биты в библиотеку и завернул вызов Whatever.GoGoGo() как в службе, так и в консольном приложении.

С чем-то, с которым вы стреляете каждые две минуты, вероятность того, что он не делает много (например, просто функция типа "пинг" ). Обертки не должны содержать гораздо больше, чем один вызов метода и некоторые протоколирования.

Ответ 9

Это старый вопрос, но я хотел бы поделиться тем, с чем я столкнулся.

Недавно мне было дано требование захватить снимок экрана радара (с метеорологического веб-сайта) и сохранить его на сервере каждые 10 минут.

Это потребовало от меня использования WebBrowser. Обычно я делаю услуги Windows, поэтому я решил сделать эту услугу, но она будет терпеть крах. Это то, что я видел в Event Viewer Отказоустойчивый путь модуля: C:\Windows\system32\MSHTML.dll

Поскольку задача была срочной, и у меня было очень мало времени для исследований и экспериментов, я решил использовать простое консольное приложение и запускал его как задачу, и он выполнялся плавно.

Мне очень понравилась статья статьи Джона Галлоуэя, рекомендованная в принятом ответе Марка Рэнсом.

Недавно пароли на серверах были изменены без подтверждения, и все службы не выполнялись, так как они не могли войти в систему. Поэтому в заявлении ppl в статье отмечается, что это проблема. Я думаю, что службы Windows могут столкнуться с одной и той же проблемой (пожалуйста, исправьте меня, если я ошибаюсь, я jus новичок)

Также упомянутая вещь, если всплывают окна планировщика задач или появляется окно консоли. Я никогда не сталкивался с этим. Он может появиться, но это, по крайней мере, очень мгновенно.

Ответ 10

Службы Windows требуют больше терпения, пока это не будет сделано. Он немного жестко отлаживает и устанавливает. Он безликий. Если вам нужна задача, которая должна выполняться каждую секунду, минуту или час, вы должны выбрать Windows Service.

Запланированная задача быстро развивается и имеет лицо. Если вам нужна ежедневная или недельная задача, вы можете использовать запланированную задачу.