當您的應用在進行擴容、部署新版本或預期流量突增時，可以使用ASM慢啟動預熱功能，在自訂的時間視窗內逐步增加請求流量，從而平穩過渡，降低因瞬間壓力過高導致的服務中斷、請求逾時及潛在的資料丟失風險，確保應用在伸縮和更新過程中的效能穩定性和高可用性。
前提條件
已建立ASM企業版或者旗艦版執行個體，且版本為1.14.3及以上。具體操作，請參見建立ASM執行個體。
已添加叢集到ASM執行個體。具體操作，請參見添加叢集到ASM執行個體。
通過kubectl串連ACK叢集。具體操作，請參見擷取叢集KubeConfig並通過kubectl工具串連叢集。
已建立ASM網關。具體操作，請參見建立入口網關服務。
已部署樣本應用Bookinfo。本文以Reviews服務為例，具體操作，請參見在ASM執行個體關聯的叢集中部署應用。
背景資訊
在未啟用慢啟動預熱功能時，每當新目標Pod加入時，請求方都會向該Pod發送一定比例的流量，不支援新Pod的漸進式流量增加。這對於需要一些預熱時間來提供全部負載的服務可能是不可取的，並且可能會導致請求逾時、資料丟失和使用者體驗惡化。例如在基於JVM的Web應用程式中，這些應用程式使用水平Pod自動縮放。當服務剛啟動時，它會被大量請求淹沒，這會導致應用程式預熱時持續逾時。因此，每次擴充服務時，都會遺失資料或者會導致這部分請求的回應時間增加。預熱的基本思想就是讓剛啟動的機器逐步接入流量。
慢啟動預熱功能介紹
慢啟動模式又稱漸進式流量增加，使用者可以為服務配置一個時間段，每當一個服務執行個體啟動時，請求方會向該執行個體發送一部分請求負載，並在配置的時間段內逐步增加請求量。當慢啟動視窗期間到達，就會退出慢啟動模式。
在慢啟動模式下，添加新的目標服務Pod時，避免新增Pod被大量請求擊垮，這些新目標服務可以根據指定的加速期在接受其均衡策略的請求之前進行預熱。
慢啟動對於依賴緩衝並且需要預熱期才能以最佳效能響應請求的應用程式非常有用。在ASM下，您只需在服務對應的DestinationRule下的配置trafficPolicy/loadBalancer即可，需要注意的是：
loadBalancer：表示負載平衡器資訊。類型限定於ROUND_ROBIN和LEAST_REQUEST負載平衡器。
warmupDurationSecs：表示Service的預熱期間。如果設定，則新建立的服務端點在此視窗期間從其建立時間開始保持預熱模式，並且Istio逐漸增加該端點的流量，而不是發送成比例的流量。
慢啟動要求應用當前副本數不小於2。例如：原本有2個副本，啟動第三個時，慢啟動會生效。如果當前只有1個副本，新啟動1個副本，慢啟動不會生效。
DestinationRule的YAML樣本如下：
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mocka
spec:
host: mocka
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
warmupDurationSecs: 100s步驟一：配置路由規則並訪問入口網關
為方便示範，本文先將Reviews的v3版本的Deployment副本數調整為0，即在Kubernetes叢集中將名為reviews-v3的Deployment部署的副本數縮容為0。
定義訪問入口。
使用以下內容，建立bookinfo-gateway.yaml檔案。
執行以下命令，部署bookinfo-gateway。
kubectl apply -f bookinfo-gateway.yaml
建立Reviews服務。
使用以下內容，建立reviews.yaml檔案。
執行以下命令，部署Reviews。
kubectl apply -f reviews.yaml
開啟網格拓撲， 持續訪問入口網關地址。
本文以通過hey命令發送壓測請求10s為例。關於hey命令的下載和安裝，請參見hey；關於開啟和查看網格拓撲的具體操作，請參見查看應用的網格拓撲。
hey -z 10s -q 100 -c 4 http://${網關地址}/reviews/0調用拓撲樣本圖如下：
步驟二：通過可觀測資料查看Pod啟動
登入ASM控制台。
在左側導覽列，選擇。
在網格管理頁面，找到待配置的執行個體，單擊執行個體的名稱或在操作列中單擊管理。
在左側導覽列單擊。
ASM執行個體版本為1.17.2.35以下：在監控指標頁面，單擊監控儀錶頁簽，然後單擊網格服務等級監控頁簽，選擇對應的Reviews服務。
ASM執行個體版本為1.17.2.35及以上：在監控指標頁面，單擊網格工作負載層級監控頁簽，選擇對應的reviews-v3工作負載，選擇Reporter為source。
發送壓測請求並觀察監控資料。
在未開啟預熱功能的情況下，在Kubernetes叢集中將名為reviews-v3的Deployment部署的副本數從0擴容為1。
執行以下命令，發送壓測請求入口網關。
本文以發送壓測請求120s為例。
hey -z 120s -q 100 -c 4 http://${網關地址}/reviews/0觀察Prometheus監控的儀錶盤資料。
大約需要45s左右，reviews-v3 Pod將接收均衡的請求（具體時間會跟實際壓測環境有關）。
在Kubernetes叢集中將名為reviews-v3的Deployment部署的副本數縮容為0。
步驟三：啟用預熱功能
使用以下內容，更新reviews.yaml檔案。
增加
warmupDurationSecs欄位，配置為120s，即定義預熱期間為120s。apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: ROUND_ROBIN warmupDurationSecs: 120s執行以下命令，更新Reviews。
kubectl apply -f reviews.yaml
步驟四：查看預熱效果
開啟預熱功能後，在Kubernetes叢集中將名為reviews-v3的Deployment部署的副本數從0擴容為1。
執行以下命令，發送壓測請求入口網關。
本文以發送壓測請求150s為例。
hey -z 150s -q 100 -c 4 http://${網關地址}/reviews/0在網格服務等級監控頁簽中，觀察Prometheus監控的儀錶盤資料。
大概需要120s左右，reviews-v3 Pod將接收均衡的請求（具體時間會跟實際壓測環境有關）。
由於Metrics的採集時間間隔限制，這條曲線並不平滑。實際上，到達reviews-v3 pod的流量是平滑增長的，如果您開啟了Sidecar日誌採集，可以在SLS中搜尋這個Sidecar對應的日誌，可以看到近5分鐘的日誌量。
在啟用預熱功能的情況下，每當一個服務執行個體啟動時，請求方會向該執行個體發送一部分請求負載，並在配置的時間段內逐步增加請求量。當慢啟動視窗期間到達，就會退出慢啟動模式。啟用預熱功能之後，需要2分30秒左右，流量將均衡地分布到v1、v2、v3版本。
相關文檔
您可以配置本地限流或全域限流，將流量維持在可控的閾值內，確保服務持續可用並維持效能穩定。具體操作，請參見在流量管理中心配置本地限流和使用ASMGlobalRateLimiter對應用服務入口流量配置全域限流。
您可以使用ASMAdaptiveConcurrency實現自適應並發控制，根據採樣的請求資料動態調整允許的並發的數量，當並發數量超過服務可承受範圍時拒絕請求，達到保護服務的目的。具體操作，請參見使用ASMAdaptiveConcurrency實現自適應並發控制。
您可以配置串連池實現熔斷功能，在系統出現故障或超負荷的情況下，保護系統免受進一步的損害。具體操作，請參見配置串連池實現熔斷功能。