1. 背景

今年的818大促跟往年不太一樣,在蘇寧成立30周年之際,蘇寧易購提出了“專注好服務”的全新品牌主張,在帶來巨大流量的同時,也給我們中臺系統(tǒng)的保障工作帶來了更大的挑戰(zhàn)。如何在818的大促過程中,更快的,更有效率,更智能的全面做好穩(wěn)定性保障工作,是我們亟需解決的難題。

2. 大促保障的痛點

大促是考驗電商后臺系統(tǒng)能力的試金場,面對著成千上萬的消費者搶購流量,系統(tǒng)壓力瞬間增大,為了避免系統(tǒng)被流量沖垮,電商系統(tǒng)經(jīng)歷了從滿足日常業(yè)務的系統(tǒng)設計模式到滿足高并發(fā)的系統(tǒng)架構模式的轉(zhuǎn)變,系統(tǒng)架構越來越復雜。大促過程中如何保障系統(tǒng)穩(wěn)定、快速獲取流量峰值和熱點、快速獲取和匯總相關業(yè)務數(shù)據(jù)便成了大促過程中新的痛點問題。

交易中臺基于以上痛點,結合大數(shù)據(jù)技術,通過數(shù)據(jù)的挖掘和應用來保障818大促的穩(wěn)定。

3. 數(shù)據(jù)組件支撐大促保障

3.1. TPS采集組件

目前RSF平臺(蘇寧自研微服務框架)只有分鐘級的調(diào)用量統(tǒng)計,無法精準統(tǒng)計到秒,且平臺原始日志數(shù)據(jù)也為采樣打印,無法直接使用。無論從容量規(guī)劃角度,還是從實時監(jiān)控,流控等角度去考慮,秒級監(jiān)控需求都極為迫切。

基于以上情況,中臺自研了TPS采集組件,截止目前已經(jīng)接入近30個系統(tǒng)、200多個核心服務,通過統(tǒng)一的展示門戶,接入服務的實時、歷史調(diào)用量一覽無余。大大提升了壓測、大促時鏈路分析的效率及準確性。這些核心服務的數(shù)據(jù)落地,為性能分析、容量規(guī)劃及儲備,提供了最基礎的不可缺少的原材料。也讓業(yè)務系統(tǒng)能直觀的看到自己系統(tǒng)的核心服務的壓力。

方案:

1:利用SpringAOP織入切面,業(yè)務系統(tǒng)接入只需添加注解并配置SCM開關。每個jvm統(tǒng)計各自服務每秒的調(diào)用量并記錄日志。

2:flume實時采集日志。

3:flink匯總每個服務單機房以及多機房的秒級調(diào)用量。

4:服務秒級調(diào)用量匯總?cè)霂臁?/p>

5:門戶實時展示調(diào)用量數(shù)據(jù)。

3.2. 流控組件

流控一直都是系統(tǒng)最重要的保障手段之一。流控從技術實現(xiàn)上分為兩種。一種為并發(fā)流控,這種流控主要基于并發(fā)考慮,公司的RSF框架流控基于此原理,但是缺點也比較大。一般系統(tǒng)服務能力或者籌備目標都是用TPS去衡量,而從TPS很難精準的換算出單JVM能支撐的并發(fā)量。而另一種流控是通過控制QPS來拒絕流量,最終保護系統(tǒng)。也是我們彌補目前流控能力不足的方式。

因此,中臺自研了流控組件,目前中臺130多個核心接口已經(jīng)全部接入。每個核心接口按照其使用的場景及需求接入了不同種類的流控組件。在接入流控之后,極大的降低了整個大促監(jiān)控團隊的運維壓力,某種意義上實現(xiàn)了對服務的無人值守。

3.2.1. 分布式流控

分布式流控主要是針對每個JVM設定流控閾值,進行單JVM流量控制。因此需要計算整體的服務能力,然后除以應用數(shù)量,計算流控閾值。他的優(yōu)點主要是完全基于JVM,損耗極小,幾乎可以忽略不計。

方案:

1:控制平臺將流控閾值下發(fā)到每個JVM。

2:對每次請求進行秒級調(diào)用量匯總,判斷是否超過閾值。

3:如果超過閾值則將超過閾值的請求流控,并打印流控日志。

4:flume采集流控日志。

5:flink匯總單機房以及多機房流控值。

6:門戶展示流控數(shù)據(jù)。

3.2.2. 分布式冷熱桶流控

主要用來防止爆款搶購,系統(tǒng)秒殺等熱品流量堵到正常系統(tǒng)的請求。如果直接使用普通流控進行攔截,會造成普通商品購買被拒絕。因此對于這種場景,在之前的流控組件的基礎上增加冷熱桶,系統(tǒng)自動識別熱品,同時冷熱流控閾值分離。

方案:

1:控制平臺將流控閾值下發(fā)到每個JVM。

2:對每次請求進行冷熱區(qū)分(自動判斷、固定值判斷)。

3:對冷熱請求按秒級維度進行匯總,并按冷、熱兩個閾值進行判斷。

4:如果超過閾值則將超過閾值的流控,并打印流控日志。

5:flume采集流控日志。

6:flink匯總單機房以及多機房流控數(shù)量并入庫。

7:門戶展示流控數(shù)據(jù)。

3.2.3. 全局流控

全局流控主要是針對流控要求比較精細的場景,希望能做到精準控制。例如提交訂單場景。整體思路是設置全局流控閾值(可放入Redis中),由JVM進行閾值步長拉取,后在JVM中去扣減流控步長以達到流控目的。

方案:

1:控制平臺將流控閾值及步長下發(fā)到每個JVM。

2:請求前判斷本jvm是否有配額,有則扣減本地配額,沒有則從公共配額拉取(值為步長)。

3:如果公共配額用凈,則將多余流量流控并打印日志。

4:flume采集流控日志。

5:flink匯總單機房以及多機房流控量并入庫。

6:門戶展示流控數(shù)據(jù)。

3.2.4. 流控比對

對比可知,分布式流控,全局流控,冷熱分離各有優(yōu)缺點。不同的業(yè)務場景,可以選擇不同的實現(xiàn)方案。在此基礎上流控的下一步方案是升級到動態(tài)流控,可以動態(tài)實現(xiàn)分布式,全局流控的自由切換,實現(xiàn)全局流控,冷熱分離閾值的動態(tài)調(diào)整和生效。而這塊重點應該是如何根據(jù)上報的健康數(shù)據(jù)分析并實現(xiàn)動調(diào)整當前流控方式或者配額值。

4. 中臺數(shù)據(jù)云支撐大促保障

除了組件提升,大數(shù)據(jù)和AI能力也逐步成為大促保障的重要利器。交易中臺通過采集平臺,清洗平臺,中臺數(shù)據(jù)云平臺的三層建設,一方面提供統(tǒng)一的數(shù)據(jù)指標服務,更重要的是提供了基于OLAP的業(yè)務指標服務,多維度查詢服務,歸檔服務等。同時也給大促籌備帶來了新的突破。

4.1. 大促云車加車分析

購物車是交易鏈路的關鍵系統(tǒng),大促交易峰值來源于購物車的訂單提交,因此加車數(shù)據(jù)的分析對于大促保障至關重要。

利用中臺采集平臺實時(binlog)采集購物車加車數(shù)據(jù),將業(yè)務數(shù)據(jù)實時匯聚到中臺清洗平臺,對豐富的多切片(分庫分表)數(shù)據(jù)進行清洗和融合,刻畫背后的業(yè)務畫像,使用智能算法分析4億+加車數(shù)據(jù)以及7萬+促銷活動,為購物車、促銷系統(tǒng)提供818大促TOP100熱點加車商品和TOP10熱門促銷活動數(shù)據(jù),使系統(tǒng)可以提前對熱點商品和熱門活動進行緩存預熱,降低大促風險。

因加購數(shù)量越多代表商品越受歡迎,大促時對加購數(shù)量多的商品進行精準的營促銷干預,會起到更好的效果,有效的提高購物車的轉(zhuǎn)化率。

4.2. 大促多平臺智能分貨

蘇寧目前除自營體系的易購平臺、O2O小店平臺、線下門店等渠道外,也在加快第三方平臺入駐的步伐,目前已在天貓、抖音、達令家、美團、餓了嗎等外部各類平臺進行銷售活動,因此庫存中心對于各平臺貨物的調(diào)配也越來越重要與復雜,分貨的方式、調(diào)度策略、補貨頻次各不相同。如何提升分貨的準確性便成了大促期間備貨方案的重中之重。

中臺數(shù)據(jù)云智能分貨涉及15個大類,幾十萬商品,極大降低了各平臺的大促商品缺貨率,提升了818銷售。

方案:

1:依托數(shù)據(jù)云平臺、AI機器學習平臺,通過歷史銷量、促銷活動、庫存深度等數(shù)據(jù)進行各平臺銷量預測。

2:庫存中心依托分貨規(guī)則引擎,根據(jù)銷售預測進行各平臺庫存分貨,并根據(jù)分貨結果推送各平臺。

3:庫存中心實時掃描銷售情況和三方庫存狀態(tài)進行庫存動態(tài)調(diào)整,并搭建異常監(jiān)控體系,聯(lián)動業(yè)務,指導運營。

智能分貨模型的核心是銷售預測,結合業(yè)務特點,銷售預測分為三個階段,通過發(fā)揮銷售預測算法三個階段的不同的優(yōu)勢,實現(xiàn)銷售預測準確度的最大化。

1) 時間序列:探查分貨相關歷史特征數(shù)據(jù)的穩(wěn)定性和線性規(guī)律。

2) 機器學習:支持分貨多平臺多場景的業(yè)務,在多變量的情況下提升銷售預測質(zhì)量。

3) 深度學習:構建更復雜的分貨模式對應的銷售預測模型,自動學習分貨相關的特征實現(xiàn)預測的全面升級。

4.3. 壓測和大促流量模型

每次大促活動籌備,有這兩件事情重要的事項:首先會進行基于業(yè)務籌備目標的流量預算,以進行系統(tǒng)的容量評估,確定系統(tǒng)是否擴容;其次是制定壓測策略、執(zhí)行壓力測試、輸出壓力測試報告,確認每個系統(tǒng)是否達到籌備的目標值。

中臺三十多個系統(tǒng),系統(tǒng)服務眾多,大促容量評估很難準確,依據(jù)歷史數(shù)據(jù),梳理中臺核心業(yè)務線,構建7個核心流量模型,快速評估出818大促的服務籌備目標后,合理進行容量規(guī)劃,通過多輪全鏈路壓測進行驗證。

方案:

1:根據(jù)業(yè)務關鍵服務梳理出從上至下的調(diào)用關系鏈。

2:使用大數(shù)據(jù)采集各系統(tǒng)服務TPS數(shù)據(jù),建立核心服務流量模型。

3:通過活動分析以及歷史流量模型依托機器學習算法進行流量預測, 為818大促系統(tǒng)容量評估,壓測以及流控提供了有效的依據(jù)。

4.4. 大促系統(tǒng)健康巡檢

目前各監(jiān)控平臺都只是在系統(tǒng)發(fā)生風險的時候進行預警,無法做到提前識別。因此每一次大促保障,都需要進行多輪的系統(tǒng)監(jiān)控檢查,包含緩存使用率,命中率,磁盤使用率,IO,Topsql等各項體檢。每項檢查涉及幾千臺機器,人工檢查耗時耗力。通過對ZABBIX,DBMS等系統(tǒng)提供的服務或離線數(shù)據(jù)采集,中臺數(shù)據(jù)云平臺自動出具檢查分析報告,極大的節(jié)省了人力,從之前人工檢查花費一周變成系統(tǒng)自動巡檢只需一天。

方案:

1:結合組件能力,系統(tǒng)巡檢可以由TPS流量異動,流控告警和手工觸發(fā)三種方式發(fā)起。對于系統(tǒng)自動觸發(fā)的通過規(guī)則引擎判斷是否需要進行巡檢。

2:巡檢發(fā)起后分別聯(lián)動異常監(jiān)管系統(tǒng),資源管理系統(tǒng),數(shù)據(jù)庫管理系統(tǒng)和微服務管理系統(tǒng)多個異常監(jiān)控平臺,通過服務,數(shù)據(jù)同步等方式獲取系統(tǒng)健康數(shù)據(jù)。

3:進行風險評,出具巡檢報告。如果存在異常,結合AI圖譜識別,根因分析后出具報告。

5. 未來-智能診斷

無論多么資深的技術人員,絕大部分情況下都無法在1分鐘內(nèi)識別系統(tǒng)異常產(chǎn)生的根本原因。然而在大促這種特殊的場景下,線上發(fā)生的任何問題都需要即刻定位和處理, 因此我們未來規(guī)劃了系統(tǒng)智能診斷模型。當系統(tǒng)發(fā)生異常后觸發(fā)第一層主機層診斷,聯(lián)合云計算研發(fā)中心,通過知識圖譜構建根因分析。第一層診斷完成后,進行持久層根因診斷,判斷數(shù)據(jù)庫是否存在異常,最后進行業(yè)務層根因檢測。通過三層智能診斷快速定位系統(tǒng)異常的根本原因。

大促保障是一項極其復雜的系統(tǒng)化工程,每次大促對系統(tǒng)而言都是一次全方位的考驗。面對越來越復雜的系統(tǒng)和更加多樣化的營促銷活動,中臺大促保障以技術為本,總結每次大促經(jīng)驗,持續(xù)建設常態(tài)化的籌備機制和立體化的監(jiān)控工具,推進保障工作逐步向更加體系化,精細化和智能化的方向發(fā)展,最終保障系統(tǒng)的平穩(wěn)運行,保證用戶順暢的購物體驗。

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）