layanan windows vs tugas terjadwal

Apa kekurangan dan kelebihan windows services vs tugas terjadwal untuk menjalankan program berulang kali (misalnya setiap dua menit)?

Memperbarui:

Hampir empat tahun setelah jawaban awal saya dan jawaban ini sudah sangat kuno. Sejak TopShelf datang, pengembangan Layanan Windows menjadi mudah. Sekarang Anda hanya perlu mencari cara untuk mendukung failover ...

Jawaban Asli:

Saya benar-benar bukan penggemar Windows Scheduler. Kata sandi pengguna harus diberikan seperti yang ditunjukkan @moodforall di atas, yang menyenangkan jika seseorang mengubah kata sandi pengguna tersebut.

Gangguan utama lainnya dengan Windows Scheduler adalah ia berjalan secara interaktif dan bukan sebagai proses latar belakang. Ketika 15 MS-DOS windows muncul setiap 20 menit selama sesi RDP, Anda akan menendang diri sendiri yang tidak menginstalnya sebagai Layanan Windows.

Apa pun yang Anda pilih, saya pasti menyarankan Anda memisahkan kode pemrosesan Anda menjadi komponen yang berbeda dari aplikasi konsol atau Layanan Windows. Kemudian Anda memiliki pilihan, untuk memanggil proses pengerjaan dari aplikasi konsol dan menghubungkannya ke Penjadwal Windows, atau menggunakan Layanan Windows.

Anda akan menemukan bahwa menjadwalkan Layanan Windows tidak menyenangkan. Skenario yang cukup umum adalah Anda memiliki proses yang berjalan lama yang ingin Anda jalankan secara berkala. Namun, jika Anda memproses antrian, Anda benar-benar tidak ingin dua instance pekerja yang sama memproses antrian yang sama. Jadi, Anda perlu mengelola pengatur waktu, untuk memastikan jika proses yang berjalan lama Anda telah berjalan lebih lama dari interval pengatur waktu yang ditetapkan, proses tersebut tidak dimulai lagi hingga proses yang ada selesai.

Setelah Anda menulis semua itu, Anda berpikir, mengapa saya tidak menggunakan Thread.Sleep saja? Itu memungkinkan saya untuk membiarkan utas saat ini terus berjalan hingga selesai dan kemudian interval jeda dimulai, utas pergi tidur dan memulai lagi setelah waktu yang diperlukan. Rapi!

Kemudian Anda kemudian membaca semua saran di internet dengan banyak ahli yang memberi tahu Anda bagaimana itu benar-benar praktik pemrograman yang buruk:

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

Jadi Anda akan menggaruk kepala dan berpikir sendiri, WTF, Urungkan Pembayaran yang Tertunda -> Ya, saya yakin -> Batalkan semua pekerjaan hari ini ..... sial, sial, sial ....

Namun, saya menyukai pola ini, bahkan jika semua orang mengira itu omong kosong:

Metode OnStart untuk pendekatan single-thread.

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();
}

Kode memberi contoh utas terpisah dan melampirkan fungsi pekerja kita padanya. Kemudian itu memulai utas dan membiarkan acara OnStart selesai, sehingga Windows tidak berpikir layanan itu macet.

Metode pekerja untuk pendekatan utas tunggal.

/// <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();
}

Metode OnStop untuk pendekatan single-thread.

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));
}

Sumber: http://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (Tautan Mati)

Saya telah menjalankan banyak Layanan Windows seperti ini selama bertahun-tahun dan berhasil untuk saya. Saya masih belum melihat pola yang direkomendasikan yang disetujui orang. Lakukan saja apa yang berhasil untuk Anda.

Beberapa informasi yang salah di sini. Penjadwal Windows sangat mampu menjalankan tugas di latar belakang tanpa jendela muncul dan tanpa kata sandi yang diperlukan. Jalankan di bawah akun NT AUTHORITY \ SYSTEM. Gunakan sakelar schtasks ini:

/ ru SISTEM

Tapi ya, untuk mengakses sumber daya jaringan, praktik terbaiknya adalah akun layanan dengan kebijakan sandi terpisah yang tidak kedaluwarsa.

EDIT

Bergantung pada OS Anda dan persyaratan tugas itu sendiri, Anda mungkin dapat menggunakan akun yang kurang diistimewakan daripada Sistem Lokal dengan /ruopsi.

Dari manual yang bagus ,

/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 tersedia dari Vista dan Server 2008.

Di XP dan Server 2003, systemadalah satu-satunya pilihan.

Berapa biaya tambahan untuk memulai dan keluar dari aplikasi? Setiap dua menit cukup sering. Sebuah layanan mungkin akan membiarkan sistem berjalan lebih lancar daripada menjalankan aplikasi Anda terlalu sering.

Kedua solusi tersebut dapat menjalankan program saat pengguna tidak masuk, jadi tidak ada perbedaan di sana. Menulis layanan agak lebih terlibat daripada aplikasi desktop biasa, meskipun - Anda mungkin memerlukan klien GUI terpisah yang akan berkomunikasi dengan aplikasi layanan melalui TCP / IP, pipa bernama, dll.

Dari sudut pandang pengguna, saya ingin tahu mana yang lebih mudah dikendalikan. Baik layanan maupun tugas terjadwal cukup sulit dijangkau oleh sebagian besar pengguna non-teknis, yaitu mereka bahkan tidak menyadari keberadaannya dan dapat dikonfigurasi / dihentikan / dijadwalkan ulang, dan seterusnya.

Dalam pengembangan NET, saya biasanya memulai dengan mengembangkan Aplikasi Konsol, yang akan menjalankan semua keluaran logging ke jendela konsol. Namun, ini hanya Aplikasi Konsol saat dijalankan dengan argumen perintah /console. Ketika dijalankan tanpa parameter ini, itu bertindak sebagai Layanan Windows, yang akan tetap berjalan pada pengatur waktu terjadwal berkode khusus saya sendiri.

Layanan Windows, menurut pendapat saya, biasanya digunakan untuk mengelola aplikasi lain, daripada menjadi aplikasi yang berjalan lama. ATAU .. mereka terus menjalankan aplikasi kelas berat seperti SQL Server, BizTalk, RPC Connections, IIS (meskipun secara teknis IIS memindahkan pekerjaan ke proses lain).

Secara pribadi, saya lebih menyukai tugas terjadwal daripada Window Services untuk tugas dan aplikasi pemeliharaan berulang seperti penyalinan / sinkronisasi file, pengiriman email massal, penghapusan atau pengarsipan file, koreksi data (ketika solusi lain tidak tersedia).

Untuk satu proyek saya telah terlibat dalam pengembangan 8 atau 9 Layanan Windows, tetapi ini hanya duduk-duduk di memori, menganggur, memakan memori 20MB atau lebih per contoh. Tugas terjadwal akan menjalankan bisnis mereka, dan segera melepaskan memori.

Kata 'serv'ice memiliki kesamaan dengan' serv'er. Diharapkan untuk selalu berjalan, dan 'serv'e. Tugas adalah tugas.

Bermain peran. Jika saya adalah sistem operasi, aplikasi, atau perangkat lain dan saya memanggil layanan, saya mengharapkannya berjalan dan saya mengharapkan tanggapan. Jika saya (os, app, dev) hanya perlu menjalankan tugas yang terisolasi, maka saya akan menjalankan tugas, tetapi jika saya ingin berkomunikasi, mungkin komunikasi dua arah, saya menginginkan layanan. Ini berkaitan dengan cara paling efektif untuk dua hal untuk berkomunikasi, atau satu hal yang ingin menjalankan satu tugas.

Lalu ada aspek penjadwalan. Jika Anda ingin sesuatu berjalan pada waktu tertentu, jadwalkan. Jika Anda tidak tahu kapan Anda akan membutuhkannya, atau membutuhkannya "dengan cepat", servis.

Tanggapan saya lebih bersifat filosofis karena ini sangat mirip dengan cara manusia berinteraksi dan bekerja dengan orang lain. Semakin kita memahami seni komunikasi, dan "entitas" memahami peran mereka, semakin mudah keputusan ini jadinya.

Terlepas dari semua filosofi, ketika Anda "membuat prototipe dengan cepat", seperti yang sering dilakukan oleh Departemen TI saya, Anda melakukan apa pun yang harus Anda lakukan untuk memenuhi kebutuhan. Setelah pembuatan prototipe dan bukti konsep selesai, biasanya di awal perencanaan dan penemuan, Anda harus memutuskan mana yang lebih dapat diandalkan untuk keberlanjutan jangka panjang.

Oke jadi kesimpulannya sangat bergantung pada banyak faktor, tapi semoga saja ini memberikan wawasan dan bukan kebingungan.

Layanan Windows tidak memerlukan siapa pun untuk masuk, dan Windows memiliki fasilitas untuk menghentikan, memulai, dan mencatat hasil layanan.

Tugas terjadwal tidak mengharuskan Anda mempelajari cara menulis layanan Windows.

1. Lebih mudah untuk mengatur dan mengunci layanan windows dengan izin yang benar.
2. Layanan lebih "terlihat" artinya setiap orang (yaitu: teknisi) tahu ke mana harus mencari.

Mengapa tidak menyediakan keduanya?

Di masa lalu saya telah menempatkan bit 'inti' di perpustakaan dan membungkus panggilan ke Apapun.GoGoGo () di kedua layanan serta aplikasi konsol.

Dengan sesuatu yang Anda lakukan setiap dua menit, kemungkinan besar itu tidak banyak berguna (misalnya hanya fungsi jenis "ping"). Wrappers tidak harus berisi lebih dari satu panggilan metode dan beberapa logging.

Ini adalah pertanyaan lama tetapi saya ingin berbagi tentang apa yang saya hadapi.

Baru-baru ini saya diberi persyaratan untuk menangkap tangkapan layar radar (dari situs web Meteorologi) dan menyimpannya di server setiap 10 menit.

Ini mengharuskan saya menggunakan WebBrowser. Saya biasanya membuat layanan windows jadi saya memutuskan untuk membuat layanan yang satu ini juga tetapi akan terus macet. Inilah yang saya lihat di jalur modul Sesar Peraga Peristiwa : C: \ Windows \ system32 \ MSHTML.dll

Karena tugas itu mendesak dan saya memiliki sedikit waktu untuk meneliti dan bereksperimen, saya memutuskan untuk menggunakan aplikasi konsol sederhana dan memicunya sebagai tugas dan itu dijalankan dengan lancar.

Saya sangat menyukai artikel oleh Jon Galloway yang direkomendasikan dalam jawaban yang diterima oleh Mark Ransom.

Baru-baru ini kata sandi di server diubah tanpa mengakui saya dan semua layanan gagal dijalankan karena mereka tidak dapat masuk. Jadi ppl mengklaim di artikel komentar bahwa ini adalah masalah. Saya pikir layanan windows dapat menghadapi masalah yang sama (Tolong perbaiki saya jika saya salah, saya hanya seorang pemula)

Juga hal yang disebutkan, jika menggunakan jendela penjadwal tugas muncul atau jendela konsol muncul. Saya tidak pernah menghadapi itu. Ini mungkin muncul tetapi setidaknya sangat instan.

Umumnya, pesan inti adalah dan seharusnya bahwa kode itu sendiri harus dapat dieksekusi dari setiap "pemicu / klien". Jadi seharusnya tidak menjadi ilmu roket untuk beralih dari satu pendekatan ke pendekatan lainnya.

Di masa lalu kami menggunakan lebih atau kurang selalu Layanan Windows tetapi karena semakin banyak pelanggan kami beralih ke Azure selangkah demi selangkah dan pertukaran dari Aplikasi Konsol (digunakan sebagai Tugas Terjadwal) ke WebJob di Azure jauh lebih mudah daripada dari Layanan Windows, kami fokus pada Tugas Terjadwal untuk saat ini. Jika kami mengalami keterbatasan, kami hanya meningkatkan proyek Windows Service dan memanggil logika yang sama dari sana (selama pelanggan menggunakan OnPrem ..) :)

BR, y

Layanan Windows menginginkan lebih banyak kesabaran sampai selesai. Ini memiliki sedikit debug dan pemasangan yang sulit. Itu tidak berwajah. Jika Anda membutuhkan tugas yang harus diselesaikan setiap detik, menit atau jam, Anda harus memilih Layanan Windows.

Tugas Terjadwal dengan cepat dikembangkan dan memiliki wajah. Jika Anda membutuhkan tugas harian atau mingguan, Anda dapat menggunakan Tugas Terjadwal.