00 導讀

企業(yè)前臺研發(fā)部包含了企業(yè)業(yè)務大部分的對外前臺系統(tǒng)，其中京東VOP平臺(開放平臺)適合于自建內網采購商城平臺的企業(yè)客戶。

京東為這類客戶專門開發(fā)API接口，對接到客戶內網的網上商城，將產品SKU直接推送到客戶內網，客戶內部采購人員可以直接在內網商城進行下單采購，訂單信息通過API接口傳遞到京東后臺，由京東安排物流配送服務。VOP模式下，客戶內網的數據信息京東并不抓取，從而實現(xiàn)內部采購架構的獨立搭建及數據的保密與安全。

隨著業(yè)務的不斷發(fā)展過程中，VOP截至目前已經服務于上千家企業(yè)Sass商城，其API接口的高并發(fā)、高可用、高可靠也就越發(fā)的重要。盡管我們如履薄冰的進行上線來盡可能的降低對接口的波動，但是發(fā)現(xiàn)，當下我們整個的上線流程中無損下線是沒問題（NP層冷備機器直至無流量打進來，JSF層下線JSF服務），但是（自身&服務提供方）上線的瞬時波動都會或多或少引起我們系統(tǒng)的一陣報警。

這對于一個"夜黑風高" 即將回家的我們多大的傷害。畢竟每一次性能或者可用率的報警都牽動著我們作為技術的心血管（牽動著客戶的投訴…）。

本文將從JSF1.7.6預熱的實踐測試報告中，真實的講述預熱給我們平臺帶來的體驗和幫助，供大家參考。

01 背景

應用調用情況

場景一：對外服務，部分接口發(fā)布過程中出現(xiàn)了大量的 5xx 超時異常，根據和客戶側研發(fā)團隊的溝通，大概確定在應用啟動后的時間點，會有部分接口的超時請求。

場景二：服務提供者接口發(fā)布，機器啟動后，會有調用JSF超時請求。

以上兩種情況都會影響到服務的穩(wěn)定性，進而引起我們系統(tǒng)的一陣（TP99/可用率）報警，如下所示：

【補充】這里同步一下檢測工具：我們如何得知上下游是否存在部署事件。見：泰山平臺故障分析模塊，可以智能分析出上下游故障，或歷史問題排查。

詳細地址：http://taishan.jd.com/faultAnalysis

幫助文檔：https://cf.jd.com/pages/viewpage.action?pageId=491274317

通過故障分析，我們發(fā)現(xiàn)我們所依賴的接口系統(tǒng)正在處于部署狀態(tài)，也就是說其上線發(fā)布影響到了我們接口的穩(wěn)定性。

02 預熱管理實踐

問題是顯而易見的，那么如何發(fā)現(xiàn)問題本質，并找到問題通用性，進而解決問題，推廣各平臺，最終達到良性循環(huán)，是我們著重需要考慮的。

解決思路：JSF1.7.6版本特性三：預熱策略動態(tài)下發(fā)，提升Provider實時治理能力 通過服務器其負載均衡的能力，對于上線需要預熱的接口進行流量權重的調整，做到剛上線的應用按照對應所配置的規(guī)則進行小流量預熱，使用方只需指定預熱規(guī)則即可按照預期對剛上線的節(jié)點進行小流量預熱。

當然新功能的引入，小至工具包升級，大至基礎服務升級，都需要足夠的測試實踐和驗證回歸，一方面測試該功能是否符合我們的訴求，另一方面避免直接引入導致的一些未知異常。因此我們通過針對地址應用及自產自銷的JSF接口進行測試實踐，并形成以下報告。

機器配置

共計5臺服務器 規(guī)格：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

測試流程

采用壓力機，模擬調用對應接口，流量穩(wěn)定后，模擬上線流程，按照50%的比例發(fā)布兩臺機器進行測試。

未設置預熱管理

如下為流量穩(wěn)定調用的UMP監(jiān)控：

提供者監(jiān)控

消費者監(jiān)控

未設置預熱發(fā)布上線

發(fā)布周期（15:40——15:44）發(fā)布機器比例50%

提供者監(jiān)控

消費者監(jiān)控

通過上方監(jiān)控圖，我們可以清晰的看出：

• 無損下線過程符合預期，并且下線過程中并沒有出現(xiàn)任何報錯。
• 報錯和性能下降期間處于服務端應用成功啟動后且注冊成功后。

設置預熱管理（流程同未設置預熱情況）

配置地址：http://taishan.jd.com/jsf/protection/index

補充：

• 權重和周期指的是初始權重到目標權重100，在預熱周期內線性增長，流量在新節(jié)點逐漸增長的過程。（即：小流量預熱）
• 在泰山流量防護頁面中新增的接口配置，必須是擁有該接口權限才可以直接進行配置。
• 在泰山平臺配置后，則直接面向所有消費者有效。當然也可以使用JSF的標簽配置進行預熱，就僅對自身服務器有效。
• 預熱周期最大2min

這里有個小插曲，最初我設置的權重為：預熱權重：10 周期：30000ms ，但是在測試結果中發(fā)現(xiàn)，效果并不明顯，如下：

因此調整配置策略：預熱權重1，周期60000ms。以此降低初始權重，增大預熱周期。

設置預熱發(fā)布上線

發(fā)布周期（17:36——17:40）發(fā)布機器比例50%

提供者監(jiān)控

效果十分明顯，如下：

03 總結

綜上，性能波動影響，從直接發(fā)布的50%占比機器上看，配置預熱后，其中一臺影響下降了2.8——15倍左右；另一臺機器上線性能波動幾乎可以忽略（16ms）。（測試接口本身性能queryJdAreaIdList TP99 11ms左右）

故，經過評估：provider冷啟動后的瞬時TP耗時高，調用波動大進而導致請求有損的問題，可以通過自動預熱機制解決。

當然，根據目前行業(yè)的一些解決方案，無損上線功能遠不止于此，期待JSF預熱功能的能力與場景不斷地大家的實踐反饋中逐漸完善與豐富。