下單穩定性治理 ｜ 得物技術

1

為什麼寫這篇文章

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

那麼站在技術視角看下單鏈路，會發現幾個特點

• 高QPS/TPS，流量大

• 訂單資料正確性要求極高

• 監控告警時快速定位能力

• 結算頁到訂單建立成功的所見即所得

• 易被惡意流量刷單

• 依賴下游服務非常之多

• 業務邏輯很複雜

本篇文章就挑幾個在日常研發中可能會遇到比較明顯的問題，以及是怎麼進行應對的。

2

可能遇到的問題

2.1  線上告警頻繁，精準定位問題耗時較長

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

• Dubbo介面：請求量、耗時、異常量。

• JVM ：GC次數、GC耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數。

• 執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數。

如圖，類似於這種告警應該是比較熟悉的。那麼這裡的問題也很明顯，下游介面異常到底影響的是哪個鏈路呢？針對這種特定業務場景，如訂單結算頁、提交訂單，這類介面級別的監控又該怎麼做呢？那首先簡單介紹下在一次下單請求中可能遇到的問題

1. 下游介面呼叫告警

1. 強依賴介面和業務可降級介面，怎麼進行區分？

2. 當告警來了，怎麼確認是下單鏈路所依賴的介面呢？

3. 下游介面告警了，是預期內的業務異常還是非預期內的呢？

2. 介面rt&介面QPS抖動告警

！由於熱門商品、大促等活動節日的存在，所以下單鏈路會經常出現這類告警

1. AVG RT的下降，怎麼識別是否正常？

2. QPS的突然升高，升高的原因是啥呢？到底是下單鏈路阻塞了導致使用者一直重試，還是發生了搶購呢？

3. 依賴的中介軟體發生抖動告警

1. 怎麼快速感知是MQ、Redis、DB等的異常？

4. 應用自身出現異常告警

1. 普通業務異常：例如當前APP版本不支援XXX新業務，非法請求核心引數缺失

2. 非預期異常：新上線的業務程式碼整出了異常導致下單阻斷

3. 怎麼區分普通業務異常和非預期異常？

1. 普通業務異常：例如當前APP版本不支援XXX新業務，非法請求核心引數缺失
2. 非預期異常：新上線的業務程式碼整出了異常導致下單阻斷

2.2  當購買期間商品資訊發生變更，怎麼保障使用者的購買體驗呢

在使用者購買東西時，首先會看到訂單結算頁面，這個上面會展示商品價格，售後保障，到貨時效，優惠資訊等，這時使用者在確認條款後會提交訂單，那麼在訂單生成後訂單詳情看到的理論是需要和在結算頁看到的資訊是完全一致的。但是由於結算頁和提交訂單是分開的請求，那麼這個時間GAP以及實現差異終究可能會帶來不一致的情況發生。如果是普通庫存的話，給使用者直接重新展示訂單結算頁也還行，要是搶購商品的話，那這個體驗就會有比較大的影響。

2.3  依賴方資料返回不合法，該如何及時感知

訂單的資料是相當複雜的，需要依賴商品、庫存、營銷、商家等資料資訊，不同的業務場景對生成的訂單資料就會存在一定的要求。

那麼這件事情的必要性，就在於可以在系統上線之前，透過迴歸測試及流量回放驗證來及時發現是依賴方介面導致的問題還是自身系統程式碼bug帶來的影響。

3

解決方案

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

3.1 自定義實現告警機制的基礎日誌資料埋點

針對介面級的定製化告警，採用了自定義日誌埋點的方式，格式如下：

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

• function_name：用來具體區分哪個介面

• error_code：介面錯誤碼，用來唯一標識介面異常原因，重點就是這個，這個指標資料輸出的精細程度決定了定位問題的速度

• rt：介面響應時間

這裡簡單畫個圖，直觀的體現下需要關注下單鏈路中哪些指標

現在介紹一下每個指標的作用：

• 閘道器QPS：觀察C端的實時入口流量

• 自身服務QPS：觀察到達服務本身的流量

• 閘道器QPS  > 自身QPS，可以考慮是否閘道器側發生了限流

• 當自身QPS下降過高

• 閘道器QPS沒什麼波動，那麼這個時候考慮閘道器問題

• 閘道器QPS也同步下降，前置導購鏈路流量問題，如商詳/購買浮層 是否發生阻斷性異常

• 自身業務異常：輸出下單阻斷的業務原因，又稱為預期內異常

• 自身其它執行時異常：如NPE，稱為非預期內異常，此時錯誤碼會統一輸出SYS_ERROR，一般此類會重點關注

• 下游介面RPC異常：此時會輸出是下游哪個介面導致的阻斷，如

• 商品查詢介面超時 -> QEURY_SKU(RPC_TIMEOUT)

• 使用者介面查詢網路異常 -> QUERY_USER(NETWORK_EXCEPTION)

• 下游介面業務異常：如

• 優惠已失效 -> CONSUME_DISCOUNT(INVALID)，這裡會透過識別下游介面返回的code碼來區分不同的業務異常，所以在日常需求中要求下游介面提供方確保返回碼的含義就是這個原因

• 返回了未約定的code碼，統一會返回如XXX(BIZ_ERR)，看到此類錯誤碼的時候，就會及時反饋給下游服務Owner去跟進這個問題

• 中介軟體訪問異常：

• SQL執行異常

• 網路連線RST異常

• 自身服務介面AVG RT/SUCCESS RT

• 這裡主要說一下SUCCESS RT，這個指標是可以最準確的反饋出最近RT是否存在波動

• 自身服務介面AVG QPS/SUCCESS QPS

• 這裡的success qps很重要，當發生搶購的時候，整體QPS會大幅上升，這個時候可以SUCCESS QPS來判斷當前成單量是不是穩定

• 如果是淺庫存搶購，這個指標不會有太大波動

• 介面被刷了，這個指標也不會有太大波動，且會出現OPERATION_TOO_FREQUENTLY頻次限流錯誤碼

！透過將介面每次請求的埋點日誌輸出到指定檔案中，後續經過監控組採集以及分析得到了如下幾個主要的大盤：

1. 確認訂單&建立訂單錯誤碼大盤

從圖中可很直觀的發現當前有哪些原因導致的下單失敗，如版本過低限制、庫存售罄、下單頻次過高等原因，這樣就能很直觀的發現

• 從異常名可以看出是有很明顯業務語義的，這樣便於大家理解

• 針對下游介面呼叫，會輸出具體某個介面（也可以給對應介面定義別名）的某個型別錯誤，如優惠核銷的超時、優惠已失效、優惠已使用

另外還設計了基於機器IP的過濾，這種做法的好處是，在釋出過程中，如果下單出現了任何阻塞性異常，都可以很快的感知到，從而可以快速做到SOP響應處理。

對於鏈路中的業務弱依賴介面，這裡不會有錯誤碼體現，這裡依然還是藉助於監告警機制。

2. QPS&RT指標資料

這裡主要日常監控觀察主要會注重成功量QPS，特別是釋出期間完全可以依賴於這些指標資料。例如釋出期間這個時候在搶購，有了這個就能做到心中有數了。這裡簡單說明一下成功量就是介面業務執行成功的含義。

3. 告警機制

有了如上的這些指標資料，那麼基於這些做告警機制就成了順理成章的事情啦，目前已經有如下指標告警：

• 錯誤碼環比漲幅超指定閾值
• 介面RT環比漲幅超指定閾值
• 介面成功量QPS環比下跌超過指定閾值

然後再將這些告警機制接入飛書、簡訊等通知，那麼哪怕是在週末外出遊玩的時間，有任何下單鏈路的異常告警，只需要開啟手機看一眼就能快速定位到問題的根因所在了，豈不美哉？

以上就是針對下單告警機制的精細化處理了，除此之外，有了這些資料後，也對其它一些指標資料也進行了完善，如：

• 高頻訪問使用者

• 不同入口的實時下單量

• 當前熱門購買商品

3.2  基於版本號的商品資訊&資料一致性校驗

1. 商品價格變更

商品改價這個在電商中應該是比較常見的，那麼如果是在秒殺時改價，那麼此時提示使用者“商品價格”變更可能對使用者的體感就沒那麼好。針對這類問題可以採用商品資訊+版本號機制。

使用者在訂單結算頁看到的商品資料版本會交由客戶端攜帶至提交訂單，此時提交訂單可以校驗該版本的生效時間是XX秒內，確保這個時間內訂單提交不受改價影響，這樣可以給到使用者一個較好的購買體驗。這個XX時間就需要業務來進行權衡了。

2. 資料一致性校驗

透過以上的UML圖可以看到，由於確認訂單和創單是兩次請求，那麼保證資料防篡改是第一要求，而且有了這個驗籤機制後，使用者自己透過簡單傳參刷創單介面就變得更加困難了。對於迭代版本中新增生成sign的引數，這邊主要採用version版本的方式，不同的version對應參與生成version的引數有所不同。

• version1，引數 a、b、c

• version2，引數a、b、c、d

有了防篡改的保障後，那麼接下來就只需要在下單資源扣減之前，針對這些核心資料進行一致性校驗即可，如訂單金額、展示給使用者的售後標籤等等。這樣的話在出現不一致時可以給到使用者友好的提示，並且對可以及時進行告警通知。

3.3 訂單資料正確性校驗&及時告警機制

一致性校驗節點旨在創單落庫節點前給恆久不變的規則（如：訂單支付金額 = 應收金額 - 優惠 ）提供下單前的兜底校驗及可選告警措施。不太適合落地多變的規則。如果是多變規則需要寫到對應業務模組以異常形式告出。大家自行判斷所屬業務屬於哪一種。

訂單資料完整性校驗致力於保障訂單在整個生命週期中資料的正確性。為使用者打造一站式的校驗、預警解決方案。提供以下能力：

• 可插拔式接入

• 場景定製化

• 動態降級

• 規則、預警可擴充套件

• 統一流程處理

適用的場景：

1. 商家地址返回手機號存在掩碼問題，必要資料缺失
2. 優惠介面在某種特定業務場景下未返回對應的優惠資訊
3. 訂單金額計算是否一致與使用者看到的一致

4

雨過天晴後的?

1. 基於錯誤碼大盤及監控機制的問題快速定位

   

• 核心介面全域性監控，高靈敏度感知任何阻塞下單的問題
• 監控機制實時告警

1. 下單鏈路一致性機制保障，所見即所得

1. 創單資料正確性兜底校驗

5

總結

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