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