0

我正在嘗試遷移到服務結構現有解決方案。其中一部分是監聽隊列的工作人員數量。例如,我有一些隊列:Azure服務結構中的可伸縮工作人員

Task1_Queue, Task2_Queue ... TaskN_Queue 

對於每個隊列都有一些邏輯處理它們的消息,比方說工作人員。他們做不同的任務,如生成巨大的報告文件,並上傳到Azure Storage或在數據庫中做小更新。

問題是如何設計服務,以便具有良好的可擴展性的工作人員。我的想法是:

選項1 - 每個隊列將具有單獨的無狀態服務。沒有簡單的方法來自動調整單一服務。

選項2 - 將工作人員作爲獨立的參與者實施,並且具有單一的無狀態服務來監聽隊列和呼叫參與者。優點 - 自動縮放,因爲隊列中的每個消息都會創建新的actor。缺點 - 演員將是一次性的。

+0

數據是否需要在任務運行之間持續?如果是這樣,演員變得不太可行。 –

+0

不,基本上工作人員通過某種方式獲取請求消息來處理它並返回執行 –

+1

至於選項1:您可以創建多個服務實例以擴展。因此,您可以讓多個服務實例處理相同的隊列 –

回答

1

考慮創建2種類型的無狀態服務:監視任務隊列深度

  1. 服務。該服務將根據排隊任務的數量創建和移除服務2的實例。
  2. 處理排隊作業的服務。