作者：京東零售 李孟東
00 導讀
企業前臺研發部包含了企業業務大部分的對外前臺系統，其中京東VOP平臺(開放平臺)適合於自建內網採購商城平臺的企業客戶。
京東為這類客戶專門開發API介面，對接到客戶內網的網上商城，將產品SKU直接推送到客戶內網，客戶內部採購人員可以直接在內網商城進行下單採購，訂單資訊透過API介面傳遞到京東後臺，由京東安排物流配送服務。VOP模式下，客戶內網的資料資訊京東並不抓取，從而實現內部採購架構的獨立搭建及資料的保密與安全。
隨著業務的不斷髮展過程中，VOP截至目前已經服務於上千家企業Sass商城，其API介面的高併發、高可用、高可靠也就越發的重要。儘管我們如履薄冰的進行上線來儘可能的降低對介面的波動，但是發現，當下我們整個的上線流程中無損下線是沒問題（NP層冷備機器直至無流量打進來，JSF層下線JSF服務），但是（自身&服務提供方）上線的瞬時波動都會或多或少引起我們系統的一陣報警。
這對於一個"夜黑風高" 即將回家的我們多大的傷害。畢竟每一次效能或者可用率的報警都牽動著我們作為技術的心血管（牽動著客戶的投訴...）。
本文將從JSF1.7.6預熱的實踐測試報告中，真實的講述預熱給我們平臺帶來的體驗和幫助，供大家參考。
01 背景
應用呼叫情況
場景一：對外服務，部分介面釋出過程中出現了大量的 5xx 超時異常，根據和客戶側研發團隊的溝通，大概確定在應用啟動後的時間點，會有部分介面的超時請求。
場景二：服務提供者介面釋出，機器啟動後，會有呼叫JSF超時請求。
以上兩種情況都會影響到服務的穩定性，進而引起我們系統的一陣（TP99/可用率）報警，如下所示：
【補充】這裡同步一下檢測工具：我們如何得知上下游是否存在部署事件。見：泰山平臺故障分析模組，可以智慧分析出上下游故障，或歷史問題排查。
詳細地址：
http://taishan.jd.com/faultAnalysis
幫助文件：
https://cf.jd.com/pages/viewpage.action?pageId=491274317
透過故障分析，我們發現我們所依賴的介面系統正在處於部署狀態，也就是說其上線釋出影響到了我們介面的穩定性。
02 預熱管理實踐
問題是顯而易見的，那麼如何發現問題本質，並找到問題通用性，進而解決問題，推廣各平臺，最終達到良性迴圈，是我們著重需要考慮的。
解決思路：JSF1.7.6版本特性三：預熱策略動態下發，提升Provider實時治理能力透過伺服器其負載均衡的能力，對於上線需要預熱的介面進行流量權重的調整，做到剛上線的應用按照對應所配置的規則進行小流量預熱，使用方只需指定預熱規則即可按照預期對剛上線的節點進行小流量預熱。
當然新功能的引入，小至工具包升級，大至基礎服務升級，都需要足夠的測試實踐和驗證迴歸，一方面測試該功能是否符合我們的訴求，另一方面避免直接引入導致的一些未知異常。因此我們透過針對地址應用及自產自銷的JSF介面進行測試實踐，並形成以下報告。
機器配置
共計5臺伺服器 規格：4c8g
四臺提供者：11.94.2.225,11.94.13.242,11.94.65.31,11.94.65.45
一臺消費者：11.38.181.175
考慮到篇幅的問題，本文主要描述其中一個介面的上線情況，具體實踐報告見：
https://joyspace.jd.com/page/LxPqDgcSA3GVjSYQRb73
涉及介面
HTTP介面（消費者）：
https://bizapi.jd.com/api/area/getTown
JSF介面（提供者）：
com.jd.ka.vop.soa.address.sdk.provider.QueryAddressOpenProvider#queryJdAreaIdList
測試流程
採用壓力機，模擬呼叫對應介面，流量穩定後，模擬上線流程，按照50%的比例釋出兩臺機器進行測試。
未設定預熱管理
如下為流量穩定呼叫的UMP監控：
提供者監控
消費者監控
未設定預熱釋出上線
釋出週期（15:40——15:44）釋出機器比例50%
提供者監控
消費者監控
透過上方監控圖，我們可以清晰的看出：
- 無損下線過程符合預期，並且下線過程中並沒有出現任何報錯。
- 報錯和效能下降期間處於服務端應用成功啟動後且註冊成功後。
設定預熱管理（流程同未設定預熱情況）
配置地址：
http://taishan.jd.com/jsf/protection/index
補充：
- 權重和週期指的是初始權重到目標權重100，在預熱週期內線性增長，流量在新節點逐漸增長的過程。（即：小流量預熱）
- 在泰山流量防護頁面中新增的介面配置，必須是擁有該介面許可權才可以直接進行配置。
- 在泰山平臺配置後，則直接面向所有消費者有效。當然也可以使用JSF的標籤配置進行預熱，就僅對自身伺服器有效。
- 預熱週期最大2min
這裡有個小插曲，最初我設定的權重為：預熱權重：10 週期：30000ms，但是在測試結果中發現，效果並不明顯，如下：
因此調整配置策略：預熱權重1，週期60000ms。以此降低初始權重，增大預熱週期。
設定預熱釋出上線
釋出週期（17:36——17:40）釋出機器比例50%
提供者監控
效果十分明顯，如下：
03 總結
綜上，效能波動影響，從直接釋出的50%佔比機器上看，配置預熱後，其中一臺影響下降了2.8——15倍左右；另一臺機器上線效能波動幾乎可以忽略（16ms）。（測試介面本身效能queryJdAreaIdList TP99 11ms左右）
故，經過評估：provider冷啟動後的瞬時TP耗時高，呼叫波動大進而導致請求有損的問題，可以透過自動預熱機制解決。
當然，根據目前行業的一些解決方案，無損上線功能遠不止於此，期待JSF預熱功能的能力與場景不斷地大家的實踐反饋中逐漸完善與豐富。