00 導(dǎo)讀
企業(yè)前臺研發(fā)部包含了企業(yè)業(yè)務(wù)大部分的對外前臺系統(tǒng)，其中京東VOP平臺(開放平臺)適合于自建內(nèi)網(wǎng)采購商城平臺的企業(yè)客戶。
京東為這類客戶專門開發(fā)API接口，對接到客戶內(nèi)網(wǎng)的網(wǎng)上商城，將產(chǎn)品SKU直接推送到客戶內(nèi)網(wǎng)，客戶內(nèi)部采購人員可以直接在內(nèi)網(wǎng)商城進行下單采購，訂單信息通過API接口傳遞到京東后臺，由京東安排物流配送服務(wù)。VOP模式下，客戶內(nèi)網(wǎng)的數(shù)據(jù)信息京東并不抓取，從而實現(xiàn)內(nèi)部采購架構(gòu)的獨立搭建及數(shù)據(jù)的保密與安全。
隨著業(yè)務(wù)的不斷發(fā)展過程中，VOP截至目前已經(jīng)服務(wù)于上千家企業(yè)Sass商城，其API接口的高并發(fā)、高可用、高可靠也就越發(fā)的重要。盡管我們?nèi)缏谋”倪M行上線來盡可能的降低對接口的波動，但是發(fā)現(xiàn)，當(dāng)下我們整個的上線流程中無損下線是沒問題（NP層冷備機器直至無流量打進來，JSF層下線JSF服務(wù)），但是（自身&服務(wù)提供方）上線的瞬時波動都會或多或少引起我們系統(tǒng)的一陣報警。
這對于一個"夜黑風(fēng)高" 即將回家的我們多大的傷害。畢竟每一次性能或者可用率的報警都牽動著我們作為技術(shù)的心血管（牽動著客戶的投訴…）。
本文將從JSF1.7.6預(yù)熱的實踐測試報告中，真實的講述預(yù)熱給我們平臺帶來的體驗和幫助，供大家參考。
01 背景
應(yīng)用調(diào)用情況
場景一：對外服務(wù)，部分接口發(fā)布過程中出現(xiàn)了大量的 5xx 超時異常，根據(jù)和客戶側(cè)研發(fā)團隊的溝通，大概確定在應(yīng)用啟動后的時間點，會有部分接口的超時請求。
場景二：服務(wù)提供者接口發(fā)布，機器啟動后，會有調(diào)用JSF超時請求。
以上兩種情況都會影響到服務(wù)的穩(wěn)定性，進而引起我們系統(tǒng)的一陣（TP99/可用率）報警，如下所示：
【補充】這里同步一下檢測工具：我們?nèi)绾蔚弥舷掠问欠翊嬖诓渴鹗录Ｒ姡禾┥狡脚_故障分析模塊，可以智能分析出上下游故障，或歷史問題排查。
詳細地址：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 預(yù)熱管理實踐
問題是顯而易見的，那么如何發(fā)現(xiàn)問題本質(zhì)，并找到問題通用性，進而解決問題，推廣各平臺，最終達到良性循環(huán)，是我們著重需要考慮的。
解決思路：JSF1.7.6版本特性三：預(yù)熱策略動態(tài)下發(fā)，提升Provider實時治理能力 通過服務(wù)器其負(fù)載均衡的能力，對于上線需要預(yù)熱的接口進行流量權(quán)重的調(diào)整，做到剛上線的應(yīng)用按照對應(yīng)所配置的規(guī)則進行小流量預(yù)熱，使用方只需指定預(yù)熱規(guī)則即可按照預(yù)期對剛上線的節(jié)點進行小流量預(yù)熱。
當(dāng)然新功能的引入，小至工具包升級，大至基礎(chǔ)服務(wù)升級，都需要足夠的測試實踐和驗證回歸，一方面測試該功能是否符合我們的訴求，另一方面避免直接引入導(dǎo)致的一些未知異常。因此我們通過針對地址應(yīng)用及自產(chǎn)自銷的JSF接口進行測試實踐，并形成以下報告。
機器配置
共計5臺服務(wù)器 規(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
測試流程
采用壓力機，模擬調(diào)用對應(yīng)接口，流量穩(wěn)定后，模擬上線流程，按照50%的比例發(fā)布兩臺機器進行測試。
未設(shè)置預(yù)熱管理
如下為流量穩(wěn)定調(diào)用的UMP監(jiān)控：
提供者監(jiān)控
消費者監(jiān)控
未設(shè)置預(yù)熱發(fā)布上線
發(fā)布周期（15:40——15:44）發(fā)布機器比例50%
提供者監(jiān)控
消費者監(jiān)控
通過上方監(jiān)控圖，我們可以清晰的看出：
- 無損下線過程符合預(yù)期，并且下線過程中并沒有出現(xiàn)任何報錯。
- 報錯和性能下降期間處于服務(wù)端應(yīng)用成功啟動后且注冊成功后。
設(shè)置預(yù)熱管理（流程同未設(shè)置預(yù)熱情況）
配置地址：http://taishan.jd.com/jsf/protection/index
補充：
- 權(quán)重和周期指的是初始權(quán)重到目標(biāo)權(quán)重100，在預(yù)熱周期內(nèi)線性增長，流量在新節(jié)點逐漸增長的過程。（即：小流量預(yù)熱）
- 在泰山流量防護頁面中新增的接口配置，必須是擁有該接口權(quán)限才可以直接進行配置。
- 在泰山平臺配置后，則直接面向所有消費者有效。當(dāng)然也可以使用JSF的標(biāo)簽配置進行預(yù)熱，就僅對自身服務(wù)器有效。
- 預(yù)熱周期最大2min
這里有個小插曲，最初我設(shè)置的權(quán)重為：預(yù)熱權(quán)重：10 周期：30000ms ，但是在測試結(jié)果中發(fā)現(xiàn)，效果并不明顯，如下：
因此調(diào)整配置策略：預(yù)熱權(quán)重1，周期60000ms。以此降低初始權(quán)重，增大預(yù)熱周期。
設(shè)置預(yù)熱發(fā)布上線
發(fā)布周期（17:36——17:40）發(fā)布機器比例50%
提供者監(jiān)控
效果十分明顯，如下：
03 總結(jié)
綜上，性能波動影響，從直接發(fā)布的50%占比機器上看，配置預(yù)熱后，其中一臺影響下降了2.8——15倍左右；另一臺機器上線性能波動幾乎可以忽略（16ms）。（測試接口本身性能queryJdAreaIdList TP99 11ms左右）
故，經(jīng)過評估：provider冷啟動后的瞬時TP耗時高，調(diào)用波動大進而導(dǎo)致請求有損的問題，可以通過自動預(yù)熱機制解決。
當(dāng)然，根據(jù)目前行業(yè)的一些解決方案，無損上線功能遠不止于此，期待JSF預(yù)熱功能的能力與場景不斷地大家的實踐反饋中逐漸完善與豐富。
]]>