雲端運算設計模式（十七）——基於隊列的負載平衡模式

標籤：blog   http   ar   os   使用   sp   strong   資料   on   

雲端運算設計模式（十七）——基於隊列的負載平衡模式

使用隊列，作為一項任務，它調用才能順利間歇重物，可能會以其他方式導致失敗的服務或任務逾時服務之間的緩衝區。這個模式可以協助最小化峰中的可用性和響應需求為任務和服務的影響。

背景和問題

許多解決方案在雲中涉及運行調用服務的任務。在這種環境下，如果一個服務進行間歇重物，它可能會導致效能或可靠性問題

一個服務可以是一個組件，它是相同的溶液作為利用它的任務的一部分，或者它可以是第三方服務提供訪問經常使用的資源，如快取或儲存服務。如果相同的服務是由多個同時啟動並執行任務的使用，它可以是難以預料到的服務可能在任何給定時間點來進行請求的數量。

它可能是一個服務可能會遇到在需求高峰，導致它變得過載和不能對及時響應請求。有大量的並發請求驅服務也可能會導致服務失敗，如果它不能處理的論點，即這些請求可能導致。

解決方案

重構的解決方案和介紹的任務和服務之間的隊列。任務和服務非同步運行。任務帖含有由服務於一個隊列所需要的資料的訊息。隊列作為緩衝，儲存該訊息，直到它被檢索到的服務。該服務從隊列中檢索訊息並進行處理。從多個任務，它可以在一個高度可變的速率產生的請求，可以通過同一個訊息佇列被傳遞給服務。圖1示出了這種結構。

圖1 - 使用隊列水平上的服務的負載


隊列有效地從服務解耦的任務，並且該服務可以按自己的速度處理從並行任務的請求量的資訊無關。此外，不存在延遲到一個任務，如果該服務是停用時候它投遞一個訊息到隊列中。

這種模式提供了以下好處：
?它可以協助最大限度地提高可用性，因為服務而產生的延遲將不會對應用程式，它可以繼續發布訊息佇列，即使該服務不可用或不正在處理訊息的即時和直接的影響。
?它可以有助於最大化可擴充性，因為隊列的數目和服務的數量可以變化，以滿足需求。
?它可以有助於控製成本，因為服務執行個體的數量部署僅需要足以滿足平均負荷，而不是峰值負荷。

注意：

有些服務可以實現節流，如果需求達到閾值，超過該系統可能會失敗。節流可能會降低功能可用。你也許可以實現與這些服務負載平衡，以確保這一閾值沒有達到。

問題和注意事項

在決定如何?這個模式時，請考慮以下幾點：
?來實現控制的速率服務處理訊息，以避免急劇的目標資源的應用程式邏輯是必要的。避免將尖峰需求到該系統的下一個階段。測試系統在負載下，以確保它提供所需的流平，並調整隊列的數目和處理訊息來實現該服務執行個體的數量。
?訊息佇列是一個單向的溝通機制。如果一個任務期望的服務的回覆，可能有必要執行該服務可用於發送的響應的機制。欲瞭解更多資訊，請參閱非同步訊息底漆。
?您一定要小心，如果你申請自動縮放到被監聽的隊列中的請求服務，因為這可能會導致更多的爭奪任何資源，這些服務的份額，並減少使用隊列級負載的有效性。

何時使用這個模式

此圖案是非常適合於使用可能會受到重載服務的任何類型的應用程式。

這種模式可能不是合適的，如果該應用程式期望以最小延遲的服務的響應。

例子

微軟的Azure Web角色儲存資料使用單獨的儲存服務。如果大量的Web角色執行個體同時運行，則可能是儲存服務可以是不堪重負，無法向請求的速度不夠快，以防止逾時或沒有響應這些請求。圖2列出了這個問題。

圖2 - 服務從一個Web角色執行個體大量並發請求正在被壓垮


要解決此問題，可以使用一個隊列地級Web角色執行個體和儲存服務之間的負載。但是，儲存服務被設計為接受同步請求，並且不能很容易地修改，以讀取資訊以及管理的輸送量。因此，可以引入一個背景工作角色作為接收從該隊列中的請求，並將其轉寄到所述儲存服務的代理服務。在背景工作角色的應用程式邏輯可以控制在它傳遞請求到儲存服務，以防止儲存服務從被壓垮的速率。圖3示出了這種解決方案。

圖3 - 使用隊列和背景工作角色成水平的幅作用和服務執行個體之間的負載

本文翻譯自MSDN：http://msdn.microsoft.com/en-us/library/dn589783.aspx

雲端運算設計模式（十七）——基於隊列的負載平衡模式