背景概括：

供應(yīng)鏈大屏做為物流的核心報表，為管理者提供大促決策時的依據(jù)。頁面指標(biāo)超過170+，依賴接口30+，復(fù)雜度較高，數(shù)據(jù)鏈路較長，同時穩(wěn)定性要求高。

本文將分享供應(yīng)鏈大屏是如何保障雙11供應(yīng)鏈大屏的穩(wěn)定性。

一，供應(yīng)鏈大屏全鏈路流程圖

保障的首要步驟是繪制供應(yīng)鏈大屏全鏈路流程圖。在梳理出概覽圖之后，深入指標(biāo)加工的各個細(xì)節(jié)去發(fā)現(xiàn)問題，然后是因地制宜的制定保障方案。

下邊是梳理的供應(yīng)鏈大屏加工的全流程圖，圖中標(biāo)注了各個風(fēng)險點(diǎn)的保障方案。

?

?

二，供應(yīng)鏈大屏風(fēng)險點(diǎn)梳理

在有了加工全鏈路之后，按照從左到右、從上往下的思路分析各個流程節(jié)點(diǎn)的薄弱點(diǎn)。

大屏加工按照分層的概念，從左到右依次是數(shù)據(jù)接入層、指標(biāo)加工層、指標(biāo)存儲層、指標(biāo)服務(wù)層。

下邊是各個模塊保障的風(fēng)險點(diǎn)：

1，數(shù)據(jù)接入層：

?加工鏈路長：從數(shù)據(jù)產(chǎn)生到指標(biāo)加工完成，經(jīng)過了報表庫、多層蜂巢任務(wù)、多層JDQ、多層Flink任務(wù)、DTS、CK、Easydata

?涉及依賴方多：依賴大件、服務(wù)、逆向、B2B、LDC、冷鏈、實時數(shù)據(jù)團(tuán)隊

?涉及接入類型多：離線Hive、jsf接口、http接口、業(yè)務(wù)導(dǎo)入、CK

2，指標(biāo)加工層：

?指標(biāo)存在多種維度，指標(biāo)計算有先后順序

?外部依賴無法保證100%，數(shù)據(jù)加工需要有重算功能，需要一定的容錯性及故障自動恢復(fù)功能

?業(yè)務(wù)促銷策略需要靈活調(diào)整（促銷策略受友商影響，需支持隨時調(diào)整）

3，指標(biāo)存儲層：

?多業(yè)務(wù)互相影響

?指標(biāo)異常需要快速定位

4，指標(biāo)服務(wù)層：

?需要保障接口穩(wěn)定性

?外部依賴接口需要可降級

?外部依賴接口需要有兜底

?多個業(yè)務(wù)服務(wù)如何隔離

5，監(jiān)控管理：

?指標(biāo)加工如何監(jiān)控

?加工鏈路異常如何快速定位

三，技術(shù)上的保障策略

1，數(shù)據(jù)接入層

1.1，加工鏈路長

1.1.1，全鏈路確定邊界，邊界一定要是清晰的，整個大屏按照責(zé)任方拆分為4個區(qū)域：

?蜂巢部分：蜂巢團(tuán)隊保障

?實時加工任務(wù)：實時數(shù)據(jù)團(tuán)隊保障

?各個接口提供方：各個接口方保障

?大屏加工及查詢部分：SCM保障（自己小組負(fù)責(zé)）

?

1.1.2，要求各依賴方及接口做高可用

?蜂巢：蜂巢保障高可用、蜂巢報警、蜂巢監(jiān)控、蜂巢壓測

?實時加工任務(wù)：加工任務(wù)雙流保障、FLINK加工鏈路壓測

?各個接口提供方：確定接口保障范圍及接口SLA

1.1.3，監(jiān)控前置

蜂巢、實時FLINK任務(wù)都加上了SCM研發(fā)，數(shù)據(jù)積壓作為下游也能提前知曉，同時也是對上游監(jiān)控的一個補(bǔ)充

具體信息見第三節(jié)第5項“監(jiān)控管理”

1.2，涉及依賴方多

梳理出所有依賴接口，與各依賴方確定SLA，下邊是部分接口示例：

1.3，涉及接入類型多

按照各種類型指定相應(yīng)措施：

?離線Hive：與離線確定大促重保任務(wù)、離線任務(wù)監(jiān)控、烽火臺增加離線推數(shù)據(jù)表的監(jiān)控

?業(yè)務(wù)導(dǎo)入：協(xié)助業(yè)務(wù)做大促數(shù)據(jù)校驗、頁面開發(fā)大促雙11導(dǎo)入數(shù)據(jù)模擬（見四節(jié)）

?外部JSF、HTTP接口：監(jiān)控、重試、降級、兜底

2，指標(biāo)加工層

2.1，指標(biāo)存在多種維度，指標(biāo)計算有先后順序

指標(biāo)加工分層，按維度拆分不同的表（單倉指標(biāo)、區(qū)域指標(biāo)），按功能作用拆分表（分鐘表、小時表、緩存表、歷史表）

?

2.2，重算、容錯及快速恢復(fù)

外部依賴無法保證100%，數(shù)據(jù)加工需要有重算功能，需要一定的容錯性及故障快速恢復(fù)功能

加工容錯：對外部每個接口做通用降級方案，接口異常取最近30min內(nèi)上一次結(jié)果

快速恢復(fù)方案：提前設(shè)計容錯方案，保障在單個或多個外部接口異常時，能快速重算指標(biāo)并恢復(fù)

?

2.3，業(yè)務(wù)促銷策略需要靈活調(diào)整（促銷策略受友商影響，需支持隨時調(diào)整）

抽象出業(yè)務(wù)策略，通過DUCC靈活配置調(diào)整

{
    "sTime": "2024-11-xx 00:00:00"， // 大屏策略時間開始
    "eTime": "2024-11-xx 19:59:59"， // 大屏策略時間結(jié)束
    "tbSTime": "2023-11-xx 00:00:00"， //同比開始
    "tbETime": "2023-11-xx 19:59:59"，//同比結(jié)束
    "hbSTime": "2024-06-xx 00:00:00"，//環(huán)比開始
    "hbETime": "2024-06-xx 19:59:59"，//環(huán)比結(jié)束
    "showType": "24h"，//類型，24h同20h小時，都可以
    "special24hCompDateStr": "2024-11-xx"，//大促24h特殊對比日期，（4h，28h不使用） 主要影響預(yù)測；主要用作非 4h/28h 的預(yù)測不使用昨日了；
    "specialCompDateStr": ""       //大促4h/28h預(yù)測對比天數(shù)
}

2.4，大屏加工及查詢部分

指標(biāo)緩存：使用redis緩存指標(biāo)

接口壓測：forcebot按預(yù)估量壓測

鏈路雙流：

下邊是SCM指標(biāo)加工查詢CK的一鍵主備切換功能，在收到報警時可以快速切換查詢鏈路

?

3，指標(biāo)存儲層

3.1，多業(yè)務(wù)互相影響

3.1.1，根據(jù)業(yè)務(wù)，Mysql采用一主三從的方式，數(shù)據(jù)庫劃分為：

主庫、大屏查詢、核心看板查詢、其它報表

?

3.1.2，根據(jù)服務(wù)劃分，大屏及核心報表存儲Mysql，easybi報表使用Doris（Doris數(shù)據(jù)由Mysql binlog異步同步）

?

3.2，指標(biāo)異常需要快速定位

3.2.1，打標(biāo)字段存儲為json

根據(jù)sql從json里邊過濾

3.2.2，mysql數(shù)據(jù)通過binlog異步存儲到Doris（Doris支持更長時間數(shù)據(jù)）

?

4，指標(biāo)服務(wù)層

4.1，需要保障接口穩(wěn)定性

?壓測

?底層存儲隔離

?業(yè)務(wù)隔離

4.2，需要可降級

外部接口單次異常，取當(dāng)前促銷策略內(nèi)，最近30min的上一次成功數(shù)據(jù)

4.3，需要有兜底

預(yù)測時異常品類的兜底策略，保障數(shù)據(jù)不會異常

5，監(jiān)控管理

總結(jié)為2個點(diǎn)：

1，監(jiān)控前置：盡可能監(jiān)控前置，提前感知上游異常，提前采取保障措施

2，監(jiān)控全面：盡可能能覆蓋所有環(huán)節(jié)；加工環(huán)節(jié)、查詢環(huán)節(jié)、推數(shù)據(jù)環(huán)節(jié)、數(shù)據(jù)準(zhǔn)確性環(huán)節(jié)

5.1，蜂巢：報警增加SCM研發(fā)，研發(fā)監(jiān)控前置

下邊是我們收到上游蜂巢的報警，以及積壓恢復(fù)告警

?

5.2，實時加工

5.2.1，報警增加SCM研發(fā)，研發(fā)監(jiān)控前置

下邊是我們收到的實時JDQ報警

?

5.2.2，我們維護(hù)了一份實時任務(wù)的JDQ層級列表，我們也能快速定位具體積壓點(diǎn)

圖1是實時加工鏈路，紅色箭頭從我們開始，箭頭指向更遠(yuǎn)端上游。

圖2是我們維護(hù)的JDQ對應(yīng)的上級各個速查監(jiān)控url，紅色箭頭從我們開始，箭頭指向更遠(yuǎn)端上游的表。

?

5.3，SCM加工監(jiān)控全域看板（依賴方接口可用率、自己方法可用率、是否調(diào)用）：

?

5.4，SCM接口查詢監(jiān)控全域看板：

?

5.5，SCM指標(biāo)數(shù)據(jù)準(zhǔn)確性監(jiān)控：

主要使用烽火臺，監(jiān)控數(shù)據(jù)是否重復(fù)寫入，數(shù)據(jù)量級是否合理以及依賴數(shù)據(jù)是否具備

四，其它流程上的保障策略

1，溝通協(xié)同，建立大屏大促保障溝通群

由于涉及眾多依賴方，大促溝通保障群建立了一條高效快捷的溝通機(jī)制

2，依賴方全鏈路演練

每年兩次大促間隔時間長，各系統(tǒng)負(fù)責(zé)研發(fā)可能會變化，研發(fā)人員配置也可能會生疏。組織大屏全鏈路預(yù)發(fā)演練，一方面各系統(tǒng)人員都建立起溝通，另一方面提前熟悉配置，也校驗了配置策略的正確性。

另外大屏大促需求都臨近大促，各個系統(tǒng)方都有變化，這些變化基本都是大促特殊策略設(shè)置平時也驗證不了，全鏈路對特殊的策略下的演練，也能提前發(fā)現(xiàn)功能的一些隱藏問題。

3，與業(yè)務(wù)聯(lián)動、業(yè)務(wù)導(dǎo)入提前模擬校驗

3.1，針對大屏用到的歷史同環(huán)比數(shù)據(jù)，聚合到各個維度，拉著業(yè)務(wù)去確認(rèn)數(shù)據(jù)的準(zhǔn)確性

針對業(yè)務(wù)導(dǎo)入數(shù)據(jù)：通過策略修改及mock日期配置，業(yè)務(wù)可以在預(yù)發(fā)環(huán)境看到提前導(dǎo)入的雙11數(shù)據(jù)在大屏的展示，保障業(yè)務(wù)導(dǎo)入數(shù)據(jù)的準(zhǔn)確性。下方展示了跟業(yè)務(wù)聯(lián)動，測試各個策略時間段下各個條線的業(yè)務(wù)數(shù)據(jù)準(zhǔn)確性。

?

3.2，策略配置雙人double check，歷史問題歸納總結(jié)為check SOP

?

4，結(jié)果第一

結(jié)果第一，是我們保障大屏的方向指導(dǎo)，所以我們不光著眼于我們自己的系統(tǒng)，還從全流程上不斷地去找方法、找薄弱點(diǎn)，去保障大屏的穩(wěn)定性、數(shù)據(jù)的準(zhǔn)確性，更好地服務(wù)于業(yè)務(wù)。

結(jié)果第一，也是每次大促我們催著業(yè)務(wù)導(dǎo)數(shù)，而不是業(yè)務(wù)有問題了找我們?nèi)缓蟛沤鉀Q。業(yè)務(wù)說省區(qū)的都不著急為啥你們研發(fā)著急，不導(dǎo)入是省區(qū)的問題又不是你們研發(fā)的問題。對于這個問題，我是這么回復(fù)業(yè)務(wù)“我們的目標(biāo)是雙11大屏的穩(wěn)定與準(zhǔn)確，而不是說是因為誰的問題導(dǎo)致的大屏數(shù)據(jù)異?！保@是我對結(jié)果第一的理解，這也是我認(rèn)為我們團(tuán)隊能做好大屏保障的根本原因。

?

5，團(tuán)隊的力量

雙十一大屏保障的好，并不是一個人的努力，而是團(tuán)隊內(nèi)每個人的齊心協(xié)力，以及上下游的同事共同協(xié)作支持才達(dá)成的。我深知一個人的力量終究是有限的，但團(tuán)隊的力量可以創(chuàng)造無限的可能。

?
審核編輯 黃宇