使用佇列，做為工作與其叫用之服務之間的緩衝區，以便順暢間歇性繁重負載，而導致服務失敗或工作逾時。這有助於將需求尖峰對工作和服務的可用性和回應性的影響降到最低。
內容和問題
雲端中的許多解決方案都牽涉到執行叫用服務的工作。 在此環境中，如果服務受限於間歇性繁重的負載，可能會導致效能或可靠性問題。
服務可以是與使用該服務之工作相同的解決方案的一部分，或者可能是第三方服務，可提供存取經常使用的資源，例如快取或記憶體服務。 如果一些同時執行的工作使用相同的服務，則隨時都很難預測對服務的要求量。
服務可能會遇到導致其多載且無法及時回應要求的需求尖峰。 如果服務無法處理這些要求所造成的爭用，大量並行要求也會造成服務失敗。
解決方案
重構解決方案，並在工作與服務之間引入佇列。 工作和服務會以異步方式執行。 工作會將包含服務所需數據的訊息張貼至佇列。 佇列會作為緩衝區，儲存訊息，直到服務擷取訊息為止。 服務會從佇列擷取訊息並加以處理。 來自許多工作的要求，可以透過相同的消息佇列以高變數速率產生。 此圖顯示使用佇列來撫平服務上的負載。
佇列會將工作與服務分離，不論並行工作的要求量為何，服務都可以以自己的步調處理訊息。 此外，如果服務在將訊息張貼至佇列時無法使用，則工作不會延遲。
此模式提供下列優點：
它有助於將可用性最大化，因為服務中出現的延遲不會對應用程式產生立即和直接的影響，即使服務無法使用或目前未處理訊息，仍可繼續將訊息張貼至佇列。
它有助於將延展性最大化，因為佇列數目和服務數目可以因應需求而有所不同。
它有助於控制成本，因為部署的服務實例數目必須足以滿足平均負載，而不是尖峰負載。
某些服務會在需求達到超出系統可能會失敗的臨界值時實作節流。 節流可以減少可用的功能。 您可以使用這些服務實作負載撫平，以確保無法達到此閾值。
問題和考慮
決定如何實作此模式時，請考慮下列幾點：
- 您必須實作應用程式邏輯，以控制服務處理訊息的速率，以避免壓倒目標資源。 避免將需求尖峰傳遞至系統的下一個階段。 測試負載下的系統，以確保其提供所需的撫平，並調整佇列數目和處理訊息的服務實例數目，以達成此目的。
- 消息佇列是單向通訊機制。 如果工作需要來自服務的回復，可能需要實作服務可用來傳送響應的機制。 如需詳細資訊，請參閱 異步傳訊入門。
- 如果您將自動調整套用至正在接聽佇列上要求的服務，請小心。 這可能會導致這些服務共用的任何資源競爭增加，並降低使用佇列來撫平負載的效率。
- 根據服務的負載，您可以遇到您實際上一律落後的情況，其中系統一律會排入比您正在處理的更多要求佇列。 必須將連入流量的變化納入考慮
- 模式可能會因為佇列的持續性而遺失資訊。 如果您的佇列損毀或捨棄資訊（因為系統限制），您有可能沒有保證的傳遞。 佇列和系統限制的行為必須根據您的解決方案需求納入考慮。
使用此模式的時機
如果應用程式使用受多載限制的服務，就適用此模式。
如果應用程式預期有來自服務且延遲最少的回應，則此模式並無用處。
工作負載設計
架構設計人員應該評估佇列型負載撫平模式如何用於其工作負載的設計，以解決 Azure 架構良好架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 此模式中所述的方法可藉由將工作的抵達與處理分離，來針對需求突然暴增提供復原能力。 它也可以隔離佇列處理中的故障，使其不會影響攝入量。 - RE：06 調整 - RE：07 背景工作 |
| 成本優化著重於維持和改善工作負載的投資報酬率。 | 由於負載處理與要求或工作接收分離，因此您可以使用此方法來減少過度布建資源以處理尖峰負載的需求。 - CO：12 調整成本 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 這種方法可針對輸送量效能進行刻意設計，因為要求取用不需要與其處理速率相互關聯。 - PE：05 調整和分割 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
Web 應用程式會將數據寫入外部資料存放區。 如果大量 Web 應用程式實例同時執行，數據存放區可能無法快速回應要求，導致要求逾時、節流或失敗。 下圖顯示來自應用程式實例的大量並行要求所淹沒的數據存放區。
若要解決此問題，您可以使用佇列來撫平應用程式實例與數據存放區之間的負載。 Azure Functions 應用程式會從佇列讀取訊息，並執行數據存放區的讀取/寫入要求。 函式應用程式中的應用程式邏輯可以控制將要求傳遞給數據存放區的速率，以防止存放區不堪重負。 （否則函式應用程式只會在後端重新導入相同的問題。
下一步
實作此模式時，下列指引也可能相關：
異步傳訊入門。 消息佇列本質上是異步的。 如果已從直接與服務通訊到使用消息佇列，則可能需要重新設計工作中的應用程式邏輯。 同樣地，可能需要重構服務以接受來自消息佇列的要求。 或者，您可以實作 Proxy 服務，如範例所述。
選擇 Azure 傳訊服務。 在 Azure 應用程式中選擇傳訊和佇列機制的相關信息。
相關資源
- Web-Queue-Worker 架構樣式。 Web 和背景工作角色都是無狀態的。 會話狀態可以儲存在分散式快取中。 背景工作會以異步方式完成任何長時間執行的工作。 背景工作角色可由佇列上的訊息觸發，或依排程執行批處理。
實作此模式時，下列模式也可能相關：