00 導(dǎo)讀

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

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

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

這對(duì)于一個(gè)"夜黑風(fēng)高" 即將回家的我們多大的傷害。畢竟每一次性能或者可用率的報(bào)警都牽動(dòng)著我們作為技術(shù)的心血管（牽動(dòng)著客戶的投訴…）。

本文將從JSF1.7.6預(yù)熱的實(shí)踐測(cè)試報(bào)告中，真實(shí)的講述預(yù)熱給我們平臺(tái)帶來的體驗(yàn)和幫助，供大家參考。

01 背景

應(yīng)用調(diào)用情況

場(chǎng)景一：對(duì)外服務(wù)，部分接口發(fā)布過程中出現(xiàn)了大量的 5xx 超時(shí)異常，根據(jù)和客戶側(cè)研發(fā)團(tuán)隊(duì)的溝通，大概確定在應(yīng)用啟動(dòng)后的時(shí)間點(diǎn)，會(huì)有部分接口的超時(shí)請(qǐng)求。

場(chǎng)景二：服務(wù)提供者接口發(fā)布，機(jī)器啟動(dòng)后，會(huì)有調(diào)用JSF超時(shí)請(qǐng)求。

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

【補(bǔ)充】這里同步一下檢測(cè)工具：我們?nèi)绾蔚弥舷掠问欠翊嬖诓渴鹗录?。見：泰山平臺(tái)故障分析模塊，可以智能分析出上下游故障，或歷史問題排查。

詳細(xì)地址：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ù)熱管理實(shí)踐

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

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

當(dāng)然新功能的引入，小至工具包升級(jí)，大至基礎(chǔ)服務(wù)升級(jí)，都需要足夠的測(cè)試實(shí)踐和驗(yàn)證回歸，一方面測(cè)試該功能是否符合我們的訴求，另一方面避免直接引入導(dǎo)致的一些未知異常。因此我們通過針對(duì)地址應(yīng)用及自產(chǎn)自銷的JSF接口進(jìn)行測(cè)試實(shí)踐，并形成以下報(bào)告。

機(jī)器配置

共計(jì)5臺(tái)服務(wù)器 規(guī)格：4c8g

四臺(tái)提供者：11.94.2.225,11.94.13.242,11.94.65.31,11.94.65.45

一臺(tái)消費(fèi)者：11.38.181.175

考慮到篇幅的問題，本文主要描述其中一個(gè)接口的上線情況，具體實(shí)踐報(bào)告見：https://joyspace.jd.com/page/LxPqDgcSA3GVjSYQRb73

涉及接口

HTTP接口（消費(fèi)者）：https://bizapi.jd.com/api/area/getTown

JSF接口（提供者）：com.jd.ka.vop.soa.address.sdk.provider.QueryAddressOpenProvider#queryJdAreaIdList

測(cè)試流程

采用壓力機(jī)，模擬調(diào)用對(duì)應(yīng)接口，流量穩(wěn)定后，模擬上線流程，按照50%的比例發(fā)布兩臺(tái)機(jī)器進(jìn)行測(cè)試。

未設(shè)置預(yù)熱管理

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

提供者監(jiān)控

消費(fèi)者監(jiān)控

未設(shè)置預(yù)熱發(fā)布上線

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

提供者監(jiān)控

消費(fèi)者監(jiān)控

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

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

設(shè)置預(yù)熱管理（流程同未設(shè)置預(yù)熱情況）

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

補(bǔ)充：

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

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

因此調(diào)整配置策略：預(yù)熱權(quán)重1，周期60000ms。以此降低初始權(quán)重，增大預(yù)熱周期。

設(shè)置預(yù)熱發(fā)布上線

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

提供者監(jiān)控

效果十分明顯，如下：

03 總結(jié)

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

故，經(jīng)過評(píng)估：provider冷啟動(dòng)后的瞬時(shí)TP耗時(shí)高，調(diào)用波動(dòng)大進(jìn)而導(dǎo)致請(qǐng)求有損的問題，可以通過自動(dòng)預(yù)熱機(jī)制解決。

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