我們系統的幾個組件具有「長時間運行」操作。它們可以從幾秒到幾分鐘，並且在CPU使用率上有所不同。例如，報告生成會將CPU掛起幾秒鐘，但數據收集主要用於等待數據庫查詢。工作者角色與異步控制器的Web角色
我面臨兩個選擇：
（1）Web角色+工作者的角色+隊列+表。工作人員角色在隊列上旋轉，獲取帶有參數的消息，確實有效，並使用進度和完成標誌更新表。客戶端旋轉，顯示進度直到標記完成。一個Web角色，根據需要放大工作者角色的數量。
（2）Web角色+異步方法。讓我長時間運行的操作使用.NET 4.5的異步/等待東西，並讓控制器動作標記爲異步。根據需要放大Web角色的數量。
選擇1顯然要複雜得多，但保持Web角色免費做網頁內容，並允許適當的排隊，如果事情開始變得非常繁忙的優勢。選項2更簡單，需要的角色和存儲資源更少，但是如果事情開始變得忙碌，它有沒有可能窒息整個網站？爲了簡單起見，我強烈傾向於選項2。有沒有特別的理由不這樣做？如果網站開始放緩，只需增加網絡角色實例的數量就可以解決性能問題了嗎？
與大多數架構決策一樣，答案只是「取決於」。
在這種情況下，選項（2）更易於編碼。如果你不希望大規模擴張，那麼我會說這很好。
的主要優勢的選項（1）是，你有兩個旋鈕縮放：您的Web角色處理web請求和您的輔助角色處理工作，並且可以獨立地擴展你的腹板你的工人。
但是除非你要大規模擴展，否則我不會擔心。選項（2）可以很好地擴展，而不是完美的效率。如果你開始大規模擴大規模，你可以（低效地）用選項（2）和（可能）使用你的大規模收入來開發選項（1）。
P.S.這兩個選項都應該使用async。
正如Stephen發佈的，這將是一個「It Depends」類型的答案。
在這種情況下，我可能會選擇第一個選項，或者在yuo擁有web角色，隊列和表之間的選項，但創建一個也作爲啓動可執行文件在您的web角色上運行的可執行文件。
使用選項2，您將打開連接超時，實例重新啓動等，並且必須通過擴展您的Web角色或重寫代碼來滿足額外的資源需求。
對於選項1（斯蒂芬指出的），你的工作量分離，並可以獨立地擴展的角色。另外，讓隊列和工人處理工作可以讓工作人員管理自己的生命週期，並且通過在完成工作之前不刪除隊列項目，您可以爲計劃內或計劃外重新啓動建立一定的恢復能力（這樣他們將會重新表面化你在中間崩潰）。您還可以充分利用角色資源（首先在線程上進行擴展，然後再添加其他實例），因爲您的輪詢機制將控制工作負載，而不是隨機訪問網站。在網絡方面，您可以選擇使用等待完成並返回的異步方法，或者您可以返回令牌並讓客戶輪詢完成工作，兩種情況應該都是相對簡單的代碼。
儘管選項1.5可能是最好的起點。如果你試圖從小處着手，那麼在你的web角色上使用後臺可執行文件將是最便宜的解決方案。您將希望至少有兩個Web角色來確保SLA的覆蓋範圍，因此，此解決方案可讓您從這兩個實例開始，不再需要更多。構建執行隊列輪詢和單獨報告（或其他）執行的可執行文件，然後將其配置爲Web角色的啓動任務。這可以讓你在開始的時候保持低成本，並且這些exe的代碼是獨立的，如果你需要擴展的話，以後可以成爲你的輔助角色的代碼。在這種情況下要注意的最大問題是您的可執行文件處理所有異常，因爲如果此進程由於未處理的異常而退出，它將不會重新啓動（與工作人員角色不同，Azure每次都會繼續啓動死）。