常見的自動調整模式
在此單元中，我們會探討自動調整的模式。
自動調整不是即時解決方案。 簡單地將資源新增至系統或執行更多的流程執行個體並無法保證系統的效能得到改善。 設計自動調整策略時，請考量以下幾點:
建議
識別瓶頸: 相應放大不是每個效能問題的修正魔法。 例如，如果您的後端資料庫是瓶頸，新增更多網頁伺服器沒有幫助。 請找出並解決系統中的瓶頸，再在問題所在之處增加更多執行個體。 系統具狀態組件最有可能是瓶頸的原因。
依可擴縮性需求分解工作負載: 應用程式通常由具有不同可擴縮性需求的多個工作負載組成。 例如，應用程式可能具有公開面向的網站和分開的系統管理網站。 公開網站可能經歷突然的流量激增，而系統管理網站則具有較小、較容易預測的負載。
卸載耗用大量資源的工作：需要許多 CPU 或 I/O 資源的工作應該盡可能移至背景作業。 卸載工作可將處理使用者要求的前端負載降到最低。
使用內建自動調整功能: 如果應用程式具有可預測的規律工作負載，則可照排程進行擴增。 例如，在上班時間進行擴增。 此外，如果工作負載不可預測，請使用效能計量 (例如 CPU 或要求佇列長度) 觸發自動調整。
請考慮對重要工作負載進行積極自動調整: 對於重要工作負載，建議您事先保留需求產能。 建議您在大量負載時迅速新增執行個體來處理其他的流量，然後再逐漸縮減執行個體。
縮減的設計：請記住，利用彈性調整，應用程式會有一段逐漸移除執行個體的縮減期間。 應用程式必須優雅地處理被移除的執行個體。 以下是處理縮減的一些做法：
- 監聽關機事件 (如果可用) 並徹底關機。
- 支援暫時性錯誤處理和重試。
- 針對長時間執行的工作，請考慮將工作分解。
- 將工作項目放在佇列上，如果在處理過程中執行個體被移除了，另一個執行個體就可以收取該工作。
通知
- 所有自動調整失敗都會記錄到 [活動記錄] 中。 然後，您可以設定活動記錄警示，以在發生自動調整失敗時，透過電子郵件、簡訊服務 (SMS) 或 Webhook 通知您。
- 同樣地，所有成功的規模調整動作都會張貼到 [活動記錄] 中。 接著，您可以設定一個活動日誌警示，以便每當有成功的自動規模調整動作時，您便可以通過電子郵件，簡訊或 Webhook 收到通知。 您也可以透過自動調整設定上的 [通知] 索引標籤來設定電子郵件或 Webhook 通知，在調整規模動作成功時收到通知。
在 Azure 中調整資源的常見模式
視需要調整
當客戶需求增加時，您可以自動在工作日開始時擴增服務執行個體數目。 在工作日結束時，自動調整應用程式的執行個體數目，以在應用程式使用較低的夜間降低資源成本。
針對工作日和週末設定不同的規模
在晚上或週末，您可能會有較低的應用程式需求。 如果這樣的負載會持續一段時間，您可以設定自動調整規則，來減少擴展集中的服務執行個體數目。 採用這個縮減的動作可減少執行擴展集的成本，因為只會執行符合目前需求所需的執行個體數目。
在假日期間設定不同的規模
如果您每月或會計週期的特定時間具有大量使用服務，您可以自動調整服務執行個體數目，以因應服務額外的需求。 在舉辦行銷活動、促銷或節日特賣時，您可以基於預期的客戶需求，提前自動調整服務執行的個體數目。
根據客戶計量縮放
最後，建議您謹慎定義自動調整規則。 例如，拒絕服務 (DoS) 攻擊可能導致大規模的傳入流量。 嘗試處理 DoS 攻擊所造成的要求激增，恐怕成效不彰且昂貴。 這些要求不是真的，應該將其捨棄不予處理。 更理想的解決方案是，在這種攻擊所產生的要求接觸到您的服務前，對其進行偵測和篩選。
設定自動調整規則之後，請在一段時間內監視應用程式效能。 如有必要，使用此監視結果來調整系統的調整方式。