Windows 서비스 대 예약 된 작업

프로그램을 반복적으로 (예 : 2 분마다) 실행하기위한 Windows 서비스와 예약 된 작업의 장단점은 무엇입니까?

최신 정보:

나의 원래 답변이 거의 4 년 후이 답변은 매우 구식입니다. TopShelf 가 Windows 서비스와 함께 나왔기 때문에 개발이 쉬워졌습니다. 이제 장애 조치를 지원하는 방법을 알아 내면됩니다.

원래 답변 :

저는 Windows Scheduler의 팬이 아닙니다. 위의 @moodforall이 지적한 대로 사용자의 비밀번호를 제공해야 하는데, 누군가 해당 사용자의 비밀번호를 변경하면 재미있을 것입니다.

Windows 스케줄러의 또 다른 주요 성가심은 백그라운드 프로세스가 아닌 대화식으로 실행된다는 것입니다. RDP 세션 중에 20 분마다 15 개의 MS-DOS 창이 나타나면 대신 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 서비스를 실행 해 왔으며 저에게 효과적입니다. 사람들이 동의하는 권장 패턴을 아직 보지 못했습니다. 당신에게 맞는 일을하십시오.

여기에 잘못된 정보가 있습니다. Windows 스케줄러는 창을 띄우지 않고 암호없이 백그라운드에서 작업을 완벽하게 실행할 수 있습니다. NT AUTHORITY \ SYSTEM 계정으로 실행하십시오. 이 schtasks 스위치를 사용하십시오.

/ ru 시스템

그러나 예, 네트워크 리소스에 액세스하기위한 모범 사례는 별도의 만료되지 않는 암호 정책이있는 서비스 계정입니다.

편집하다

OS 및 작업 자체의 요구 사항에 따라 /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.

작업 스케줄러 2.0 은 Vista 및 Server 2008에서 사용할 수 있습니다.

XP 및 Server 2003에서는 system유일한 옵션입니다.

앱을 시작하고 종료하는 데 드는 오버 헤드는 무엇입니까? 2 분마다 꽤 자주 있습니다. 서비스를 사용하면 응용 프로그램을 자주 실행하는 것보다 시스템을 더 원활하게 실행할 수 있습니다.

두 솔루션 모두 사용자가 로그인하지 않았을 때 프로그램을 실행할 수 있으므로 차이가 없습니다. 서비스 작성은 일반 데스크톱 앱보다 다소 복잡합니다. TCP / IP, 명명 된 파이프 등을 통해 서비스 앱과 통신하는 별도의 GUI 클라이언트가 필요할 수 있습니다.

사용자의 POV에서 제어하기 쉬운 것이 무엇인지 궁금합니다. 서비스와 예약 된 작업 모두 기술에 익숙하지 않은 대부분의 사용자에게는 거의 도달 할 수 없습니다. 즉, 이들이 존재한다는 사실을 깨닫지 못하고 구성 / 중지 / 일정 변경 등이 가능합니다.

.NET 개발에서는 일반적으로 콘솔 응용 프로그램을 개발하여 시작합니다. 콘솔 응용 프로그램은 콘솔 창에 모든 로깅 출력을 실행할 것입니다. 그러나 이것은 command 인수로 실행되는 경우 에만 콘솔 응용 프로그램 /console입니다. 이 매개 변수없이 실행하면 Windows 서비스로 작동하여 사용자 지정 코딩 된 예약 타이머에서 계속 실행됩니다.

내 생각에 Windows 서비스는 일반적으로 장기 실행 응용 프로그램이 아니라 다른 응용 프로그램을 관리하는 데 사용됩니다. 또는 .. SQL Server, BizTalk, RPC Connections, IIS (IIS가 기술적으로 다른 프로세스로 작업을 오프로드하더라도)와 같은 무거운 애플리케이션을 지속적으로 실행합니다.

개인적으로 필자는 파일 복사 / 동기화, 대량 이메일 전송, 파일 삭제 또는 보관, 데이터 수정 (다른 해결 방법을 사용할 수없는 경우)과 같은 반복적 인 유지 관리 작업 및 응용 프로그램을 위해 Window Services보다 예약 된 작업을 선호합니다.

한 프로젝트에서 저는 8 개 또는 9 개의 Windows 서비스 개발에 참여했지만 이러한 서비스는 인스턴스 당 20MB 이상의 메모리를 사용하여 메모리에 유휴 상태로 있습니다. 예약 된 작업은 업무를 수행하고 즉시 메모리를 해제합니다.

'serv'ice라는 단어는'serv'er와 공통점이 있습니다. 항상 실행 중이어야하며 'serv'e. 작업은 작업입니다.

역할극. 내가 다른 운영 체제, 응용 프로그램 또는 장치이고 서비스를 호출하는 경우 서비스가 실행될 것으로 예상하고 응답을 기대합니다. 내가 (os, app, dev) 고립 된 작업을 실행해야한다면 작업을 실행할 것입니다.하지만 양방향 통신과 같은 통신을 기대한다면 서비스를 원합니다. 이는 두 가지가 의사 소통하는 가장 효과적인 방법 또는 단일 작업을 실행하려는 단일 사물과 관련이 있습니다.

그런 다음 스케줄링 측면이 있습니다. 특정 시간에 무언가를 실행하려면 일정을 잡으십시오. 언제 필요할지 모르거나 "즉시"필요한 경우 서비스를 제공합니다.

내 반응은 인간이 다른 사람과 상호 작용하고 일하는 방식과 매우 유사하기 때문에 본질적으로 더 철학적입니다. 우리가 의사 소통의 기술을 더 많이 이해하고 "개체"가 그들의 역할을 이해할수록이 결정은 더 쉬워집니다.

모든 철학을 제쳐두고, 제 IT 부서가 종종하는 것처럼 "신속하게 프로토 타이핑"할 때, 당신은 목표를 달성하기 위해 필요한 모든 것을 수행합니다. 일반적으로 초기 계획 및 발견 단계에서 프로토 타이핑 및 개념 증명 작업이 중단되면 장기적인 지속 가능성을 위해 더 신뢰할 수있는 것이 무엇인지 결정해야합니다.

결론적으로 많은 요인에 크게 의존하지만, 이것이 혼란 대신 통찰력을 제공했으면합니다.

Windows 서비스에는 아무도 로그인 할 필요가 없으며 Windows에는 서비스 결과를 중지, 시작 및 기록하는 기능이 있습니다.

예약 된 작업에서는 Windows 서비스 작성 방법을 배울 필요가 없습니다.

1. 올바른 권한으로 Windows 서비스를 설정하고 잠그는 것이 더 쉽습니다.
2. 서비스는 더 "가시적"이라는 의미로 모든 사람 (예 : 기술자)이 어디를 찾아야하는지 알고 있습니다.

둘 다 제공하지 않는 이유는 무엇입니까?

과거에는 라이브러리에 '핵심'비트를 넣고 서비스와 콘솔 앱 모두에서 Whatever.GoGoGo () 호출을 래핑했습니다.

당신이 매 2 분마다 발사하는 어떤 것을 가지고있는 것은 그다지 많은 일을하지 않는 것입니다 (예를 들어, 단지 "ping"타입 함수). 래퍼에는 단일 메서드 호출과 일부 로깅 이상을 포함 할 필요가 없습니다.

이것은 오래된 질문이지만 내가 직면 한 것을 공유하고 싶습니다.

최근에 기상 웹 사이트에서 레이더의 스크린 샷을 캡처하고 10 분마다 서버에 저장하라는 요구 사항이 주어졌습니다.

이를 위해서는 WebBrowser를 사용해야했습니다. 나는 보통 Windows 서비스를 만들기 때문에이 서비스도 만들기로 결정했지만 계속 충돌합니다. 이것은 이벤트 뷰어 오류 모듈 경로 에서 본 것입니다 : C : \ Windows \ system32 \ MSHTML.dll

작업이 시급하고 연구와 실험 시간이 매우 적어 간단한 콘솔 애플리케이션을 사용하기로 결정하고 작업으로 트리거하여 원활하게 실행되었습니다.

Mark Ransom의 답변으로 추천 된 Jon Galloway 의 기사가 정말 마음에 들었습니다 .

최근 서버의 암호가 나를 확인하지 않고 변경되었으며 로그온 할 수 없어 모든 서비스가 실행되지 않았습니다. 따라서 기사에서 주장하는 ppl은 이것이 문제라고 언급합니다. 나는 Windows 서비스가 동일한 문제에 직면 할 수 있다고 생각합니다 (Pls. 내가 틀렸다면 나를 바로 잡으십시오. 나는 초보자입니다)

또한 작업 스케줄러를 사용하는 경우 창이 팝업되거나 콘솔 창이 팝업됩니다. 나는 그것을 직면 한 적이 없다. 튀어 나올 수 있지만 적어도 매우 즉각적입니다.

일반적으로 핵심 메시지는 코드 자체가 모든 "트리거 / 클라이언트"에서 실행 가능해야한다는 것입니다. 따라서 하나에서 다른 접근 방식으로 전환하는 것이 로켓 과학이되어서는 안됩니다.

과거에는 거의 항상 Windows 서비스를 사용했지만 점점 더 많은 고객이 Azure로 단계별로 전환하고 콘솔 앱 (예약 된 작업으로 배포 됨)에서 Azure의 WebJob으로 전환하는 것이 훨씬 쉽습니다. Windows 서비스 인 경우 지금은 예약 된 작업에 중점을 둡니다. 한계에 부딪히면 Windows 서비스 프로젝트를 시작하고 거기에서 동일한 로직을 호출합니다 (고객이 OnPrem .. 작업하는 한). :)

BR, y

Windows 서비스는 완료 될 때까지 더 많은 인내심을 원합니다. 약간 하드 디버그 및 설치가 있습니다. 얼굴이 없습니다. 매초, 분 또는 시간마다 수행해야하는 작업이 필요한 경우 Windows 서비스를 선택해야합니다.

예약 된 작업은 빠르게 개발되고 얼굴이 있습니다. 매일 또는 매주 작업이 필요한 경우 예약 된 작업을 사용할 수 있습니다.