管理員工多個實例的體系結構？

我應該選擇什麼架構？有一個工作進程將消息從隊列中取出並逐個處理。現在我可以有許多windows服務實例完成這項工作，或者我可以將一個WCF服務作爲一個Windows服務託管，以充當某種服務器，我可以在其上爲每個實例啓動一個線程。管理員工多個實例的體系結構？

哪種方法比較好？當我們談論雲計算時，我需要觀點，比如擴展速度非常快的基礎架構，以及非基於雲的基礎架構。

來源

2012-11-06 deostroll

雲中最具擴展性的方法是使用WCF或Web-api來處理服務（如果您正在設計RESTful服務，則最好）。這樣的實例將是可擴展的。在Azure的情況下，將其視爲IIS託管的Web角色。 IIS旨在擴展來自客戶端的傳入請求。另一個好處是你可以獲得IIS和asp.net基礎設施來管理安全和其他東西。但是，如果您不需要使用Windows服務託管的WCF或Web-api服務。然後，Web服務實例將對消息進行排隊或將工作負載稱爲隊列。在Azure的情況下，隊列可以是服務總線隊列。然後，您可以使用Windows服務或Azure輔助角色從隊列中提取工作項。通常，單個工作人員從隊列中提取多個消息並對其進行處理。在這樣做的時候，這些消息不會被其他工作人員使用。工作完成後，從隊列中刪除消息或工作負載。因爲在一段時間之後，其他工作人員可以看到他們有可見性設置，例如在amazon SQS中有可視性超時設置。 *在單個worker中提取5到10條消息，並將它們作爲線程池線程並行地作爲「Task」運行。

請注意，前端具有可伸縮服務實例的體系結構，在後端接收傳入請求和工作人員角色，儘快清除工作項取決於雲提供的分佈式，健壯和可伸縮隊列Azure服務總線和Amazon SQS。否則，您可能會遇到爭用問題。

對於內部（非雲）部署，通常如果沒有分佈式隊列，在這裏您可以讓IIS託管的服務實例執行所有操作，或者windows服務執行所有操作或組合。我建議使用IIS託管的HTTP服務來提供網頁並接收傳入的請求（REST服務）。 IIS在這方面很好。但是，如果沒有很長時間的請求，IIS池可能會被回收並且可能不會運行。因此，如果需要運行計劃任務或作業，後端的Windows服務就擅長此操作。擁有windows服務來完成所有工作肯定是可行的，但根據我的經驗，使用IIS和asp.net接收請求有助於提高工作效率。您可以通過服務和網絡應用共享安全。我更喜歡在前端使用IIS，在後端使用Windows服務。有了這個，我不必使用Windows服務來管理安全。嘗試NServiceBus爲內部隊列https://github.com/NServiceBus/NServiceBus。我沒有評估過它。

來源

2012-11-06 05:36:41

NServiceBus將只運行沒有付費許可證的單線程。 –

就像做某種HTTP服務（託管在iis上）來做實際的「過程」一樣。但是我想象一個工作者在處理一條消息時 - 如果這個工作者是一個多線程應用程序？ – deostroll

是的，工作人員應該是多線程來利用實例上的多個CPU和核心。如果失敗，則需要運行更多的實例來提高系統的響應速度，而每個實例不會更充分地利用CPU和內核。這會增加成本。有很多方法來設計這個。讓單個線程從隊列中獲取許多消息，並以並行方式在線程池中執行消息。或者你可以有多個線程輪詢隊列並執行消息。等等。我喜歡使用線程池線程的第一種方法。 –

難道你不能簡單地將工作人員託管在一個服務中，並使其成爲多線程？因爲你必須創建一個讀取隊列並調用服務的調度器，Wcf只是搞砸了一些東西。讓消費者作爲服務工作，您也可以將其安裝在多臺計算機上，配置爲從同一隊列讀取，以便縱向和橫向都可以縮放。我假設你正在使用MSMQ或其他類似的隊列機制，如果沒有，請考慮使用它。

來源

2012-11-06 05:29:01

我想過一個託管WCF服務的Windows服務......因爲我需要通過某種通信方式在服務上啓動線程。所以我認爲WCF是...！我沒有得到調度員的意思......那是什麼模式？ – deostroll

我會主持每個工作人員在一個單線程的Windows服務。這具有以下好處：

簡單的代碼和測試（沒有多線程）。
輕便
Dispatcher沒有必要 - 工作人員將負載均衡，無需干預。
易於部署/管理。如果工人僅在重新啓動服務時出現問題。

來源

2012-11-06 08:12:04

管理員工多個實例的體系結構？

回答

相關問題