2011-06-07 59 views
6

我將一個巨大的應用程序移植到Windows Azure。它將有一個Web服務前端和一個處理後端。到目前爲止,我認爲我會使用Web角色來爲後端處理服務客戶端請求和輔助角色。爲後端處理重用Azure Web角色是一個好主意嗎?

管理兩種角色似乎有問題 - 我需要決定如何縮放兩種角色,還需要每個角色的幾個(至少兩個)實例來確保合理的容錯能力,這會稍微增加運營成本。同樣在我的應用程序中,客戶端請求相當輕量級,後端處理也很重要,所以我認爲後端處理會比處理客戶端請求消耗更多的處理能力。

這就是爲什麼我想爲所有事情使用Web角色 - 只是產生線程,並在每個實例中同時處理請求和後端處理。這將使角色更加複雜,但我猜想可以簡化管理。我將擁有更多具有統一角色和更好容錯能力的實例。

是否將Web角色重新用於後端處理是一個好主意?我應該期待什麼缺點?

回答

4

聽起來像是你已經有什麼想使用多個角色時,約一個不錯的主意:

  • 成本爲2個實例,以滿足SLA(雖然有些後臺任務真的不,如果最終需要SLA用戶不會看到影響)
  • 單獨的刻度單位

不過:如果你在一個角色上運行的一切,那麼一切秤在一起。例如,如果您有一個8000端口的管理網站,如果您的用戶羣正在使用流量在端口80上關閉主站點,則您可能無法訪問它。

我寫了一篇關於結合網絡和工作者角色的文章,here,這篇文章詳細介紹了我們在這裏討論的內容。此外,截至3月的某個時候,每個角色的5個端點限制被解除 - 請參閱我的博客文章here,以瞭解您現在可以推送多少端點。具有這種限制性較小的端點模型確實爲單角色部署開闢了新的可能性。

2

從我的理解你的問是否有意義鞏固服務層,以便你只需要處理單一層。高層次,我認爲這是有道理的。越簡單越好,只要它不那麼簡單就不能達到你的主要目標。

如果您的主要目標是性能,並且您的服務調用是內聯的(意思是調用者正在等待答案),那麼整合這些層可以幫助您實現更高的性能,因爲您不必處理額外的物理層的額外網絡延遲開銷。您可以使用任務並行庫(TPL)來實現您的線程邏輯。

如果您的主要目標是可擴展性,並且對您的服務的調用是帶外的(意思是調用者實現了即發即棄模式),那麼使用處理隊列和輔助角色可能更有意義。雲計算的一個原則是鬆耦合服務。雖然您有更多的維護工作,但您也可以更靈活地獨立增長您的圖層。你的工作者角色也可以使用上面提到的TPL,這樣你就可以在更大的虛擬機上部署你的角色(比如4CPU,或8),這樣可以將部署的實例數量降到最低。

我的2美分。:)

相關問題