設計以符合容量需求
 提供足夠的供應，以解決預期的需求。 |
|---|
請務必主動測量效能。 測量效能牽涉到測量基準，並初步了解系統哪些元件可能會帶來挑戰。 您可以達成此目的，而不需進行完整的效能測試，或透過細微的優化。 藉由採取這些初始步驟，您可以在開發生命週期早期建立有效的效能管理基礎。
檢查整個系統，而不是專注於個別元件。 避免在這個階段微調。 進行細微的效能改善會導致其他領域的取捨。 當您在生命週期中進行並開始接受測試或移至生產環境時，您可以快速識別哪些區域需要進一步優化。
範例案例
Contoso Manufacturing 已開發內部使用的 Java Spring 型微服務應用程式，用來監視和優化其製造程式。 工作負載小組正在將目前裝載於內部部署的應用程式移轉至 Azure 的程式。
Azure 裝載的應用程式會建置在 Azure Spring Apps、適用於 MySQL 的 Azure 資料庫 和 Azure IoT 中樞 上。 Contoso 具有與 Azure 的 ExpressRoute 連線。
有效地設計工作負載
跨技術堆疊選擇正確的資源，讓您符合效能目標，並與系統整合。 請考慮可滿足延展性需求的功能，並找出資源配置與系統需求之間的適當平衡，以有效率地處理非預期的激增。
藉由分析資源的不同功能，您可以確定每個元件都有助於系統的整體功能和效能，而且您可以識別您可以利用的調整功能。
適當重設大小的資源可以滿足需求變更，而不需要過度布建，進而節省成本。
Contoso 的挑戰
- 現有的內部部署應用程式環境基礎結構完全由 Contoso 管理，這對小組造成重大負擔。 它們目前會布建和維護伺服器、網路和記憶體，以及設定及更新 Java Spring 服務運行時間和所有相依性。
- 小組期待著使用 Azure Spring Apps 移轉至 PaaS 模型，這可讓小組更專注於確保應用程式提供預期的商業價值，並投入較少的時間來管理基礎結構。
- 此應用程式對於 Contoso 的業務至關重要，而且具有嚴格的效能需求，因此他們需要確定他們在移轉過程中所做的技術選擇，才能符合這些需求。
套用方法和結果
- 比較可用的不同方案之後，小組會選擇 Azure Spring Apps Standard 方案，此方案為 Spring Boot 應用程式提供完全受控的服務，並針對生產流量優化。 每個應用程式最多 500 個實例，標準方案就能夠提供足夠的計算容量，以達到預期使用量上限。
- 此外，服務也可以設定為視需要相應放大，並在不需要額外的容量時相應縮小計算資源。
- 小組查看了 Enterprise 方案，每個應用程式可相應增加至 1000 個實例，但決定目前不需要該容量。 他們也確信他們不需要企業方案供應專案的支援層級，或其專屬功能的其餘部分。
正確預測容量需求
根據需求和所選資源的功能進行容量規劃，以擴充效能模型。 使用預測模型化技術來預測可預測和非預期變更可能發生的容量變更。 定義可轉譯成技術需求的效能目標。
藉由採用這種方法，您可以有效率地使用資源並滿足需求，而不需要過度布建，從而避免不必要的成本。 此外，它可協助您了解設計選擇如何影響效能。
Contoso 的挑戰
- 為了最大限度地有效使用生產機械，Contoso 的生產線會按照週期性排程運作，在一天的不同時間生產不同的產品。
- 每個產品都需要不同的作業，因此與控制應用程式需要不同的計算需求。 在產品之間的轉換期間，控制應用程式必須執行需要增加計算容量的各種工作，例如分析先前生產執行中的數據，以及更新機器的控制演算法。
套用方法和結果
- 為了在變更期間滿足較高的需求，小組會先識別處理轉換功能的流程、記錄其效能需求，以及根據應用程式的內部部署版本來估計其交易量。 有了這項數據，小組會繼續評估屬於目標流程之微服務所需的計算容量。
- 自動調整已針對這些元件設定，以確保在切換期間之前布建其他資源，並在工作完成之後釋放。
- 自動調整設定將會在將應用程式部署到生產環境之前，根據新環境中的實際效能進行調整。
概念證明部署
實作概念證明（POC），以驗證技術需求和設計選擇。
概念證明有助於驗證設計，以判斷系統是否可以符合效能目標，以及這些目標是否現實。 根據預期的負載，您可以驗證預期的容量是否符合效能目標。
此外，請確認設計選擇的成本影響。
Contoso 的挑戰
- 在開發期間，小組會使用裝置模擬器執行應用程式功能的廣泛負載和效能測試，並使用這項資訊來優化自動調整設定。
- 可能會影響自動調整組態有效性的一個層面是，從 Azure Spring Apps 環境到製造樓層的 IoT 裝置進行潛在的網路等待時間通訊，該裝置會透過 ExpressRoute 連線到 Azure。 小組推測 Azure 中的延遲會高於應用程式的內部部署版本，而且延遲也可能受到其他因素的影響，例如一天的時間或裝置位置。
- 延遲增加可能會對每個微服務實例能夠處理的交易量造成影響。
套用方法和結果
- 小組決定將POC部署至 Azure，以驗證其假設，並收集可用來優化設定的計量。 他們會建置測試 Azure Spring App，以與散佈在製造樓層的 IoT 裝置通訊。 IoT 裝置會連線到內部部署網路，且會向 Azure IoT 中樞 註冊。 測試應用程式會透過傳送簡單的 Ping 來隨機連線到裝置，並記錄接收回應所需的時間。
- 此 POC 期間所擷取的數據，加上負載測試的結果，可讓小組更準確地估計所需的計算容量，因為他們為初始生產環境啟動做準備。
- 小組也會研究如何進一步改善用於負載測試的測試案例，以根據POC的學習來模擬更真實的響應時間。