c# 編寫Windows服務程式

標籤：windows

1.Windows服務程式

在沒有涉及到這個問題的時候我也不太明白他裡面的深刻奧義。後來知道了這是一個能夠長時間啟動並執行應用程式，這個服務只要配置自動啟動那麼在windows開機啟動的時候自動運行起，他沒有介面。在Windows機器上能夠通過管理工具/服務進行系統啟動並執行所有服務的查看和管理。系統的大部分軟體和硬體的運行狀態監控都是通過Windows服務進行監控的，通過服務不斷輪訓去請求BIOS提供的連接埠收集BIOS收集的硬體的運行狀態。可能他們又通過不同的媒介進行展示如windows計數器進行效能指標的展示，windows計數器暴露一些可供外部調用的介面（win32函數），其他的第三方軟體做的更好的使用者體驗的展示該機器的效能了如魯大師進行的電腦監控。說道這裡我不禁想到了電腦的組成，電腦的每一個硬體只需要向外部提供統一格式的介面，底層的BIOS系統輪訓查詢調用每一個硬體提供的介面，收集每一個硬體運行狀態。因為Intel和AMD處理器所公布出來的是兩套介面方案，才導致市面上存在AMD平台的主板和Intel平台的主板不能互用。

2.什麼情況下建立Windows服務程式

我們自己所要建立的Windows服務沒有那麼的複雜，可能就是一個定時任務，到達時間點就開始執行。如果我們要讓程式在每天晚上12點自動運行抓取資料進行資料匯聚操作，不可能派一個人坐在哪裡等吧，這是就是我們的windows服務程式發揮功能的地方了，我們在程式中設定每天12:00自動運行這個函數執行相應的資料抓取和匯聚的功能了。再有一個在一個系統中進行了一個操作，這個系統需要把資料同步到B系統去，如果把這個事情完全在使用者操作的時候處理，難免會導致速度變慢，換一種思考我們可以使用Bot以很快的定時頻率去檢測是否有資料的變化，如果檢測到資料的變化自動啟用一個線程去同步（失敗了可以嘗試多次），反正就是不要影響或降低使用者的易用性。windows服務程式就像一個哨兵一樣他隨時都在監控周圍的異常，一旦發現達到預定的條件就會啟動該有的程式執行。

3.記錄日誌，查詢自動任務執行情況

自動任務是沒有介面的，無法進行人機互動的。那麼如果沒有一個良好的日誌記錄，自動任務失敗或出現異常要定位異常就不是意見容易的事情了。所以在自動任務編寫中我們應該加入良好的日誌記錄方式，記錄日誌的方式任意，可以記錄資料庫日誌、文字檔日誌和系統日誌，只要做到這些日誌能夠方便的管理並且用於查詢Bot的問題就達到了記錄日誌的目的了。

4.怎樣建立起良好的自動任務用於服務整個系統運行

很多人認為Bot很好，因為不用人為的參與很多事情就會自動的處理比如資料抓取分析這些事情。但是在一個公司裡面的Bot應該有一個嚴格的控制和部署的監管，會開發很多的自動任務處理那些時間長的運算這些事情且不需要人為參與的事情。這時在我們的架構設計的時候必須要明確記錄哪一個自動任務部署在那些伺服器上面，如果記錄不詳細在系統後期的維護或遷移上面可能會忘記卸載或忘記裝載某一些自動任務，而這些自動任務直接影響了我們整個系統的正常運行。所以要做到安裝部署準確並保證即時更新這些部署的記錄。