向外延展的設計

  • 發行項

設計您的應用程式，使其可以水準調整

雲端的主要優點是彈性調整 — 能夠視需要使用盡可能多的容量、隨著負載增加而相應放大，以及在不需要額外容量時相應縮小。 設計您的應用程式，使其可以視需要水準調整、新增或移除新的實例。

建議

避免實例黏性 。 黏性或 會話親和性 是來自相同用戶端的要求一律路由傳送至相同的伺服器時。 黏性會限制應用程式相應放大的能力。例如，來自大量使用者的流量不會分散到實例。 黏性的原因包括將會話狀態儲存在記憶體中，以及使用電腦特定的金鑰進行加密。 請確定任何實例都可以處理任何要求。

識別瓶頸 。 相應放大並不是每個效能問題的魔術修正程式。 例如，如果您的後端資料庫是瓶頸，新增更多網頁伺服器沒有幫助。 先找出並解決系統中的瓶頸，再向問題擲回更多實例。 系統具狀態組件最有可能是瓶頸的原因。

依可擴縮性需求分解工作負載。 應用程式通常由多個工作負載組成，並有不同的調整需求。 例如，應用程式可能具有公開面向的網站和分開的系統管理網站。 公開網站可能經歷突然的流量激增，而系統管理網站則具有較小、較容易預測的負載。

卸載自然非同步工作。 傳送電子郵件、使用者不需要立即回應的動作，與其他系統整合等工作都是使用 非同步傳訊模式 的好地方。

卸載耗用大量資源的工作。 需要大量 CPU 或 I/O 資源的工作應該盡可能移至背景工作 ，以將處理使用者要求的前端負載降到 最低。

使用內建的自動調整功能 。 許多 Azure 計算服務都有自動調整的內建支援。 如果應用程式具有可預測的一般工作負載，請依排程相應放大。 例如，在上班時間進行擴增。 否則，如果工作負載無法預測，請使用 CPU 或要求佇列長度等效能計量來觸發自動調整。 如需自動調整最佳做法，請參閱 自動調整 。

請考慮針對重要工作負載 進行積極的自動調整。 針對重要的工作負載，您想要在需求之前保持領先。 最好在負載過重的情況下快速新增實例，以處理額外的流量，然後逐漸相應減少。

相應縮小 的設計。 請記住，當實例移除時，應用程式將會有相應縮小的期間。 應用程式必須優雅地處理被移除的執行個體。 以下是處理 scalein 的一些方式：

  • 監聽關機事件 (如果可用) 並徹底關機。
  • 服務的用戶端/消費者應支持瞬間故障處理和重試。
  • 對於長時間執行的工作，請考慮使用檢查點或 管道和篩選 模式來中斷工作。
  • 將工作專案放在佇列上，以便在處理中間移除實例時，讓另一個實例可以挑選工作。

請考慮調整備援規模。 相應放大可改善應用程式的可靠性。 例如，請考慮跨多個 可用性區域 相應放大，例如使用區域備援服務。 這種方法可以改善應用程式的輸送量，以及在某個區域發生中斷時提供復原能力。