在沒有涉及到這個問題的時候我也不太明白他裡面的深刻奧義。後來知道了這是一個能夠長時間運行的應用程序，這個服務只要配置自動啟動那麼在windows開機啟動的時候自動運行起，他沒有界面。在Windows機器上能夠通過管理工具/服務進行系統運行的所有服務的查看和管理。系統的大部分軟件和硬件的運行狀態監控都是通過Windows服務進行監控的，通過服務不斷輪訓去請求BIOS提供的端口收集BIOS收集的硬件的運行狀態。可能他們又通過不同的媒介進行展示如windows計數器進行性能指標的展示，windows計數器暴露一些可供外部調用的接口（win32函數），其他的第三方軟件做的更好的用戶體驗的展示該機器的性能了如魯大師進行的電腦監控。說道這裡我不禁想到了電腦的組成，電腦的每一個硬件只需要向外部提供統一格式的接口，底層的BIOS系統輪訓查詢調用每一個硬件提供的接口，收集每一個硬件運行狀態。因為Intel和AMD處理器所公布出來的是兩套接口方案，才導致市面上存在AMD平台的主板和Intel平台的主板不能互用。
我們自己所要建立的Windows服務沒有那麼的復雜，可能就是一個定時任務，到達時間點就開始執行。如果我們要讓程序在每天晚上12點自動運行抓取數據進行數據匯聚操作，不可能派一個人坐在哪裡等吧，這是就是我們的windows服務程序發揮功能的地方了，我們在程序中設定每天12:00自動運行這個函數執行相應的數據抓取和匯聚的功能了。再有一個在一個系統中進行了一個操作，這個系統需要把數據同步到B系統去，如果把這個事情完全在用戶操作的時候處理，難免會導致速度變慢，換一種思考我們可以使用自動程序以很快的定時頻率去檢測是否有數據的變化，如果檢測到數據的變化自動啟用一個線程去同步（失敗了可以嘗試多次），反正就是不要影響或降低用戶的易用性。windows服務程序就像一個哨兵一樣他隨時都在監控周圍的異常，一旦發現達到預定的條件就會啟動該有的程序執行。
自動任務是沒有界面的，無法進行人機交互的。那麼如果沒有一個良好的日志記錄，自動任務失敗或出現異常要定位異常就不是意見容易的事情了。所以在自動任務編寫中我們應該加入良好的日志記錄方式，記錄日志的方式任意，可以記錄數據庫日志、文本文件日志和系統日志，只要做到這些日志能夠方便的管理並且用於查詢自動程序的問題就達到了記錄日志的目的了。
很多人認為自動程序很好，因為不用人為的參與很多事情就會自動的處理比如數據抓取分析這些事情。但是在一個公司裡面的自動程序應該有一個嚴格的控制和部署的監管，會開發很多的自動任務處理那些時間長的運算這些事情且不需要人為參與的事情。這時在我們的架構設計的時候必須要明確記錄哪一個自動任務部署在那些服務器上面，如果記錄不詳細在系統後期的維護或遷移上面可能會忘記卸載或忘記裝載某一些自動任務，而這些自動任務直接影響了我們整個系統的正常運行。所以要做到安裝部署准確並保證實時更新這些部署的記錄。
