อะไรคือข้อเสียและข้อดีของบริการ windows เทียบกับงานที่กำหนดไว้สำหรับการรันโปรแกรมซ้ำ ๆ (เช่นทุกๆสองนาที)?
อะไรคือข้อเสียและข้อดีของบริการ windows เทียบกับงานที่กำหนดไว้สำหรับการรันโปรแกรมซ้ำ ๆ (เช่นทุกๆสองนาที)?
คำตอบ:
ปรับปรุง:
เกือบสี่ปีหลังจากคำตอบเดิมของฉันและคำตอบนี้ล้าสมัยมาก ตั้งแต่TopShelfมาพร้อมกับการพัฒนา Windows Services จึงเป็นเรื่องง่าย ตอนนี้คุณต้องหาวิธีรองรับเฟลโอเวอร์ ...
คำตอบเดิม:
ฉันไม่ใช่แฟนตัวยงของ Windows Scheduler ต้องระบุรหัสผ่านของผู้ใช้ตามที่@moodforallชี้ไว้ข้างต้นซึ่งจะสนุกเมื่อมีคนเปลี่ยนรหัสผ่านของผู้ใช้นั้น
ความรำคาญที่สำคัญอื่น ๆ กับ Windows Scheduler คือมันทำงานแบบโต้ตอบไม่ใช่เป็นกระบวนการเบื้องหลัง เมื่อหน้าต่าง MS-DOS 15 หน้าต่างปรากฏขึ้นทุกๆ 20 นาทีระหว่างเซสชัน RDP คุณจะเตะตัวเองที่ไม่ได้ติดตั้งเป็นบริการ Windows แทน
ไม่ว่าคุณจะเลือกอะไรฉันขอแนะนำให้คุณแยกรหัสการประมวลผลของคุณออกเป็นส่วนประกอบอื่นจากแอปคอนโซลหรือบริการ Windows จากนั้นคุณมีทางเลือกที่จะเรียกกระบวนการของผู้ปฏิบัติงานจากแอปพลิเคชันคอนโซลและเชื่อมต่อเข้ากับ Windows Scheduler หรือใช้บริการ 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://tutorials.csharp-online.net/Creating_a_.NET_Windows_Service%E2%80%94Alternative_1%3a_Use_a_Separate_Thread (Dead Link)
ฉันใช้บริการ Windows จำนวนมากเช่นนี้มาหลายปีแล้วและใช้ได้ผลกับฉัน ฉันยังไม่เห็นรูปแบบที่แนะนำที่ผู้คนเห็นด้วย เพียงแค่ทำสิ่งที่เหมาะกับคุณ
NT AUTHORITY\NetworkService
บัญชีนี้มีสิทธิ์ จำกัด
ข้อมูลที่ผิดบางส่วนที่นี่ Windows Scheduler สามารถเรียกใช้งานในพื้นหลังได้อย่างสมบูรณ์แบบโดยไม่มีหน้าต่างโผล่ขึ้นมาและไม่ต้องใช้รหัสผ่าน เรียกใช้ภายใต้บัญชี 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.
Task Scheduler 2.0พร้อมใช้งานจาก Vista และ Server 2008
ใน XP และ Server 2003 system
เป็นตัวเลือกเดียว
Local Service
(aka NT AUTHORITY\LocalService
) แทนที่จะเป็นLocalSystem
(aka .\LocalSystem
) อดีตมีสิทธิ์ จำกัด ในขณะที่คนหลังเป็นผู้ดูแลระบบ
LocalService
และNetworkService
พร้อมใช้งานในschtasks
v2 Vista เป็นต้นไปและควรเลือกใช้หากเป็นไปได้ ในขณะนี้สิ่งนี้อ้างถึงschtasks
ใน XP และ Server 2003 ซึ่งยอมรับเฉพาะSystem
เป็นพารามิเตอร์ตามtechnet.microsoft.com/en-us/library/bb490996.aspx
ค่าใช้จ่ายในการเริ่มและออกจากแอปคืออะไร? ทุกสองนาทีมักจะสวย บริการอาจทำให้ระบบทำงานได้อย่างราบรื่นกว่าการเรียกใช้แอปพลิเคชันของคุณบ่อยๆ
โซลูชันทั้งสองสามารถเรียกใช้โปรแกรมเมื่อผู้ใช้ไม่ได้เข้าสู่ระบบดังนั้นจึงไม่มีความแตกต่างกัน การเขียนบริการค่อนข้างมีส่วนเกี่ยวข้องมากกว่าแอปเดสก์ท็อปทั่วไป - คุณอาจต้องใช้ไคลเอนต์ GUI แยกต่างหากที่จะสื่อสารกับแอปบริการผ่าน TCP / IP ชื่อไปป์เป็นต้น
จาก POV ของผู้ใช้ฉันสงสัยว่าตัวไหนควบคุมได้ง่ายกว่ากัน ทั้งบริการและงานตามกำหนดเวลานั้นค่อนข้างไม่สามารถเข้าถึงได้สำหรับผู้ใช้ที่ไม่ได้ใช้เทคนิคส่วนใหญ่กล่าวคือพวกเขาจะไม่รู้ด้วยซ้ำว่ามีอยู่และสามารถกำหนดค่า / หยุด / กำหนดเวลาใหม่ได้และอื่น ๆ
ในการพัฒนา. NET ปกติแล้วฉันจะเริ่มต้นด้วยการพัฒนาแอปพลิเคชันคอนโซลซึ่งจะทำงานทั้งหมดจะบันทึกเอาต์พุตไปยังหน้าต่างคอนโซล แต่นี้เป็นเพียง/console
โปรแกรมประยุกต์ของคอนโซลเมื่อมีการทำงานกับการโต้แย้งคำสั่ง เมื่อรันโดยไม่มีพารามิเตอร์นี้จะทำหน้าที่เป็นบริการของ Windows ซึ่งจะยังคงทำงานบนตัวจับเวลาตามกำหนดเวลาที่กำหนดรหัสเอง
ฉันคิดว่า Windows Services มักใช้เพื่อจัดการแอปพลิเคชันอื่น ๆ แทนที่จะเป็นแอปพลิเคชันที่ใช้งานได้ยาวนาน หรือ .. พวกเขากำลังเรียกใช้แอปพลิเคชันที่มีน้ำหนักมากอย่างต่อเนื่องเช่น SQL Server, BizTalk, RPC Connections, IIS (แม้ว่า IIS ในทางเทคนิคจะลดภาระไปยังกระบวนการอื่น ๆ )
โดยส่วนตัวแล้วฉันชอบงานที่กำหนดเวลาไว้บน Window Services สำหรับงานบำรุงรักษาและแอปพลิเคชันที่ทำซ้ำเช่นการคัดลอกไฟล์ / การซิงโครไนซ์การส่งอีเมลจำนวนมากการลบหรือการเก็บไฟล์การแก้ไขข้อมูล (เมื่อไม่มีวิธีแก้ปัญหาอื่น ๆ )
สำหรับโครงการหนึ่งฉันมีส่วนร่วมในการพัฒนาบริการ Windows 8 หรือ 9 รายการ แต่สิ่งเหล่านี้อยู่ในหน่วยความจำไม่ได้ใช้งานกินหน่วยความจำ 20MB หรือมากกว่าต่ออินสแตนซ์ งานที่กำหนดเวลาไว้จะทำธุรกิจของพวกเขาและปล่อยหน่วยความจำทันที
คำว่า 'serv'ice มีบางอย่างที่เหมือนกันกับ' serv'er คาดว่าจะทำงานอยู่เสมอและ "serv'e งานคืองาน
สวมบทบาท หากฉันเป็นระบบปฏิบัติการแอปพลิเคชันหรืออุปกรณ์อื่นและฉันเรียกใช้บริการฉันคาดว่าระบบจะทำงานและคาดว่าจะได้รับการตอบกลับ ถ้าฉัน (ระบบปฏิบัติการ, แอป, dev) เพียงแค่ต้องดำเนินการแยกงานฉันก็จะดำเนินงาน แต่ถ้าฉันคาดหวังว่าจะสื่อสารได้อาจเป็นการสื่อสารสองทางฉันต้องการบริการ สิ่งนี้เกี่ยวข้องกับวิธีที่มีประสิทธิภาพสูงสุดสำหรับสองสิ่งในการสื่อสารหรือสิ่งเดียวที่ต้องการดำเนินการงานเดียว
จากนั้นมีลักษณะการตั้งเวลา หากคุณต้องการให้บางสิ่งบางอย่างดำเนินการตามเวลาที่กำหนดให้กำหนดเวลา หากคุณไม่ทราบว่าคุณจะต้องใช้เมื่อใดหรือต้องการบริการแบบ "ทันที"
คำตอบของฉันเป็นไปในเชิงปรัชญามากกว่าเพราะสิ่งนี้คล้ายกับการที่มนุษย์โต้ตอบและทำงานกับคนอื่น ยิ่งเราเข้าใจศิลปะในการสื่อสารและ "เอนทิตี" เข้าใจบทบาทของพวกเขามากเท่าไหร่การตัดสินใจนี้ก็จะง่ายขึ้นเท่านั้น
นอกเหนือจากปรัชญาทั้งหมดเมื่อคุณ "สร้างต้นแบบอย่างรวดเร็ว" อย่างที่ฝ่ายไอทีของฉันมักจะทำคุณจะทำทุกอย่างที่คุณต้องทำเพื่อให้ได้มาซึ่งจุดจบ เมื่อการสร้างต้นแบบและการพิสูจน์แนวคิดต่างๆไม่เป็นไปตามปกติโดยปกติแล้วในการวางแผนและการค้นพบในระยะแรกคุณต้องตัดสินใจว่าอะไรน่าเชื่อถือกว่าสำหรับความยั่งยืนในระยะยาว
ตกลงโดยสรุปแล้วมันขึ้นอยู่กับหลายปัจจัย แต่หวังว่าสิ่งนี้จะให้ข้อมูลเชิงลึกแทนความสับสน
บริการ Windows ไม่จำเป็นต้องมีใครเข้าสู่ระบบและ Windows มีสิ่งอำนวยความสะดวกสำหรับการหยุดเริ่มต้นและบันทึกผลลัพธ์ของบริการ
งานตามกำหนดการไม่ต้องการให้คุณเรียนรู้วิธีการเขียนบริการ Windows
NT AUTHORITY\LocalService
หรือNT AUTHORITY\NetworkService
) รหัสผ่านที่ให้มาจะถูกละเว้นเนื่องจากบัญชีไม่มีรหัสผ่าน
ทำไมไม่ให้ทั้งสองอย่าง?
ในอดีตฉันได้ใส่บิต 'core' ไว้ในไลบรารีและทำการโทรไปที่ Whatever GoGoGo () ทั้งในบริการและแอปคอนโซล
ด้วยบางสิ่งบางอย่างที่คุณกำลังยิงออกไปทุกๆสองนาทีโอกาสที่ดีก็ไม่ได้ทำอะไรมากนัก (เช่นฟังก์ชันประเภท "ping") Wrapper ไม่ควรมีการเรียกใช้เมธอดมากกว่าหนึ่งครั้งและการบันทึกบางอย่าง
นี่เป็นคำถามเก่า แต่ฉันอยากจะแบ่งปันสิ่งที่ฉันเผชิญ
เมื่อเร็ว ๆ นี้ฉันได้รับข้อกำหนดในการจับภาพหน้าจอของเรดาร์ (จากเว็บไซต์อุตุนิยมวิทยา) และบันทึกไว้ในเซิร์ฟเวอร์ทุกๆ 10 นาที
สิ่งนี้ทำให้ฉันต้องใช้เว็บเบราว์เซอร์ ฉันมักจะทำบริการ windows ดังนั้นฉันจึงตัดสินใจที่จะให้บริการนี้ด้วย แต่มันจะหยุดทำงาน นี่คือสิ่งที่ฉันเห็นในเส้นทางโมดูลที่ผิดพลาดของ Event Viewer : C: \ Windows \ system32 \ MSHTML.dll
เนื่องจากงานเป็นเรื่องเร่งด่วนและฉันมีเวลาค้นคว้าและทดลองน้อยมากฉันจึงตัดสินใจใช้แอปพลิเคชันคอนโซลแบบธรรมดาและเรียกใช้งานเป็นงานและดำเนินการได้อย่างราบรื่น
ฉันชอบบทความของ Jon Galloway มากแนะนำในคำตอบที่ยอมรับโดย Mark Ransom
เมื่อเร็ว ๆ นี้รหัสผ่านบนเซิร์ฟเวอร์มีการเปลี่ยนแปลงโดยไม่ยอมรับฉันและบริการทั้งหมดล้มเหลวในการดำเนินการเนื่องจากไม่สามารถเข้าสู่ระบบได้ ดังนั้น ppl ที่อ้างสิทธิ์ในบทความแสดงความคิดเห็นว่านี่เป็นปัญหา ฉันคิดว่าบริการ windows สามารถประสบปัญหาเดียวกันได้ (กรุณาแก้ไขฉันถ้าฉันผิดฉันเป็นมือใหม่)
นอกจากนี้สิ่งที่กล่าวถึงหากใช้หน้าต่างตัวกำหนดตารางเวลางานป๊อปอัปหรือหน้าต่างคอนโซลปรากฏขึ้น ฉันไม่เคยเผชิญกับสิ่งนั้น มันอาจจะโผล่ขึ้นมา แต่อย่างน้อยก็เป็นไปในทันที
โดยทั่วไปข้อความหลักคือและควรเป็นไปได้ว่าโค้ดจะต้องสามารถเรียกใช้งานได้จาก "ทริกเกอร์ / ไคลเอนต์" แต่ละรายการ ดังนั้นจึงไม่ควรเป็นวิทยาศาสตร์จรวดที่จะเปลี่ยนจากแนวทางหนึ่งไปสู่อีกแนวทางหนึ่ง
ในอดีตเราใช้บริการ Windows มากขึ้นหรือน้อยลงเสมอ แต่เนื่องจากลูกค้าของเราจำนวนมากขึ้นเรื่อย ๆ เปลี่ยนไปใช้ Azure ทีละขั้นตอนและการเปลี่ยนจากแอปคอนโซล (ปรับใช้เป็นงานตามกำหนดการ) ไปยัง WebJob ใน Azure นั้นง่ายกว่าจาก บริการ Windows เรามุ่งเน้นไปที่งานตามกำหนดการในตอนนี้ หากเราพบข้อ จำกัด เราก็เพิ่มโปรเจ็กต์บริการ Windows และเรียกใช้ตรรกะเดียวกันจากที่นั่น (ตราบใดที่ลูกค้าทำงาน OnPrem .. ) :)
BR, y
บริการ Windows ต้องการความอดทนมากขึ้นจนกว่าจะเสร็จสิ้น มีการดีบักและติดตั้งค่อนข้างยาก มันไร้ใบหน้า หากคุณต้องการงานที่ต้องทำในทุก ๆ วินาทีนาทีหรือชั่วโมงคุณควรเลือก Windows Service
งานตามกำหนดการได้รับการพัฒนาอย่างรวดเร็วและมีหน้าตา หากคุณต้องการงานรายวันหรือรายสัปดาห์คุณสามารถใช้งานตามกำหนดการ