作者：陳保安，2011年加入京東，目前主要負(fù)責(zé)手機(jī)京東核心業(yè)務(wù)（搜索、商品、購物車、結(jié)算、收銀臺(tái)、我的京東）的后端研發(fā)工作。帶領(lǐng)團(tuán)隊(duì)在一線奮戰(zhàn)多年，積累了非常豐富的大促備戰(zhàn)經(jīng)驗(yàn)，也見證了核心系統(tǒng)從一分鐘幾千單到幾十萬單的質(zhì)的蛻變。
京東手機(jī)單品頁在每次大促時(shí)承載所有流量的入口，它被天然賦予的一個(gè)標(biāo)簽就是抗壓，對(duì)系統(tǒng)的穩(wěn)定性、性能方面要求極其苛刻，另外單品頁本身業(yè)務(wù)復(fù)雜度較高，單品頁有幾十種垂直流程業(yè)務(wù)，并且展示上都要求個(gè)性化的單品頁，加上依賴有50+的基礎(chǔ)服務(wù)，稍有抖動(dòng)，對(duì)整體服務(wù)質(zhì)量都會(huì)有比較大的影響，因此之前大促也出現(xiàn)過各種問題，不斷打磨，持續(xù)優(yōu)化升級(jí)，當(dāng)前系統(tǒng)架構(gòu)可支撐接近百萬的QPS瞬時(shí)訪問，并且今年雙11表現(xiàn)非常平穩(wěn)，借此機(jī)會(huì)一塊和大家做一次分享。
一、先聊聊APP接口開發(fā)的特點(diǎn)
手機(jī)單品頁提供給APP的API受限于運(yùn)營商的網(wǎng)絡(luò)，手機(jī)的信號(hào)時(shí)有時(shí)無、時(shí)好時(shí)壞極其不穩(wěn)定，為了減少客戶端和后端建連握手的過程，因此接口下發(fā)內(nèi)容大而全，涵蓋了頁面上的所有內(nèi)容，沒辦法像瀏覽器BS的結(jié)構(gòu)可以有大量的ajax請(qǐng)求；
API接口依賴了幾十個(gè)基礎(chǔ)服務(wù)，任何接口的抖動(dòng)對(duì)整體接口性能影響很大，因此必須是并發(fā)請(qǐng)求依賴，減少接口抖動(dòng)疊加的影響；
單品頁有大量的圖片信息，商品主圖、插圖、推薦商品、手機(jī)配件商品、排行榜等等圖片信息量比較大，單個(gè)圖片的大小對(duì)手機(jī)流量影響較大，所有下發(fā)的圖片采用是webp格式，極大減少網(wǎng)絡(luò)傳輸流量。
不同環(huán)境下用戶的體驗(yàn)存在差異，比如在弱網(wǎng)、低版本、分辨率差的手機(jī)會(huì)保持最基本的購物車流程，會(huì)減少一些增值的體驗(yàn)；
圖片的展示尺寸也會(huì)根據(jù)網(wǎng)絡(luò)環(huán)境、分辨率大小進(jìn)行適配。
新業(yè)務(wù)需求變更盡可能兼容老版本，但有些業(yè)務(wù)很難兼容老版本，因此系統(tǒng)里面存在很多版本適配的邏輯，增加了系統(tǒng)的復(fù)雜度；
客戶端如果出現(xiàn)重大bug并且沒辦法進(jìn)行hotfix的情況下，需要服務(wù)端針對(duì)特定版本進(jìn)行打補(bǔ)丁，也增加代碼復(fù)雜度以及后期的維護(hù)成本。
因此APP的接口開發(fā)邏輯復(fù)雜度和后續(xù)的維護(hù)成本被放大很多。
二、單品頁業(yè)務(wù)系統(tǒng)架構(gòu)
這是當(dāng)前單品頁系統(tǒng)的整體架構(gòu)圖，其他的核心交易流程，比如購物車、下單等也都基本類似，單品頁系統(tǒng)主要有三個(gè)進(jìn)程：OpenResty、Tracer-Collect、Tomcat，以及包含幾個(gè)旁路系統(tǒng)。OpenResty是nginx層的web容器，主要職責(zé)是做靜態(tài)化和限流防刷，只有經(jīng)過清洗過的流量才會(huì)流轉(zhuǎn)到tomcat的java進(jìn)程真正的業(yè)務(wù)處理，Tracer-Collect進(jìn)程是通過旁路的方式異步埋點(diǎn)到統(tǒng)一的監(jiān)控平臺(tái)，進(jìn)行實(shí)時(shí)的數(shù)據(jù)分析。
三、核心技術(shù)點(diǎn)
這個(gè)是在今年618之前架構(gòu)上做的一個(gè)變化，主要有以下幾點(diǎn)考慮：
業(yè)務(wù)需要，業(yè)務(wù)流量到一定程度，需要把靜態(tài)化數(shù)據(jù)以及限流策略前置，更多把流量擋在前端，減少業(yè)務(wù)系統(tǒng)壓力；
ngx_openresty模塊有效地把Nginx 服務(wù)器轉(zhuǎn)變?yōu)橐粋€(gè)強(qiáng)大的 Web 應(yīng)用服務(wù)器，在其他0級(jí)系統(tǒng)中已經(jīng)很好驗(yàn)證了帶來的高可用、高并發(fā)的能力。
使用規(guī)范上
Lua屬于腳本語言，開發(fā)相對(duì)java語言比較開放，比如方法可以返回多對(duì)象，這對(duì)長期java開發(fā)人員就有很多不適應(yīng)，在灰度過程中及時(shí)發(fā)現(xiàn)并進(jìn)行修復(fù)，因此利用lua來滿足特殊需求外，不會(huì)進(jìn)行過多業(yè)務(wù)邏輯處理；
任何技術(shù)上的變動(dòng)都要極度謹(jǐn)慎，不斷的進(jìn)行灰度測(cè)試，我們是從一臺(tái)機(jī)器逐步灰度到一個(gè)set，再擴(kuò)散到一個(gè)渠道，最后全量，并且具備實(shí)時(shí)的異常數(shù)據(jù)埋點(diǎn)能力，及時(shí)發(fā)現(xiàn)灰度過程中問題，一旦發(fā)現(xiàn)問題要有開關(guān)能實(shí)時(shí)降級(jí)。
Lua語言對(duì)于很多團(tuán)隊(duì)都使用過程中都遇到各種問題，今年雙11的總結(jié)會(huì)上也有團(tuán)隊(duì)分享大促期間lua死鎖問題，我們這里遇到的一個(gè)場景是zk的配置數(shù)據(jù)同步到lua時(shí)一定概率出現(xiàn)死鎖。
原因：lua運(yùn)行在nginx主線程中，但zk在nginx主線程外啟動(dòng)新的線程watch，當(dāng)zk更新時(shí)通過這個(gè)新線程通知數(shù)據(jù)更新，這時(shí)我們?cè)谶@個(gè)新的線程中直接調(diào)用lua代碼，會(huì)有概率產(chǎn)生死鎖。
解決方案：在這個(gè)新線程中不直接調(diào)用lua代碼，而是通過http協(xié)議直接進(jìn)入nginx主線程更新配置數(shù)據(jù)。
單品頁給APP提供的API重點(diǎn)包含兩個(gè)，一個(gè)是靜態(tài)接口，一個(gè)是動(dòng)態(tài)接口數(shù)據(jù)，這里提到的靜態(tài)化重點(diǎn)是針對(duì)靜態(tài)接口數(shù)據(jù)，包含商品圖片、基本信息、店鋪商家信息、顏色尺碼、延?！?.等，去年雙11期間，由于一些熱點(diǎn)商品訪問量過大，對(duì)jimdb集群單個(gè)分片的連接數(shù)和操作數(shù)都非常高，服務(wù)壓力過大，整體集群服務(wù)性能變差，因此針對(duì)此進(jìn)行了三級(jí)熱點(diǎn)的優(yōu)化：
CDN
眾所周知，CDN本來就是替業(yè)務(wù)靜態(tài)流量扛熱點(diǎn)數(shù)據(jù)，但是上邊提到后端有很多的適配工作，包括平臺(tái)、網(wǎng)絡(luò)環(huán)境、分辨率尺寸，要知道Android的分辨率五花八門，所以這種邏輯的話CDN很難發(fā)揮作用，因此今年針對(duì)這個(gè)邏輯做了優(yōu)化，接口下發(fā)給APP的數(shù)據(jù)都是標(biāo)準(zhǔn)數(shù)據(jù)格式，同時(shí)會(huì)下發(fā)對(duì)應(yīng)的適配規(guī)則給APP，由APP根據(jù)規(guī)則進(jìn)行動(dòng)態(tài)適配，極大地提升了緩存命中率，另外別忘了還要加上各種開關(guān)控制和數(shù)據(jù)的埋點(diǎn)監(jiān)控，這也是APP開發(fā)的一個(gè)重要特征，APP發(fā)出去的版本如果出現(xiàn)各種未知情況將會(huì)是災(zāi)難，在618之前版本經(jīng)過各種灰度最終還是順利上線，在618期間發(fā)揮了重要作用，CDN的命中率達(dá)到60%以上，大促的0點(diǎn)開始大部分人還是集中在少數(shù)的爆款商品上。這是第一層的保護(hù)。
OpenResty（Nginx+Lua）層靜態(tài)化
上邊提到這一層重點(diǎn)還是數(shù)據(jù)靜態(tài)化和防刷，您可能有疑問，CDN已經(jīng)替擋住了大部分流量，為什么還需要這一層？CDN只是擋住了App的最新版本熱點(diǎn)流量，還有M渠道是通過內(nèi)網(wǎng)網(wǎng)關(guān)過來的，不經(jīng)過CDN，以及App的老版本也是不走CDN，因此這一層主要依賴Nginx的共享緩存，分配100M的共享空間，在大促時(shí)命中率也可以到接近20%。
JVM本地緩存
JVM的堆內(nèi)存主要是針對(duì)商品的基本信息和特殊屬性信息進(jìn)行本地緩存，支持動(dòng)態(tài)接口商品熱點(diǎn)數(shù)據(jù)，依賴Guava組件實(shí)現(xiàn)的LRU緩存淘汰算法，大致5000個(gè)熱點(diǎn)sku數(shù)據(jù)，數(shù)據(jù)量在5M左右，這是第三層的數(shù)據(jù)保護(hù)，大促時(shí)命中率在27%左右，另外強(qiáng)調(diào)一下，這里的java對(duì)象可動(dòng)態(tài)配置成弱引用或者是軟引用，一般建議采用弱引用，這樣避免內(nèi)存增長過快，導(dǎo)致頻繁的GC。
數(shù)據(jù)異構(gòu)帶來的好處是可以減少一些基礎(chǔ)服務(wù)的強(qiáng)依賴，之前老板提的一個(gè)目標(biāo)就是基礎(chǔ)服務(wù)掛了，上層業(yè)務(wù)還能很好的活著，但是京東這個(gè)數(shù)據(jù)體量來看成本是非常巨大的，因此APP單品頁選擇部分?jǐn)?shù)據(jù)異構(gòu)，減少基礎(chǔ)服務(wù)接口的強(qiáng)依賴，主要是商品的基礎(chǔ)數(shù)據(jù)、擴(kuò)展屬性信息、商品的詳情數(shù)據(jù)，全量數(shù)據(jù)同步一次之后通過中間件JMQ進(jìn)行增量的數(shù)據(jù)同步變更，存儲(chǔ)使用的是緩存中間件jimdb（redis緩存）。
APP單品頁前期屬于野蠻發(fā)展，很多RPC的依賴極其不合理，比如依賴關(guān)系沒有層次概念，超時(shí)時(shí)間設(shè)置超長、內(nèi)外網(wǎng)接口同時(shí)依賴，造成任何的服務(wù)質(zhì)量變差和網(wǎng)絡(luò)抖動(dòng)對(duì)整體API影響非常大，因此進(jìn)行了一次SOA化改造，主要工作是把單品頁系統(tǒng)從大網(wǎng)關(guān)分離出來，然后制定服務(wù)接入標(biāo)準(zhǔn)并進(jìn)行改造，第三方面就是上游基礎(chǔ)服務(wù)調(diào)用并行化，系統(tǒng)整體并發(fā)能力及穩(wěn)定性得到了極大的提升。
服務(wù)依賴的標(biāo)準(zhǔn)
依賴接口必須是內(nèi)網(wǎng)服務(wù)，不允許依賴外網(wǎng)服務(wù)；
接口超時(shí)時(shí)間不超過100ms，并且除了一些核心數(shù)據(jù)，比如商品、價(jià)格、庫存，其他都不進(jìn)行重試；
核心接口必須可支持跨機(jī)房的雙活容災(zāi)，client端出現(xiàn)問題必須可切換，并且要有降級(jí)方案；
RPC調(diào)用最好是依賴中間件JSF，這樣是點(diǎn)對(duì)點(diǎn)的長連接服務(wù)，減少每次建連的開銷，HTTP依賴需要經(jīng)過內(nèi)網(wǎng)的LB，增加一層代理的開銷，會(huì)出現(xiàn)一些不可控的問題。
隨著流量不斷增加，并行化遇到了瓶頸，每次請(qǐng)求會(huì)創(chuàng)建大量的線程，線程的維護(hù)和上下文切換成本本身比較消耗CPU資源，因此基于現(xiàn)有HttpClient和JSF基礎(chǔ)組件的異步化支持，進(jìn)一步進(jìn)行異步化的改造，單機(jī)壓測(cè)效果還是比較明顯，并發(fā)能力提升40%。
系統(tǒng)流量到一定程度，系統(tǒng)的各維度監(jiān)控尤為重要，可以幫助我們縮短排查、定位問題的時(shí)間，甚至可以幫助預(yù)警風(fēng)險(xiǎn)，當(dāng)前APP業(yè)務(wù)從用戶到后端整個(gè)服務(wù)鏈條的監(jiān)控都已經(jīng)非常完善，包括各運(yùn)營商入口流量的監(jiān)控、內(nèi)外部網(wǎng)絡(luò)質(zhì)量、負(fù)載均衡、以及網(wǎng)關(guān)流量的監(jiān)控以外，我重點(diǎn)介紹下單品頁業(yè)務(wù)層的監(jiān)控，下邊是業(yè)務(wù)監(jiān)控系統(tǒng)數(shù)據(jù)異步埋點(diǎn)的架構(gòu)，主要分為兩類數(shù)據(jù)，第一業(yè)務(wù)指標(biāo)數(shù)據(jù)比如單品頁各渠道訪問數(shù)據(jù)，通過UDP協(xié)議實(shí)時(shí)埋點(diǎn)到Kafka，然后storm實(shí)時(shí)在線分析形成最終需要的數(shù)據(jù)落地，另一類是大流量數(shù)據(jù)，比如系統(tǒng)異常信息落到磁盤日志中，然后通過logCollector異步發(fā)送到Kafka中，這類數(shù)據(jù)對(duì)磁盤IO、網(wǎng)卡IO的流量占比大，針對(duì)磁盤IO，會(huì)按照文件大小100M滾動(dòng)生成日志文件，數(shù)據(jù)搬走之后進(jìn)行刪除操作，網(wǎng)卡IO在數(shù)據(jù)傳輸過程中進(jìn)行了限速，按照1m/s的速度進(jìn)行傳輸，可進(jìn)行動(dòng)態(tài)調(diào)整，基本對(duì)業(yè)務(wù)不產(chǎn)生任何影響，大促峰值期間會(huì)針對(duì)一定比例降級(jí)。
業(yè)務(wù)系統(tǒng)除了基本的服務(wù)器各項(xiàng)指標(biāo)CPU、MEM監(jiān)控，服務(wù)的性能、可用率監(jiān)控以外，介紹幾個(gè)比較實(shí)用的業(yè)務(wù)能力監(jiān)控：
方法tree監(jiān)控，一次請(qǐng)求在單品頁SOA系統(tǒng)內(nèi)部所經(jīng)過的每一個(gè)類的方法作為結(jié)點(diǎn)形成這么一顆樹，這棵樹非常直觀看到系統(tǒng)內(nèi)部的依賴結(jié)構(gòu)關(guān)系和任何一個(gè)節(jié)點(diǎn)的請(qǐng)求量的大小，如果性能、可用率、異常量、訪問量出現(xiàn)異?？傻谝粫r(shí)間標(biāo)紅報(bào)警，出現(xiàn)任何故障可第一時(shí)間聚焦到具體某一個(gè)點(diǎn)上，極大提升了定位和處理故障的時(shí)間；
異常監(jiān)控 ， 系統(tǒng)依賴的外部服務(wù)以及系統(tǒng)內(nèi)部拋出的任何一條異常的堆棧信息都被異步埋點(diǎn)記錄下來，進(jìn)行實(shí)時(shí)的統(tǒng)計(jì)和報(bào)警，對(duì)系統(tǒng)健康度的把控起到至關(guān)重要的作用；
用戶行為的跟蹤，詳細(xì)記錄用戶在什么時(shí)間做了什么事情以及當(dāng)時(shí)的網(wǎng)絡(luò)情況，方便用戶出現(xiàn)問題時(shí)回放出問題時(shí)的現(xiàn)場，快速幫助用戶解決問題。
監(jiān)控細(xì)節(jié)還有很多，以上幾個(gè)監(jiān)控手段對(duì)當(dāng)前業(yè)務(wù)系統(tǒng)幫助非常大也是非常實(shí)用的一些能力，現(xiàn)在業(yè)務(wù)系統(tǒng)已經(jīng)做到非常透明，任何人都可以清晰看到系統(tǒng)的健康度，并且部分服務(wù)具備通過故障自動(dòng)容錯(cuò)的能力，對(duì)系統(tǒng)整體的穩(wěn)定性提供了非常大的保障。
京東APP上所有商品價(jià)格庫存都是分區(qū)域的，因此很多刷子以及爬蟲不斷的來爬京東各區(qū)域的價(jià)格、庫存和促銷信息等，有一個(gè)很明顯的特征就是大量刷子刷時(shí)用戶登錄態(tài)的占比會(huì)明顯下降，因此單品頁針對(duì)用戶的行為實(shí)時(shí)行為數(shù)據(jù)進(jìn)行分析和控制：
流量清洗能力，根據(jù)用戶的pin、IP的實(shí)時(shí)分析和清洗，并可以根據(jù)已登錄和未登錄做不同策略；
系統(tǒng)過載保護(hù)能力，任何時(shí)候不能讓系統(tǒng)掛掉，把明顯的惡意流量清洗之后進(jìn)行按一定策略進(jìn)行排隊(duì)，保障流量不超過系統(tǒng)極限負(fù)載，同時(shí)給用戶比較友好的一些交互體驗(yàn)。
單品頁壓測(cè)比較麻煩，一方面壓測(cè)的流量大，對(duì)線上可能會(huì)造成很多不可預(yù)知的問題，另一方面涉及的基礎(chǔ)服務(wù)比較多，牽涉的人就多，每次壓測(cè)要協(xié)調(diào)上下游幾十號(hào)人支持，協(xié)調(diào)成本比較高，第三方面壓測(cè)的商品數(shù)量都在上百萬的商品，每次壓測(cè)的SKU會(huì)變更，腳本變更比較大，第四每次壓測(cè)完成之后需要人工形成壓測(cè)報(bào)告并分析其中的薄弱環(huán)節(jié)問題，因此APP端產(chǎn)出了一個(gè)自己的壓測(cè)平臺(tái)，通過流程方面來協(xié)助解決以上幾個(gè)問題：
啟動(dòng)壓測(cè)任務(wù)可自動(dòng)收集壓測(cè)數(shù)據(jù)并產(chǎn)出需要的壓測(cè)腳本；
線上流量的隔離；
通知相關(guān)方，確認(rèn)壓測(cè)時(shí)間和壓測(cè)方案；
按照壓測(cè)腳本逐步進(jìn)行壓測(cè)任務(wù)執(zhí)行；
形成壓測(cè)報(bào)告，并分析壓測(cè)過程中問題點(diǎn)。
壓測(cè)數(shù)據(jù)準(zhǔn)備方面：
線上流量日志進(jìn)行回放，并且按照壓測(cè)目標(biāo)放大到一定倍數(shù)來回放；
按照各品類的流量占比選出一部分商品作為熱點(diǎn)數(shù)據(jù)來進(jìn)行壓測(cè)，檢驗(yàn)各環(huán)節(jié)對(duì)熱點(diǎn)數(shù)據(jù)的處理是否合理；
針對(duì)一些埋點(diǎn)以及統(tǒng)計(jì)要能清洗掉這部分?jǐn)?shù)據(jù)，目前主要是根據(jù)請(qǐng)求的一些固定特征，比如設(shè)備號(hào)和特殊標(biāo)識(shí)來進(jìn)行區(qū)分，并且上下游都要能做到一致的數(shù)據(jù)清洗規(guī)則。
四、未來方向
單品頁還有很大的一些優(yōu)化空間，比如為適應(yīng)快速的業(yè)務(wù)迭代進(jìn)行系統(tǒng)重構(gòu)、jvm垃圾收回策略和堆內(nèi)存分配大小的調(diào)整、異步化的改造等等優(yōu)化正在進(jìn)行，未來單品頁最重要的幾個(gè)方向：
動(dòng)態(tài)配置化：不同品類商品可根據(jù)單品頁元素動(dòng)態(tài)形成一個(gè)個(gè)性化的單品頁，做到完全樓層可配置化；
精細(xì)化：流控、自動(dòng)化降級(jí)等方面能夠根據(jù)用戶特征，比如用戶級(jí)別、地域等可執(zhí)行不同策略；
智能化：根據(jù)用戶畫像數(shù)據(jù)展示更多個(gè)性化推薦的數(shù)據(jù)，千人千面，給用戶提供更有價(jià)值的信息。
聯(lián)系客服
