（二十三）——Throttling 節(jié)流模式

云計算設計模式（二十三）——Throttling 節(jié)流模式

控制由應用程序使用，一個單獨的租戶或整個服務的一個實例的資源的消耗。這種模式可以允許系統繼續(xù)運行并滿足服務水平協議，即使當增加需求的資源放置一個極端載荷。

背景和問題

在云應用負載通常上變化的基礎上的活動用戶的數量或他們正在執(zhí)行的活動類型的時間。例如，多個用戶可能會在工作時間被激活，否則系統可能被要求在每月結束時執(zhí)行計算昂貴的分析。也有可能是突然和意外的突發(fā)活動。如果系統的處理要求超過了可用的資源的能力，其將遭受性能不佳，甚至會失敗。該系統可能必須滿足的服務約定的水平，并且這種故障可能是不可接受的。

有許多策略可用于處理可變負載在云中，根據業(yè)務目標的應用程序。一種策略是使用自動縮放來在任何給定時間相匹配的供應資源給用戶的需要。這具有始終如一地滿足用戶需求，同時優(yōu)化運行費用的潛力。然而，盡管自動縮放可能會引發(fā)更多的資源配置，這配置是不是瞬間。如果需求快速增長，有可能是一個時間窗口，那里是一個資源赤字。

解決方案

另一種策略來自動縮放是為了讓應用程序能夠使用的資源最多只有一些軟限位，然后油門當他們達到此限制。該系統應監(jiān)測它是如何使用的資源，使得當使用量超過一些系統定義的閾值時，它可以調節(jié)來自一個或多個用戶的請求，以使系統繼續(xù)工作，并滿足任何服務級別協議（SLA），該已到位。有關監(jiān)控資源使用情況的詳細信息，請參閱儀器和遙測指導。

該系統可以實現多種限制策略，其中包括：

• 從誰已經訪問系統API超過每秒n次超過給定時間內的個人用戶拒絕請求。這就要求系統米利用資源用于運行應用程序的每個租戶或用戶。欲了解更多信息，請參閱服務計量指引。
• 禁用或有辱人格的選擇不必要的服務的功能，以便必要的服務可以提供足夠的資源運行暢通。例如，如果應用程序是視頻流輸出，它可以切換到一個較低的分辨率。
• 使用負載均衡來平滑活動量（這種方法是覆蓋在由基于隊列的負載均衡模式的更多細節(jié)）。在多租戶環(huán)境中，這種方法將減少為每一個租戶的性能。如果系統必須支持的住戶有不同的SLA的組合，為高價值租戶的工作可能會被立即執(zhí)行。請求其他住戶可以忍住，以及時處理積壓有所緩解。優(yōu)先級隊列模式，可以用來幫助實現此方法。
• 代表低優(yōu)先級的應用程序或租戶被推遲執(zhí)行的操作。這些操作可以暫?；蛳鳒p，異常生成的通知，該系統正忙，該操作應該稍后重試房客。

圖1示出一個區(qū)域圖進行資源利用率（存儲器，CPU，帶寬，以及其它因素的組合）對時間對于正在使用的三個特征的應用程序。一個特征是功能性的區(qū)域，例如，執(zhí)行特定的任務集，一個代碼段，執(zhí)行一個復雜的計算，或者，提供了一個服務，例如在內存中緩存的元素的組分。這些特征被標記為 A，B 和 C。

圖1 - 對時間的曲線圖的資源利用率代表三個用戶運行的應用程序

注意：

立即行功能下的區(qū)域表示應用程序中使用時，調用此功能的資源。例如，下面的線為特色的一個區(qū)域顯示使用的是正在使用的功能 A 的應用資源，并為特征 A 和特征 B 線之間的區(qū)域被使用的應用程序調用功能 B.匯總的指示資源對于每個特征區(qū)域顯示了系統的總的資源利用率。

在圖1中的曲線示出了延遲操作的效果。只是之前的時間 T1，分配給使用這些功能的所有應用程序的總資源達到一個閾值（資源利用的軟限制）。在這一點上，應用程序是在用盡可用的資源的危險。在這個系統中，特征 B 比特點 A 或特征 ? 不太重要，所以它是暫時禁用，并且它被使用的資源被釋放。之間的時間 T1，T2，使用功能 A 和功能 C 中的應用程序繼續(xù)運行正常。最后，資源利用這兩個功能減退的點時，在時間 T2 時，有足夠的容量，以再次啟用功能 B 中。

該自動縮放和調節(jié)方法也可以結合，以幫助保持應用程序響應和 SLA 之內。如果需求預計將保持高位，節(jié)流可以提供一個臨時的解決方案，同時在系統擴展了。在這一點上，該系統的全部功能可以恢復。

圖 2 示出了整體的資源利用通過在與時間的系統中運行的所有應用程序的區(qū)域圖，并示出了如何限制可與自動縮放組合。

圖2 - 圖表顯示自動縮放與節(jié)流相結合的效應

在時間T1，門檻指定資源利用的軟限制為止。在這一點上，系統可以開始向外擴展。然而，如果新的資源不成為可用的足夠快地再現有的資源可能被耗盡，并且系統可能會失敗。為了防止這種情況發(fā)生，系統被暫時限制，如前面所述。何時自動縮放已完成和額外資源，限制可以放寬。

問題和注意事項

在決定如何實現這個模式時，您應考慮以下幾點：

• 節(jié)流的應用程序，并使用策略，是一個建筑的決定，影響系統的整體設計。節(jié)流應在應用設計之初就被考慮，因為這是不容易的添加它一旦系統已經實施。
• 節(jié)流必須迅速執(zhí)行。系統必須能夠檢測活性增加，并相應地作出反應。該系統還必須能夠恢復到原來的狀態(tài)后快速負載有所緩和。這需要相應的性能數據是不斷捕獲和監(jiān)測。
• 如果一個服務需要暫時拒絕用戶的請求，則它應該返回一個特定的錯誤代碼，以使客戶端應用程序理解為拒絕執(zhí)行某種操作的原因是由于節(jié)流。客戶端應用程序可以等待一段時間，然后重試該請求。
• 節(jié)流可作為而系統 autoscales一項臨時措施。在某些情況下它可能是更好的簡單節(jié)流，而不是按比例，如果在活動突發(fā)是突然的并且預計不會被長壽命，因為結垢可顯著增加了運行成本。
• 如果節(jié)流正在使用的臨時措施，而一個系統 autoscales，并且如果資源需求迅速增長，系統可能無法繼續(xù)運作，即使在節(jié)流模式中操作時。如果這是不能接受的，考慮維護大容量的儲備和配置更積極自動縮放。

何時使用這個模式

使用這種模式：

• 為了確保系統持續(xù)滿足服務水平協議。
• 為了防止單一租戶獨占由應用程序所提供的資源。
• 為了處理突發(fā)活動。
• 為了幫助限制需要保持它運轉的最大資源水平的成本優(yōu)化的系統。

例子

圖3示出了如何限制可以在多租戶系統來實現。從每個租戶組織的用戶訪問一個云托管的應用程序，他們填寫并提交調查。應用程序中包含的儀器，用于監(jiān)視在其中這些用戶提交請求給應用程序的速度。

為了防止用戶從一個租戶影響應用的所有其他用戶的響應性和可用性，限制施加到每秒從任何一個租戶的用戶可以提交請求的數目。該應用程序塊請求超過此限制

圖3 - 在一個多租戶應用程序中實現節(jié)流