向外延展的設計
設計您的應用程式，使其能夠實現水平縮放
雲端的主要優勢之一是彈性縮放，即根據需要使用所需的容量，當負載增加時進行擴增，當額外容量不再需要時進行縮減。 設計您的應用程式，使其可以水平擴展，增加或移除執行個體，使供應與需求相符。
可擴展性是以輸送量增加與資源增加的比率來衡量。 在理想情況下，在設計良好的系統中，這兩個數字都成正比：兩倍的資源分配將使輸送量增加一倍。 可擴展性通常受限於系統中的瓶頸或同步點。
建議
避免執行個體黏性。 黏性或工作階段親和性指的是來自相同用戶端的請求總是被路由到相同的伺服器。 黏性會限制應用程式的水平擴增能力。例如，來自高流量使用者的流量將不會分佈到不同的執行個體上。 造成黏性的原因包括將工作階段狀態儲存在記憶體中，以及使用機器專屬的金鑰進行加密。 確保任何執行個體都能處理任何請求。
找出瓶頸。 並非所有效能問題都能用水平擴增來解決。 例如，如果您的後端資料庫是瓶頸，新增更多網頁伺服器沒有幫助。 請先找出並解決系統中的瓶頸，再考慮增加更多執行個體來解決問題。 系統具狀態組件最有可能是瓶頸的原因。
依可擴縮性需求分解工作負載。 應用程式通常包含多個工作負載，每個工作負載對擴縮的需求各不相同。 例如，應用程式可能具有公開面向的網站和分開的系統管理網站。 公開網站可能經歷突然的流量激增，而系統管理網站則具有較小、較容易預測的負載。
設計自主且去耦的元件，透過非同步通訊協定進行通訊。 理想情況下，元件應具有自己的獨立狀態，並使用事件來向外部元件傳遞任何變更或活動。 這有助於只單獨擴增過載的元件。 實施流量控制機制來管理流量，實現得體地降級。 消費者應控制自己的耗用速率。 生產者應控制自己的傳輸速率，包括在必要時停止傳輸。 訊息佇列是吸收額外工作負載並允許取用者按其節奏處理工作的良好選擇。
避免不必要的通訊、協調和等待。
自然卸除非同步工作。 像是傳送電子郵件、使用者不需要即時回應的操作，以及與其他系統的整合，都是使用非同步傳訊模式的好時機。
卸載耗用大量資源的工作。 為了將處理使用者要求的前端負載降到最低，建議您盡量將需要大量 CPU 或 I/O 資源的工作移至背景工作。
根據即時使用指標進行自動擴縮，並使用內建的自動擴縮功能。 許多 Azure 計算服務內建支援自動擴縮。 如果應用程式有可預測的規律工作負載，可以按照預定計劃進行擴增。 例如，在上班時間進行擴增。 此外，如果工作負載不可預測，請使用效能計量 (例如 CPU 或要求佇列長度) 觸發自動擴縮。 觀察應用程式及其通訊，以找出瓶頸並做出更準確的決策。 有關自動擴縮的最佳做法，請參閱「自動擴縮」。
對於關鍵工作負載，考慮採取主動式自動擴縮。 對於關鍵工作負載，您需要先於需求進行準備。 建議您在大量負載時迅速新增執行個體來處理其他的流量，然後再逐漸縮減執行個體。
設計時考慮縮減。 請記住，使用彈性擴縮時，應用程式會有縮減階段，即執行個體會被移除。 應用程式必須優雅地處理被移除的執行個體。 以下是處理縮減的一些做法：
- 監聽關機事件 (如果可用) 並徹底關機。
- 服務的用戶端/消費者應支持瞬間故障處理和重試。
- 對於長時間執行的工作，請考慮使用檢查點或管道和篩選模式來拆分工作。
- 將工作項目放入佇列中，以便如果某個執行個體在處理過程中被移除，其他執行個體可以繼續處理這些工作。
考慮為備援進行擴縮。 擴增可以提高應用程式的可靠性。 例如，考慮在多個可用區域進行擴增，例如使用區域備援服務。 這種方法可以提高應用程式的輸送量，同時在某個區域發生中斷時提供復原能力。
建模並最佳化系統的可擴展性。 您可以使用阿姆達爾定律等方法來建立系統模型。 根據爭用和一致性等參數量化可擴展性。 爭用是指由於共用資源的等待或排隊所造成的延遲。 一致性是指資料變得一致的延遲。 舉例來說，競爭性高表示可以並行化的順序處理，而一致性高則表示程序之間有過度的依賴關係，促使您盡量減少互動。 在工作負載設計期間，您可以計算系統的最大有效容量，避免供過於求，造成浪費。