控制應用程式實例、個別租用戶或整個服務所使用的資源耗用量。 這可讓系統繼續運作並符合服務等級協定，即使需求增加會對資源產生極端負載也一樣。
內容和問題
雲端應用程式上的負載通常會隨著時間而有所不同，取決於作用中用戶的數目或他們正在執行的活動類型。 例如，在上班時間可能會有更多的用戶處於作用中狀態，或者系統可能需要在每個月底執行計算昂貴的分析。 活動中也可能突然和未預期的暴增。 如果系統的處理需求超過可用的資源容量，則效能不佳，甚至可能會失敗。 如果系統必須符合已同意的服務等級，則這類失敗可能是無法接受的。
根據應用程式的商務目標，有許多策略可用來處理雲端中的不同負載。 其中一個策略是使用 自動調整 ，將布建的資源與任何指定時間的使用者需求相符。 這有可能持續滿足使用者需求，同時優化執行成本。 不過，雖然自動調整可能會觸發更多資源的布建，但此布建並不立即。 如果需求迅速增長，可能會有資源赤字的時間範圍。
解決方案
自動調整的替代策略是允許應用程式只使用最多限制的資源，然後在達到此限制時進行節流。 系統應該監視其使用資源的方式，如此一來，當使用量超過閾值時，它可以對來自一或多個使用者的要求進行節流。 這可讓系統繼續運作，並符合任何已就緒的服務等級協定（SLA）。 如需監視資源使用量的詳細資訊，請參閱 檢測和遙測指引。
系統可以實作數個節流策略，包括：
拒絕在指定時間內每秒存取系統 API 超過 n 次的個別使用者的要求。 這需要系統為執行應用程式的每個租用戶或使用者計量資源的使用量。 如需詳細資訊，請參閱 服務計量指引。
停用或降級所選非必要服務的功能，讓基本服務可以不受足夠的資源阻礙執行。 例如，如果應用程式正在串流視訊輸出，它可以切換為較低的解析度。
使用負載撫平來平滑活動量（以隊列為基礎的負載撫平模式會更詳細地說明這種方法）。 在多租用戶環境中，此方法會減少每個租使用者的效能。 如果系統必須支援混合使用不同 SLA 的租使用者，可能會立即執行高價值租使用者的工作。 其他租使用者的要求可以保留下來，並在待辦項目放寬時處理。 優先順序 佇列模式 可用來協助實作此方法，因為可以公開不同服務層級/優先順序的不同端點。
代表優先順序較低的應用程式或租用戶執行延遲作業。 這些作業可以暫停或限制，但會產生例外狀況，以通知租用戶系統忙碌中，稍後應重試作業。
與某些可能無法使用或傳回錯誤的第三方服務整合時，您應該小心。 減少正在處理的並行要求數目，讓記錄不會不必要地填滿錯誤。 您也可以避免因第三方服務而需要重試處理失敗的要求的相關成本。 然後，成功處理要求時，請回到一般未處理的要求。 實作此功能的其中一個連結庫是 NServiceBus。
此圖顯示資源使用的區域圖表（記憶體、CPU、頻寬和其他因素的組合），以針對使用三個功能的應用程式使用時間。 功能是一個功能區域，例如執行特定工作集的元件、執行複雜計算的程式代碼段，或提供記憶體內部快取等服務的專案。 這些功能會標示為 A、B 和 C。
功能行正下方的區域表示應用程式叫用此功能時所使用的資源。 例如，功能 A 行下方的區域會顯示使用特徵 A 的應用程式所使用的資源，以及功能 A 和 Feature B 各行之間的區域，表示叫用 Feature B 的應用程式所使用的資源。匯總每個功能的區域會顯示系統的總資源使用量。
上圖說明延遲作業的效果。 就在 T1 之前，使用這些功能配置給所有應用程式的資源總數達到臨界值（資源使用限制）。 此時，應用程式有耗盡可用資源的危險。 在此系統中，功能 B 比功能 A 或功能 C 更不重要，因此會暫時停用，並使用的資源會釋出。 在 T1 和 T2 之間，使用 Feature A 和 Feature C 的應用程式會繼續正常執行。 最後，這兩個功能的資源使用量會降低到 T2 時，有足夠的容量可再次啟用功能 B。
也可以結合自動調整和節流方法，協助讓應用程式保持回應，並在 SLA 內。 如果需求預期會保持高，則節流會在系統相應放大時提供暫時性解決方案。此時，可以還原系統的完整功能。
下一個圖顯示系統內執行之所有應用程式針對時間執行之整體資源使用的分區圖，並說明節流如何與自動調整結合。
在 T1 時，達到指定資源使用軟限制的臨界值。 此時，系統可以開始向外延展。不過，如果新的資源不夠快速可用，則現有的資源可能會耗盡，而且系統可能會失敗。 為了防止這種情況發生，系統會暫時節流系統，如先前所述。 當自動調整完成且可用的額外資源時，節流可能會放寬。
問題和考量
決定如何實作此模式時，您應該考慮下列幾點：
節流應用程式，以及要使用的策略，是影響整個系統設計的架構決策。 應用程式設計程式中應該儘早考慮節流，因為實作系統之後，新增並不容易。
必須快速執行節流。 系統必須能夠偵測活動增加，並據以做出反應。 系統也必須能夠在負載放寬之後快速還原成其原始狀態。 這需要持續擷取和監視適當的效能數據。
如果服務需要暫時拒絕使用者要求，它應該傳回特定的錯誤碼，例如 429 （「太多要求」）和 503 （「伺服器太忙碌」），因此用戶端應用程式可以了解拒絕處理要求的原因是節流。
- HTTP 429 表示呼叫端應用程式在時間範圍中傳送太多要求，並超過預先決定的限制。
- HTTP 503 表示服務尚未準備好處理要求。 常見的原因是服務遇到比預期更多的暫時性負載尖峰。
用戶端應用程式可以在重試要求之前等候一段時間。 Retry-After應包含 HTTP 標頭，以支援客戶端選擇重試策略。
節流可作為系統自動調整時的暫存量值。 在某些情況下，如果活動突然突然出現高載，而且不會長時間運作，最好只是節流，而不是調整，因為調整可能會大幅增加執行成本。
如果在系統自動調整時使用節流作為暫存量值，而且如果資源需求非常快成長，系統可能無法繼續運作，即使以節流模式運作也一樣。 如果無法接受，請考慮維護較大的容量保留，並設定更積極的自動調整。
將不同作業的資源成本正規化，因為它們通常不會有相同的執行成本。 例如，讀取作業的節流限制可能較低，寫入作業的節流限制較高。 不考慮作業的成本可能會導致耗盡的容量，並暴露潛在的攻擊媒介。
在運行時間進行節流行為的動態設定變更是可取的。 如果系統面臨套用設定無法處理的異常負載，節流限制可能需要增加或減少，以穩定系統並跟上目前的流量。 此時，不建議使用昂貴、具風險且緩慢的部署。 使用外部組態存放區模式節流設定已外部化，而且不需要部署即可變更和套用。
使用此模式的時機
使用此模式：
確保系統持續符合服務等級協定。
防止單一租用戶壟斷應用程式所提供的資源。
處理活動中的高載。
藉由限制維持系統運作所需的最大資源層級，協助將系統成本優化。
工作負載設計
架構設計人員應該評估節流模式在工作負載的設計中如何使用，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 您可以設計限制來協助防止可能導致故障的資源耗盡。 您也可以在正常降級計劃中使用此模式作為控制機制。 - RE：07 自我保護 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 您可以設計限制，以協助防止資源耗盡，這可能會導致系統自動濫用。 - SE：06 網路控制 - SE：08 強化資源 |
| 成本優化著重於維持和改善工作負載的投資報酬率。 | 強制執行的限制可以通知成本模型化，甚至可以直接系結至應用程式的商務模型。 它們也會對使用率加上明確的上限，這可納入資源大小調整。 - CO：02 成本模型 - CO：12 調整成本 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 當系統需求過高時，此模式有助於降低可能導致效能瓶頸的壅塞。 您也可以使用它來主動避免吵雜的鄰近案例。 - PE：02 容量規劃 - PE：05 調整和分割 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
最後一個圖說明如何在多租用戶系統中實作節流。 來自每個租用戶組織的使用者會存取雲端裝載的應用程式，在其中填寫並提交問卷。 應用程式包含檢測，可監視這些使用者提交要求給應用程式的速率。
為了防止使用者有一個租用戶影響所有其他使用者的應用程式回應性和可用性，限制會套用至任何一個租使用者可以提交的每秒要求數目。 應用程式會封鎖超過此限制的要求。
下一步
實作此模式時，下列指引也可能相關：
- 檢測和遙測指引。 節流取決於收集使用服務程度的相關信息。 描述如何產生和擷取自定義監視資訊。
- 服務計量指引。 描述如何計量服務的使用量，以便瞭解其使用方式。 這項資訊有助於判斷如何節流服務。
- 自動調整指引。 節流可以在系統自動調整時做為過渡量值，或移除系統自動調整的需求。 包含自動調整策略的相關信息。
相關資源
實作此模式時，下列模式也可能相關：