1、為什么寫這篇文章

在工作期間，筆者有幸參與了下單鏈路的開發(fā)、維護(hù)工作，在這期間有經(jīng)歷下單從0到1的搭建，也有隨著業(yè)務(wù)發(fā)展不得不進(jìn)行系統(tǒng)重構(gòu)的經(jīng)驗。“提交訂單”這一詞大家應(yīng)該都是再熟悉不過了，不管你是不是軟件研發(fā)人員，還是普通使用電商APP購買商品的用戶，只要你在購買商品時必然會遇到。既然“提交訂單”這么頻繁的被使用到，作為任何電商APP來說，那么它的穩(wěn)定性就尤為重要。

那么站在技術(shù)視角看下單鏈路，會發(fā)現(xiàn)幾個特點(diǎn)

• 高QPS/TPS，流量大
• 訂單數(shù)據(jù)正確性要求極高
• 監(jiān)控告警時快速定位能力
• 結(jié)算頁到訂單創(chuàng)建成功的所見即所得
• 易被惡意流量刷單
• 依賴下游服務(wù)非常之多
• 業(yè)務(wù)邏輯很復(fù)雜

本篇文章就挑幾個在日常研發(fā)中可能會遇到比較明顯的問題，以及是怎么進(jìn)行應(yīng)對的。

2、可能遇到的問題

2.1  線上告警頻繁，精準(zhǔn)定位問題耗時較長

告警機(jī)制，這個大家最熟悉不過的了，作為技術(shù)人的對這可以說是又愛又恨吧。即討厭線上頻繁告警的打擾，又擔(dān)心真正發(fā)生告警時的定位難。常見的主流監(jiān)控，Zabbix、Promethues、Open-Falcon等主要監(jiān)控的指標(biāo)還是以應(yīng)用維度為主，主要監(jiān)控指標(biāo)如下。

• Dubbo接口：請求量、耗時、異常量。
• JVM ：GC次數(shù)、GC耗時、各個內(nèi)存區(qū)域的大小、當(dāng)前線程數(shù)、死鎖線程數(shù)。
• 線程池：活躍線程數(shù)、任務(wù)隊列大小、任務(wù)執(zhí)行耗時、拒絕任務(wù)數(shù)。

如圖，類似于這種告警應(yīng)該是比較熟悉的。那么這里的問題也很明顯，下游接口異常到底影響的是哪個鏈路呢？針對這種特定業(yè)務(wù)場景，如訂單結(jié)算頁、提交訂單，這類接口級別的監(jiān)控又該怎么做呢？那首先簡單介紹下在一次下單請求中可能遇到的問題

• 下游接口調(diào)用告警

1. 強(qiáng)依賴接口和業(yè)務(wù)可降級接口，怎么進(jìn)行區(qū)分？
2. 當(dāng)告警來了，怎么確認(rèn)是下單鏈路所依賴的接口呢？
3. 下游接口告警了，是預(yù)期內(nèi)的業(yè)務(wù)異常還是非預(yù)期內(nèi)的呢？

• 接口rt&接口QPS抖動告警

！由于熱門商品、大促等活動節(jié)日的存在，所以下單鏈路會經(jīng)常出現(xiàn)這類告警

• AVG RT的下降，怎么識別是否正常？
• QPS的突然升高，升高的原因是啥呢？到底是下單鏈路阻塞了導(dǎo)致用戶一直重試，還是發(fā)生了搶購呢？
• 依賴的中間件發(fā)生抖動告警

• 怎么快速感知是MQ、Redis、DB等的異常？

• 應(yīng)用自身出現(xiàn)異常告警
• 普通業(yè)務(wù)異常：例如當(dāng)前APP版本不支持XXX新業(yè)務(wù)，非法請求核心參數(shù)缺失
• 非預(yù)期異常：新上線的業(yè)務(wù)代碼整出了異常導(dǎo)致下單阻斷
• 怎么區(qū)分普通業(yè)務(wù)異常和非預(yù)期異常？

普通業(yè)務(wù)異常：例如當(dāng)前APP版本不支持XXX新業(yè)務(wù)，非法請求核心參數(shù)缺失

非預(yù)期異常：新上線的業(yè)務(wù)代碼整出了異常導(dǎo)致下單阻斷

2.2  當(dāng)購買期間商品信息發(fā)生變更，怎么保障用戶的購買體驗?zāi)?/h3>

在用戶購買東西時，首先會看到訂單結(jié)算頁面，這個上面會展示商品價格，售后保障，到貨時效，優(yōu)惠信息等，這時用戶在確認(rèn)條款后會提交訂單，那么在訂單生成后訂單詳情看到的理論是需要和在結(jié)算頁看到的信息是完全一致的。但是由于結(jié)算頁和提交訂單是分開的請求，那么這個時間GAP以及實現(xiàn)差異終究可能會帶來不一致的情況發(fā)生。如果是普通庫存的話，給用戶直接重新展示訂單結(jié)算頁也還行，要是搶購商品的話，那這個體驗就會有比較大的影響。

2.3  依賴方數(shù)據(jù)返回不合法，該如何及時感知

訂單的數(shù)據(jù)是相當(dāng)復(fù)雜的，需要依賴商品、庫存、營銷、商家等數(shù)據(jù)信息，不同的業(yè)務(wù)場景對生成的訂單數(shù)據(jù)就會存在一定的要求。

那么這件事情的必要性，就在于可以在系統(tǒng)上線之前，通過回歸測試及流量回放驗證來及時發(fā)現(xiàn)是依賴方接口導(dǎo)致的問題還是自身系統(tǒng)代碼bug帶來的影響。

3、解決方案

那么問題來了，既然決定好好治理，那么怎么治理呢？怎么以最小的人力、技術(shù)成本實現(xiàn)這些治理呢？這個時候大量參考了現(xiàn)在同行業(yè)內(nèi)針對下單場景穩(wěn)定性相關(guān)的方案。現(xiàn)在就逐一介紹以上問題最終選擇的解決方案。

3.1 自定義實現(xiàn)告警機(jī)制的基礎(chǔ)日志數(shù)據(jù)埋點(diǎn)

針對接口級的定制化告警，采用了自定義日志埋點(diǎn)的方式，格式如下：

{current_time}|{trace_id}|{span_id}| {function_name}|{rt}|{error_code}|{error_message}|{user_id}

• function_name：用來具體區(qū)分哪個接口
• error_code：接口錯誤碼，用來唯一標(biāo)識接口異常原因，重點(diǎn)就是這個，這個指標(biāo)數(shù)據(jù)輸出的精細(xì)程度決定了定位問題的速度
• rt：接口響應(yīng)時間

這里簡單畫個圖，直觀的體現(xiàn)下需要關(guān)注下單鏈路中哪些指標(biāo)

現(xiàn)在介紹一下每個指標(biāo)的作用：

• 網(wǎng)關(guān)QPS：觀察C端的實時入口流量
• 自身服務(wù)QPS：觀察到達(dá)服務(wù)本身的流量

網(wǎng)關(guān)QPS  > 自身QPS，可以考慮是否網(wǎng)關(guān)側(cè)發(fā)生了限流

當(dāng)自身QPS下降過高

網(wǎng)關(guān)QPS沒什么波動，那么這個時候考慮網(wǎng)關(guān)問題

網(wǎng)關(guān)QPS也同步下降，前置導(dǎo)購鏈路流量問題，如商詳/購買浮層 是否發(fā)生阻斷性異常

• 自身業(yè)務(wù)異常：輸出下單阻斷的業(yè)務(wù)原因，又稱為預(yù)期內(nèi)異常
• 自身其它運(yùn)行時異常：如NPE，稱為非預(yù)期內(nèi)異常，此時錯誤碼會統(tǒng)一輸出SYS_ERROR，一般此類會重點(diǎn)關(guān)注
• 下游接口RPC異常：此時會輸出是下游哪個接口導(dǎo)致的阻斷，如
• 商品查詢接口超時 -> QEURY_SKU(RPC_TIMEOUT)
• 用戶接口查詢網(wǎng)絡(luò)異常 -> QUERY_USER(NETWORK_EXCEPTION)
• 下游接口業(yè)務(wù)異常：如
• 優(yōu)惠已失效 -> CONSUME_DISCOUNT(INVALID)，這里會通過識別下游接口返回的code碼來區(qū)分不同的業(yè)務(wù)異常，所以在日常需求中要求下游接口提供方確保返回碼的含義就是這個原因
• 返回了未約定的code碼，統(tǒng)一會返回如XXX(BIZ_ERR)，看到此類錯誤碼的時候，就會及時反饋給下游服務(wù)Owner去跟進(jìn)這個問題
• 中間件訪問異常：
• SQL執(zhí)行異常
• 網(wǎng)絡(luò)連接RST異常
• 自身服務(wù)接口AVG RT/SUCCESS RT
• 這里主要說一下SUCCESS RT，這個指標(biāo)是可以最準(zhǔn)確的反饋出最近RT是否存在波動
• 自身服務(wù)接口AVG QPS/SUCCESS QPS
• 這里的success qps很重要，當(dāng)發(fā)生搶購的時候，整體QPS會大幅上升，這個時候可以SUCCESS QPS來判斷當(dāng)前成單量是不是穩(wěn)定

如果是淺庫存搶購，這個指標(biāo)不會有太大波動

接口被刷了，這個指標(biāo)也不會有太大波動，且會出現(xiàn)OPERATION_TOO_FREQUENTLY頻次限流錯誤碼

！通過將接口每次請求的埋點(diǎn)日志輸出到指定文件中，后續(xù)經(jīng)過監(jiān)控組采集以及分析得到了如下幾個主要的大盤：

1）確認(rèn)訂單&創(chuàng)建訂單錯誤碼大盤

從圖中可很直觀的發(fā)現(xiàn)當(dāng)前有哪些原因?qū)е碌南聠问。绨姹具^低限制、庫存售罄、下單頻次過高等原因，這樣就能很直觀的發(fā)現(xiàn)

• 從異常名可以看出是有很明顯業(yè)務(wù)語義的，這樣便于大家理解
• 針對下游接口調(diào)用，會輸出具體某個接口（也可以給對應(yīng)接口定義別名）的某個類型錯誤，如優(yōu)惠核銷的超時、優(yōu)惠已失效、優(yōu)惠已使用

另外還設(shè)計了基于機(jī)器IP的過濾，這種做法的好處是，在發(fā)布過程中，如果下單出現(xiàn)了任何阻塞性異常，都可以很快的感知到，從而可以快速做到SOP響應(yīng)處理。

對于鏈路中的業(yè)務(wù)弱依賴接口，這里不會有錯誤碼體現(xiàn)，這里依然還是借助于監(jiān)告警機(jī)制。

2） QPS&RT指標(biāo)數(shù)據(jù)

這里主要日常監(jiān)控觀察主要會注重成功量QPS，特別是發(fā)布期間完全可以依賴于這些指標(biāo)數(shù)據(jù)。例如發(fā)布期間這個時候在搶購，有了這個就能做到心中有數(shù)了。這里簡單說明一下成功量就是接口業(yè)務(wù)執(zhí)行成功的含義。

3）告警機(jī)制

有了如上的這些指標(biāo)數(shù)據(jù)，那么基于這些做告警機(jī)制就成了順理成章的事情啦，目前已經(jīng)有如下指標(biāo)告警：

• 錯誤碼環(huán)比漲幅超指定閾值
• 接口RT環(huán)比漲幅超指定閾值
• 接口成功量QPS環(huán)比下跌超過指定閾值

然后再將這些告警機(jī)制接入飛書、短信等通知，那么哪怕是在周末外出游玩的時間，有任何下單鏈路的異常告警，只需要打開手機(jī)看一眼就能快速定位到問題的根因所在了，豈不美哉？

以上就是針對下單告警機(jī)制的精細(xì)化處理了，除此之外，有了這些數(shù)據(jù)后，也對其它一些指標(biāo)數(shù)據(jù)也進(jìn)行了完善，如：

• 高頻訪問用戶
• 不同入口的實時下單量
• 當(dāng)前熱門購買商品

3.2  基于版本號的商品信息&數(shù)據(jù)一致性校驗

1） 商品價格變更

商品改價這個在電商中應(yīng)該是比較常見的，那么如果是在秒殺時改價，那么此時提示用戶“商品價格”變更可能對用戶的體感就沒那么好。針對這類問題可以采用商品信息+版本號機(jī)制。

用戶在訂單結(jié)算頁看到的商品數(shù)據(jù)版本會交由客戶端攜帶至提交訂單，此時提交訂單可以校驗該版本的生效時間是XX秒內(nèi)，確保這個時間內(nèi)訂單提交不受改價影響，這樣可以給到用戶一個較好的購買體驗。這個XX時間就需要業(yè)務(wù)來進(jìn)行權(quán)衡了。

2）數(shù)據(jù)一致性校驗

通過以上的UML圖可以看到，由于確認(rèn)訂單和創(chuàng)單是兩次請求，那么保證數(shù)據(jù)防篡改是第一要求，而且有了這個驗簽機(jī)制后，用戶自己通過簡單傳參刷創(chuàng)單接口就變得更加困難了。對于迭代版本中新增生成sign的參數(shù)，這邊主要采用version版本的方式，不同的version對應(yīng)參與生成version的參數(shù)有所不同。

• version1，參數(shù) a、b、c
• version2，參數(shù)a、b、c、d

有了防篡改的保障后，那么接下來就只需要在下單資源扣減之前，針對這些核心數(shù)據(jù)進(jìn)行一致性校驗即可，如訂單金額、展示給用戶的售后標(biāo)簽等等。這樣的話在出現(xiàn)不一致時可以給到用戶友好的提示，并且對可以及時進(jìn)行告警通知。

3.3 訂單數(shù)據(jù)正確性校驗&及時告警機(jī)制

一致性校驗節(jié)點(diǎn)旨在創(chuàng)單落庫節(jié)點(diǎn)前給恒久不變的規(guī)則（如：訂單支付金額 = 應(yīng)收金額 - 優(yōu)惠 ）提供下單前的兜底校驗及可選告警措施。不太適合落地多變的規(guī)則。如果是多變規(guī)則需要寫到對應(yīng)業(yè)務(wù)模塊以異常形式告出。大家自行判斷所屬業(yè)務(wù)屬于哪一種。

訂單數(shù)據(jù)完整性校驗致力于保障訂單在整個生命周期中數(shù)據(jù)的正確性。為用戶打造一站式的校驗、預(yù)警解決方案。提供以下能力：

• 可插拔式接入
• 場景定制化
• 動態(tài)降級
• 規(guī)則、預(yù)警可擴(kuò)展
• 統(tǒng)一流程處理

適用的場景：

1. 商家地址返回手機(jī)號存在掩碼問題，必要數(shù)據(jù)缺失
2. 優(yōu)惠接口在某種特定業(yè)務(wù)場景下未返回對應(yīng)的優(yōu)惠信息
3. 訂單金額計算是否一致與用戶看到的一致

4、雨過天晴后的??

1）基于錯誤碼大盤及監(jiān)控機(jī)制的問題快速定位

• 核心接口全局監(jiān)控，高靈敏度感知任何阻塞下單的問題
• 監(jiān)控機(jī)制實時告警

2）下單鏈路一致性機(jī)制保障，所見即所得

3）創(chuàng)單數(shù)據(jù)正確性兜底校驗

5、總結(jié)

在下單的穩(wěn)定性治理過程中，從面對線上告警的盲目無措，逐漸演進(jìn)到面對日常迭代變更、突發(fā)流量場景的鎮(zhèn)定自若。在日常工作中，持續(xù)關(guān)注、發(fā)現(xiàn)線上潛在的問題以及不合理的設(shè)計，然后盡量通過合理機(jī)制&實現(xiàn)來進(jìn)行保障。作為一名研發(fā)人員，不能確保不犯錯，但能盡最大努力及時發(fā)現(xiàn)錯誤，敬畏生產(chǎn)。幾套打完收工，可以手握小茶壺，靜看風(fēng)波了。