一 背景

C端服務應用升級和重啟，導致耗時瞬時抖動，業務超時，應用監控報警，上游感知明顯，導致用戶體驗變差。

二 應用升級重啟導致抖動的原因

1 C端服務應用升級和重啟的冷啟動階段，它需要重新載入和初始化各種資源，例如資料庫連接、緩存數據等，導致耗時瞬時飆升。

2 應用重啟後，本地緩存失效，應用需要重新載入數據，導致耗時變長。

3 應用重啟後，有大量請求堆積，導致系統負載增加，線程處理不及時，導致系統響應變慢。

三 解決方案

1 停服時，先下線JSF介面，再升級應用，待應用啟動成功後，JSF服務介面延遲註冊到註冊中心。

2 JSF開啟預熱功能，是服務提供者重啟後，JSF上線後，消費者與服務者建立鏈接後，調用方客戶端先放設置比例的小部分流量過來到升級重啟的實例，在預熱周期內，逐步到100%

3 在應用升級流程編排中，結合流量回放，編排流程，在流量回放後再操作JSF上線，實現略複雜，依賴基礎運維

方案1，方案2實現簡單，預熱效果也比較好，使用的是JSF的預熱功能，以下效果對比的實現來自方案2的JSF預熱功能。

四 採用JSF開啟預熱功能效果對比

1 服務提供者配置預熱周期

預熱初始權重：consumer連接到provider後，provider的初始權重（provider端權重會在預熱周期內會逐漸恢復到正常權重，一般是100）

2 未開啟預熱容器實例整體升級重啟監控：

應用部署在3個機房，所以看到3次抖動，可以看到TP999最高的機房達到了近25s。

開啟預熱後整體實例升級重啟效果：

應用部署在3個機房，所以看到3次抖動，可以看到TP999最高的機房降到了2.5s，降幅達10倍。

3 未開啟預熱，單實例應用重啟監控

max達到了20s,TP999到達了18s

開啟預熱後，單實例應用重啟監控

max降到了2s,TP999將到了1.5s左右，降幅達10倍，TPS在配置的預熱周期內（60s）呈現線性增長

五 註意事項

依賴服務調用方升級JSF到1.7.6版本及以上，推動所有調用方升級JSF

可根據應用的啟動時間和特性，調整應用匹配的預熱周期，達到相對預熱效果最好的狀態。至於是否有必要結合流量回放和流程編排實現預熱，需結合自己的業務情況和實現成本考慮。

作者：京東科技 張石磊

來源：京東雲開發者社區 轉載請註明來源