ASP.NET背景主題

Question

我正在研究一個包含WCF服務的ASP.NET應用程序，該應用程序的目的是充當模擬生產環境的測試用例。這是一個複雜的後端，它可以通過它的Web服務接收訂單，然後幾小時，或幾天後發送通知（通過調用其他系統上的Web服務）。

該測試雙應用程序首次發佈的要求之一是它是無狀態的，即沒有數據庫。

由原始開發商誰是不再對項目到位的設計是：

1. 通過Web服務，接收訂單。
2. 菌種後臺線程
3. 返回到客戶端
4. 然後後臺線程休眠5一個罐頭響應 - 30秒發送一個通知，再次睡覺時，發送一個通知，重複也許三至四次，然後終於在沒有任何事情要做時終止

5到30秒的睡眠時間是爲了模擬生產系統的小時和長日延遲。每個後臺線程的活動時間不會超過三分鐘。

目前，該設計似乎很適合其目的。到目前爲止，這種方法遇到的唯一問題是，如果發生導致應用程序重新啓動的事情（web.config更改，部署新的DLL，重新啓動IIS等），後臺線程似乎被終止並且任何等待的後臺線程從未發生。

客戶現在已經決定5 - 30秒的延遲太短，通知之間延遲5分鐘更合適。這意味着後臺線程的生命週期可能超過20分鐘。

我的直覺是，讓延遲五分鐘可能不是這個設計的好主意。我很想看看人們的想法是什麼。

這種設計對於延遲時間的增加有多可靠？有沒有人有任何經驗，在ASP.NET中的長時間運行的後臺線程可以評論這個？

Answer 1

這樣睡覺不應該像在這個應用程序中那樣完成;你已經看到了這是爲什麼。如果延遲時間增加，則任務未完成的時間將成倍增加，因爲時間越長，應用程序池回收的機會就越大。

創建單獨的Windows服務可能是值得的，該服務可以連接到網站/服務並啓動這些長時間運行的任務。 Windows服務不會像ASP.NET服務那樣自動回收自己。您可以使用WCF來促進ASP.NET和Win服務之間的通信。

Answer 2

無論如何，您都需要某種服務來處理此問題。網站不應該做後臺處理，尤其是IIS，因爲它對應用程序池回收非常積極。

基本上你需要的是一個後臺處理程序或一個隊列。這通常以單獨的服務或運行的計劃任務的形式出現。在Linux世界中，你可以調用這些守護進程或cron作業。

如果您使用服務，您需要通過傳遞工單或隊列項目（無論您稱之爲什麼）來與該服務交互，並且會使用某種通知延遲規則處理它們內置。不需要數據庫存儲，儘管您可能會發現將文件轉儲到偶爾會收到的文件夾中很容易。

如果您使用計劃任務（可能每分鐘運行一次），那麼將其存儲在sqlite數據庫中或再次存儲在文件系統上，並讓任務選取它會很容易。您可以編寫一個簡單的命令行應用程序來獲取文件並執行其操作。

Answer 3

如果您可以使用MSMQ來存儲訂單，然後運行一個線程來處理隊列將是一個不錯的主意。這將確保在IIS服務器升級/重新啓動的情況下具有更高的可靠性。