自動調整是以動態方式配置資源以符合效能需求的程序。 隨著工作量的成長，應用程式可能需要更多資源來保有所需的效能層級及滿足服務等級協定 (SLA)。 當需求減少且不再需要額外資源時，可以釋放資源以降低成本。
自動調整擴展會充分利用雲端託管環境的彈性，同時減輕管理負擔。 其可減少操作員持續監視系統效能的需求，並做出有關新增或移除資源的決策。
應用程式有兩種主要方式可調整：
垂直擴展，也稱為向上和向下調整，表示調整資源的容量。 例如，您可以將應用程式移至較大的虛擬機大小。 垂直調整通常需要在重新部署時使系統暫時無法使用。 因此，自動化垂直調整比較不常見。
水平調整，也稱為橫向擴展和縮減，指的是新增或移除資源的實例。 在佈建這些新資源時，應用程式會繼續執行而不中斷。 佈建程序完成時，解決方案即會部署在這些額外的資源上。 如果要求降低，則可以完全關閉及取消配置這些額外的資源。
許多雲端式系統，包括Microsoft Azure，都支援自動水平調整。 本文的其餘部分著重於水平調整。
備註
自動調整主要適用於計算資源。 雖然可以水平調整資料庫或消息佇列，但此程式通常牽涉到 數據分割，這通常不會自動化。
自動調整元件
自動調整原則通常涉及下列元件：
應用程式、服務和基礎結構層級的檢測和監視系統。 這些系統會擷取關鍵計量，例如響應時間、佇列長度、CPU 使用率和記憶體使用量。
決策邏輯會根據預先定義的閾值或排程評估這些即時使用計量，並決定是否要調整。
元件和機制會執行調整動作。 在理想情況下，這些元件和機制應該與工作負載程式代碼本身分離，並以外部進程的形式進行管理。 閑置或過載的程式代碼不應該負責調整自身。
自動調整策略的測試、監視和微調功能，以確保其如預期般運作。
Azure 提供解決常見案例的內建自動調整機制。 如果特定服務或技術沒有內建的自動調整功能，或您有超出其功能的特定自動調整需求，請考慮自定義實作。 自定義實作會收集作業和系統計量、分析計量，並據以調整資源。
設定 Azure 解決方案的自動縮放
Azure 提供適用於大部分計算選項的內建自動調整。
透過虛擬機擴展集自動調整 Azure 虛擬機，以群組方式管理一組虛擬機。 如需詳細資訊，請參閱 使用自動調整和虛擬機規模集。
Azure Service Fabric 支援透過虛擬機擴展集進行自動調整。 Service Fabric 叢集中的每個節點類型都會設定為個別的虛擬機擴展集。 每個節點類型都可以獨立縮小或擴大。 如需詳細資訊，請參閱 使用自動調整規則相應縮小或相應放大 Service Fabric 叢集。
Azure App Service 具有內建的自動伸縮。 自動調整設定會套用至 App Service 內的所有應用程式。 如需詳細資訊，請參閱在 App Service 中 手動或自動擴展實例數量 和 擴展應用程式。
這些計算選項全都使用 Azure 監視器自動調整功能 來提供一組常見的自動調整功能。
- Azure Functions 與先前的計算選項不同，因為您不需要設定任何自動調整規則。 相反地，當您的程式代碼執行時，Azure Functions 會自動配置計算能力。 Azure Functions 會視需要彈性擴展來處理負載。 如需詳細資訊，請參閱 選擇正確的 Azure Functions 主控方案。
自定義自動調整解決方案有時可能很有用。 例如，您可以使用 Azure 診斷和應用程式型計量，以及自定義程式代碼來監視和導出應用程式計量。 然後，您可以根據這些計量定義自定義規則，並使用 Azure Resource Manager REST API 來觸發自動調整。 不過，自定義解決方案並不簡單，只有在上述任何方法都無法滿足您的需求時，才應考慮使用。
如果平臺符合您的需求，請使用平臺的內建自動調整功能。 如果沒有，請仔細考慮您是否需要更複雜的調整功能。 其他需求的範例可能包括更細微的控制、偵測用於調整的觸發事件、跨訂閱之間的調整，以及調整其他類型的資源。
使用 Azure 監視器自動調整功能
Azure 監視器自動調整功能為虛擬機擴展集、App Service 和 Azure 雲端服務提供一組常見的自動調整功能。 您可以依排程或根據運行時間計量來執行調整，例如 CPU 或記憶體使用量。
請考慮下列範例：
在工作日擴展至 10 個實例，並在星期六和星期日縮減至四個實例。
如果平均 CPU 使用量超過 70%，則擴展一個實例；當 CPU 使用量低於 50%，則縮減一個實例。
如果佇列中的訊息數目超過特定閾值，則擴展一個實例。
當負載增加時相應增加資源，以確保可用性。 在低使用量時，縮減規模以優化成本。 務必使用擴展和縮減的規則組合。 否則，自動調整只會以一個方向進行，直到達到配置檔中設定的臨界值（最大值或最小實例計數）。
選取適用於您工作負載的預設實例計數。 如果未設定最大或最小實例計數，資源會根據該值進行調整。
如需內建計量的清單，請參閱 Azure 監視器自動調整一般計量。 您也可以使用 Application Insights 來實作自定義計量。
您可以使用 PowerShell、Azure CLI、Azure Resource Manager 範本或 Azure 入口網站來設定自動調整。 如需更詳細的控制，請使用 Resource Manager REST API。 Azure 監視管理連結庫和 Microsoft Insights 連結庫 （預覽版） 是 SDK，可讓您從不同的資源收集計量，並使用 REST API 來執行自動調整。 對於無法使用 Resource Manager 支援的資源，或使用 Azure 雲端服務時，可以使用服務管理 REST API 進行自動調整。 在其他所有情況下，請使用 Resource Manager。
使用自動調整時，請考慮下列幾點：
請考慮您是否可以準確地預測應用程式上的負載，以使用排程的自動調整、新增和移除實例，以符合預期的需求尖峰。 如果您無法，請使用以運行時間計量為基礎的響應式自動調整來處理需求無法預測的變更。 一般而言，您可以結合這些方法。
例如，建立策略，根據您知道應用程式最忙碌的時間排程來新增資源。 額外的資源可以確保容量在需要時立即可用，避免啟動新實例時的延遲。 針對每個排程規則，定義計量，以在該期間允許響應式自動調整，以確保應用程式可以處理持續但無法預測的需求尖峰。
通常很難瞭解計量與容量需求之間的關聯性，特別是一開始部署應用程式時。 在一開始設定一點額外的容量，然後監視和調整自動調整規則，讓容量更接近實際負載。
設定自動調整規則，然後持續監視應用程式的效能。 使用此監視的結果，視需要調整系統調整的方式。 不過，請記住，自動調整不是一個瞬間完成的過程。 需要時間來回應計量，例如平均CPU使用率超過或低於指定的閾值。
根據經測量的觸發屬性使用檢測機制的自動擴展規則，會使用隨著時間匯總的值，而非即時值，以觸發自動擴展動作。 觸發程式屬性包括 CPU 使用量或佇列長度。 根據預設，匯總是值的平均值。 這種方法可防止系統反應太快或造成快速振蕩。 它還允許自動啟動的新實例有時間進入運行模式。 啟動新實例時，無法執行其他自動調整動作。 針對 Azure 雲端服務和 Azure 虛擬機，匯總的預設期間為 45 分鐘。 因此，計量最多可能需要這段時間才能觸發自動調整，以回應需求尖峰。 您可以使用 SDK 來變更匯總期間，但少於 25 分鐘的期間可能會導致無法預期的結果。 針對 App Service 的 Web Apps 功能，平均計算期間較短，使得在更改平均觸發標準後，新實例可以在約五分鐘內準備就緒。
避免規模縮小和擴展操作不斷來回擺動。 假設有兩個實例。 上限為 80% CPU，下限為 60%。 當負載在85%時，會新增另一個實例。 經過一段時間之後，負載會減少到 60%。 在自動調整服務收縮規模之前，它會在移除一個實例時計算三個實例的總負載分佈，並將其負載分佈調整至 90%。 它必須立即再次擴展。 因此，它會略過「縮小規模」的過程，而且您可能永遠無法看到應有的縮放結果。
通過在擴展和縮減閾值之間選擇適當的邊界即可控制波動情況。
手動縮放會根據自動調整使用的實例數目上限和下限進行重置。 如果您手動將實例計數更新為高於或低於最大值的值，自動調整引擎會自動縮減為最小值（如果較低）或最大值（如果更高）。 例如，您可以設定介於 3 到 6 之間的範圍。 如果您有一個執行中的實例，自動調整引擎會在下次執行時調整為三個實例。 同樣地，如果您手動將縮放比例設定為八個實例，在下一次執行時自動調整會將它調整回六個實例。 除非您也重設自動調整規則，否則手動調整是暫時性的。
自動縮放引擎每次僅處理一個設定檔。 如果條件不符合，則會檢查下一個設定檔。 請將關鍵指標保持不在預設配置檔中，因為該配置檔最後才會被檢查。 在一個設定檔中，您可以擁有多個規則。 在向外擴展時，只要符合任何規則，就會啟動自動調整。 在縮小規模時，自動調整需要符合所有規則。
如需 Azure 監視器調整方式的詳細資訊，請參閱 自動調整的最佳做法。
如果您使用 SDK 而不是入口網站來設定自動調整，您可以指定更詳細的排程，讓規則處於作用中狀態。 您也可以建立自己的指標，並在自動調整規則中選擇搭配使用現有指標或獨立使用這些自訂指標。 例如，您可能想要使用替代計數器，例如每秒要求數目或平均記憶體可用性。 或者，您可以使用自定義計數器來測量特定的商務程式。
當您自動調整 Service Fabric 時，叢集中的節點類型是由後端的虛擬機擴展集所組成，因此您必須為每個節點類型設定自動調整規則。 在設定自動調整之前，請先考慮您必須擁有的節點數目。 您的可靠性層級會驅動您針對主要節點類型必須擁有的節點數目下限。 如需詳細資訊，請參閱 使用自動調整規則相應縮小或相應放大 Service Fabric 叢集。
您可以使用入口網站，將 Azure SQL Database 實例和佇列等資源連結至雲端服務實例。 這個方法可讓您更輕鬆地存取每個鏈接資源的個別手動和自動調整組態選項。 如需詳細資訊，請參閱 管理 Azure 雲端服務。
當您設定多個原則和規則時，它們可能會彼此衝突。 自動調整會使用下列衝突解決規則，以確保一律有足夠的實例執行：
向外延展操作始終優先於縮小延展操作。
當擴展作業衝突時，規則是以最大的實例數增長為優先。
當縮減操作發生衝突時，優先選擇導致實例數量減少幅度最小的規則。
在 App Service 環境中，任何工作者集區或前端度量都可以用來定義自動調整規則。 如需詳細資訊，請參閱 App Service 環境概觀。
應用程式設計考慮
自動調整不是立即解決方案。 只要將資源新增至系統或執行更多進程實例，就不保證系統的效能會改善。 設計自動調整策略時，請考慮下列幾點：
系統必須設計為可水平調整。 避免對實例親和性進行假設。 請勿設計需要程式碼一律在特定進程實例中執行的解決方案。 水平調整雲端服務或網站時，請勿假設一系列來自相同來源的要求一律會路由傳送至相同的實例。 基於同樣的原因，設計服務是無狀態的，以避免要求一系列來自應用程式的要求一律路由傳送至相同的服務實例。 設計從佇列讀取訊息並處理訊息的服務時，請勿對服務處理特定訊息的實例進行任何假設。 隨著佇列長度的成長，自動擴展可能會啟動更多服務實例。 競爭取用者模式 說明如何處理此情境。
如果解決方案實作長時間執行的工作，請設計此工作以支持擴展和縮減。 如果沒有適當的設計，這類工作可能會防止系統相應縮小時，進程實例會完全關閉。 或者，如果進程被強制終止，它可能會遺失數據。 在理想情況下，重構長時間執行的工作，並將其執行的處理分成較小的離散區塊。 如需範例，請參閱 管道和篩選模式。
或者，您可以實作檢查點機制，以定期記錄工作的狀態資訊。 將此狀態資訊儲存在長期記憶體中，執行工作的任何進程實例都可以存取。 因此，如果進程已關閉，則可以使用另一個實例，從最後一個檢查點繼續執行的工作。 有提供此功能的程式庫，例如 NServiceBus 和 MassTransit。 它們會透明地持久化狀態，佇列訊息的處理間隔與 Azure Service Bus 中的處理流程一致。
當背景工作在不同的計算實例上執行時，例如在雲端服務裝載應用程式的背景工作角色中，您可能需要使用不同的調整原則來調整應用程式的不同部分。 例如，您可能需要部署更多使用者介面 （UI） 計算實例，而不需要增加背景計算實例的數目，或相反。 您可以提供不同的服務層級，例如基本和進階服務套件。 您可能需要比基本服務套件的資源更積極地向外延展進階服務套件的計算資源。 此方法可協助您符合 SLA。
其他縮放準則
請考量用於UI和背景計算實例之間通訊的佇列長度。 使用它作為自動擴展策略的準則。 此準則可以指出目前負載與背景工作處理容量之間的不平衡或差異。 做出縮放決策時，有一種稍微複雜但更好的屬性可作為依據。 使用訊息傳送的時間，以及訊息處理完成的時間，稱為 「關鍵時間」。 如果這個關鍵時間值低於有意義的商務閾值，則不需要調整，即使佇列長度很長也一樣。
例如，佇列中可能有 50,000 則訊息。 但最舊訊息的關鍵時間是500毫秒，該端點正在處理與合作夥伴Web服務整合以傳送電子郵件。 業務相關人士可能認為此情境不夠緊急，來證明進行擴展所需的成本是合理的。
另一方面，佇列中可能會有 500 則訊息，且這些訊息的處理時間均為關鍵的 500 毫秒。 但端點是即時在線遊戲中重要路徑的一部分，其中商務項目關係人定義了 100 毫秒或更少的回應時間。 在此情況下，擴展是合理的。
為了在自動調整決策中有效利用關鍵時機，讓函式庫在訊息的傳輸和處理期間自動將相關資訊新增至訊息標頭會很有幫助。 提供此功能的其中一個這類程式庫是 NServiceBus。
如果您的自動調整策略是基於測量商業流程的計數器，請確保您完全了解這些計數器結果與實際計算容量需求之間的關聯性。 計數器的範例包括每小時的訂單數或複雜交易的平均運行時間。 您可能需要調整多個元件或計算單位，以響應業務流程計數器的變化。
若要防止系統嘗試擴展過度，請考慮限制可自動增加的實例數量上限。 此方法也會避免與執行數千個實例相關聯的成本。 大部分的自動調整機制都可讓您指定規則的實例數目下限和上限。 如果系統在已部署最大實例數目後仍然過載，請考慮平穩降級系統所提供的功能。
請記住，自動調整可能不是處理工作負載突然暴增的最適當機制。 設定和啟動服務的新實例或將資源新增至系統需要時間。 尖峰需求可能會在這些額外資源可用時經過。 在這種情況下，或許最好對服務進行節流。 如需詳細資訊，請參閱 節流模式。
相反地，如果您需要在請求量快速波動時處理所有要求，請考慮使用積極的自動調整策略，以更快速地啟動額外的執行個體。 請確定成本不是主要因素。 您也可以使用排程策略，在預期負載達到最大值之前啟動足夠多的實例，來應對這個負載。
自動調整機制應該監視自動調整程式，並記錄每個自動調整事件的詳細數據。 這些詳細數據包括觸發事件的內容、已新增或移除哪些資源，以及發生時。 如果您建立自定義自動調整機制，請確定它包含這項功能。 分析資訊以協助測量自動調整策略的有效性，並視需要調整。 您可以在短期內進行調整，隨著使用模式變得更加明顯，並在長期內進行調整，以因應業務擴展或應用程式需求的演變。 如果應用程式達到自動調整所定義的上限，機制可能也會警示作員，他們可能在必要時手動啟動額外的資源。 在這些情況下，操作員也可能會負責在工作量減輕之後手動地移除相關的資源。
相關資源
實作自動調整時，下列模式和指引也可能與您的案例相關：