什麼是延展性？

在商業世界中，成長可能有益。 不過，當成長速度過快，且您尚未充分準備好成長時，成長可能會造成問題。 其中一個問題是成長對未設計來處理大量流量增加的應用程式和服務可靠性的影響。

對於客戶和使用者來說，中斷就是中斷。 他們不知道或不在意他們是否因為錯誤程式碼而無法存取您的網站，或因為太多其他人嘗試同時使用完美編碼的網站。

延展性 是適應增加需求或變更需求的能力。 您的應用程式和服務必須能夠處理大量的工作負載，以因應成長。 可調整的應用程式能夠處理一段時間的擴充要求數目，而不會對可用性或效能產生負面影響。

在此單元中，您將瞭解延展性與可靠性之間的關係、容量規劃在達到延展性方面的重要性，並簡短檢閱一些與調整相關的基本概念和詞彙。

延展性/可靠性關聯性

好消息是，讓您的應用程式更具延展性也可能使其更可靠。 例如，如果您的系統自動調整，若單一虛擬機上的元件發生故障，自動調整服務會部署另一個實例，以符合您的最小虛擬機（VM）數量需求。 您的系統變得更可靠。 在另一個範例中，您使用的是更上層的服務，例如原本就可擴充的 Azure 記憶體。 如果您有儲存體問題，服務會建置為具有可靠性，因此您的資料會複寫。

以下是一個比喻：請想想您經常在大樓外看到的無障礙斜坡，一開始設計是為了配合使用輪椅的人士。 它們服務於這個目的。 但推著嬰兒車的父母、覺得樓梯步階太深或太高的幼兒也會使用這些斜坡。 此用法是 次要優點。

可靠性通常是延展性的次要優點。 如果您將系統設計為可調整，它們可能也會更可靠。

延展性和容量規劃

容量規劃 牽涉到決定您滿足目前和未來需求所需的資源。 您可以藉由分析目前的資源使用量，然後預測未來成長來執行此規劃。

若要估計未來容量需求，您應該考慮下列因素：

• 預期的業務增長
• 定期波動（季節性等）
• 應用程式條件約束
• 識別瓶頸和限制因素

您也需要設定服務等級目標，以便建立容量管理計劃，以在工作負載和環境變更時可靠地符合或超過這些目標。

容量規劃是一個反覆的過程。 當我們進行本課程模組時，您將學習如何繪製應用程式元件的資源需求。

概念和術語

在完全瞭解您在本課程模組中遇到的概念和策略之前，您需要一些與規模相關的基本概念和基礎詞彙的基礎知識。

• 擴展規模：提升元件的容量，以應對更大的工作負載。 也稱為垂直縮放。
• 水平擴展：新增更多元件或資源，將負載分散到分散式架構上。 例如，使用在一組前端後方具有多個後端的簡單架構。 隨著負載增加，我們會新增更多後端 （和前端） 伺服器來處理它。 也稱為水平調整。
• 手動調整：需要人為動作，才能增加資源數量。
• 自動調整：系統會根據負載自動調整資源數量。 明確來說，會根據增加或減少的負載來向上或向下調整數量。
• DIY 調整：自行調整，藉以設定自動調整。
• 內建的擴展能力：設計為可擴展的服務，自動在幕後處理擴展，不需您介入。 從您的觀點來看，它們似乎可以無限擴展，因為您可以直接消耗更多資源，而不需要手動布建資源。

Tailwind Traders 公司架構

在本課程模組中，我們將使用名為Tailwind Traders的虛構硬體公司範例架構。 其電子商務平臺如下所示：

這個圖表乍看之下相當複雜，所以讓我們逐步解說。 該網站設有前端。 如果您前往 tailwindtraders.com，這就是您進行通訊的對象。

前端會與一組後端服務進行互動。 這些後端服務包括一般專案，例如優惠券服務、購物車服務、庫存服務等等。 它們全都在 Azure Kubernetes Service 中執行。 此應用程式還有其他元件和技術可供使用。 您只需要專注於前端和在 Kubernetes 上執行的後端服務。

單一失敗點

既然您已看到整個架構，讓我們花一點時間來檢查單一故障點，以及考慮擴展時需要關注的領域。

已標示後端元件和 SQL 資料庫的應用程式完整架構圖。

所有這些服務都是單一失敗點-它們不是針對復原能力或規模而建置。 如果其中一個被超載，它可能會當機，而且目前無法輕易解決。

在本課程模組稍後，我們將探討設計這些服務的其他方式，以更可調整且更可靠。

預先布建的容量

讓我們看看另一個可能造成麻煩的問題。 以下是需要我們預先布建容量的服務/元件：

例如，使用Cosmos DB 時，我們會預先布建吞吐量。 如果我們超過這些限制，我們會開始將錯誤訊息傳回給客戶。 透過 Azure AI 服務，我們選擇一個層級，而該層級有每秒最大要求數目的限制。 一旦達到上述任一限制，就會對用戶端進行節流。

流量的大量尖峰 (像是啟動新產品) 會讓我們達到這些限制嗎？ 現在，我們不知道。 這件事是我們在本模組中稍後會檢討的另一個事項。

成本

即使我們做正確的事，我們仍然需要規劃增長。 以下是依使用量付費的服務：

在這裡，我們使用 Azure Logic Apps 和 Azure Functions，這兩個都是無伺服器技術的範例。 這些服務會自動調整，而我們會按要求付費。 您的帳單會隨著客戶群的成長而成長。 我們至少應該注意即將推出的事件，例如產品推出可能對我們的雲端支出產生的影響。 我們也致力於瞭解並預測本課程模組稍後的雲端支出。