有贊連鎖業務穩定性實踐

圖片

作者：阿嬌

部門：業務中臺 / 測試開發

一、業務背景

有贊連鎖，定位爲連鎖品牌多門店管理、多渠道增長數智化經營系統。店鋪結構上爲多級結構，主要爲：

目前商品在連鎖產品中採用的是複製方案，即總部新增編輯商品後，1：1 全量複製到每一個分店。商品信息接受 MU 的強管控，同時也具備部分字段信息的自定義能力，如價格、庫存、商品標題等。

商品在進行同步分店時，實際上我們在進行 1*（分店數 + 合夥人店鋪數）的商品創建請求。業務設計上，總部商品變更完成不依賴於分店同步。這裏我們使用 NSQ 消息進行數據同步。以商品創建爲例，

二、帶來的穩定性挑戰 / 問題

2.1 流量失控

2.2 流量分佈不均 

一次商品變更，流量被成千上萬倍放大，因此連鎖大商家佔據大部分的機器資源、存儲資源、流量資源。

2.3 流量水位變化感知缺失

欠缺流量水位業務操作級別監控，大流量來臨，線上定位困難，強依賴於開發測試人員對業務的瞭解程度。

2.4 支撐更大規模連鎖商家 

連鎖產品設計之初，估計沒有想到會在不久的將來就承接成千上萬個網店數量的大型連鎖商家，信息更新的時效性要求給我們帶來了巨大的挑戰。

三、設計思路 

在開始之前，我們先盤點現狀、資源，明確行動方向和目標。我們本次行動第一要義並非提供商家非凡的用戶體驗，而是解連鎖總部的操作打崩全站業務的風險。

3.1 目標 

3.2 現狀 

長鏈路操作，應用、接口、中間件、存儲未隔離，存在突發流量佔滿資源打爆應用的風險。

3.3 思路 

【短期】 

1、在調用鏈路的放大節點卡點監控，設置限流。維度：渠道、店鋪、商品等

2、在入口進行渠道限流，針對來源渠道設置限流

3、異步消息消費考慮消息合併，降消息數量

【長期】 

1、連鎖非連鎖資源隔離 

2、連鎖 vip 資源隔離 3、熱點商家檢測、隔離機制系統化

3.4 成本 

需要輸出放大場景鏈路的時序圖，清晰放大節點和公式

四、應對機制 - 控制、預警、隔離、合併、演練

基於前文輸出的鏈路梳理、鏈路應用依賴圖，我們按照核心鏈路、非核心鏈路、高頻操作、次高頻操作、低頻操作的優先級開始上手段。

4.1 流量發現 - 監控告警

【問題】

1、大流量預警時，只能通過日誌系統的接口日誌定位大流量商家，效率低下 

2、監控粒度較粗，無法快速對應大流量的業務場景

【思路】

1、流量來之前，具備預警能力。通過設置各業務場景流量和 RT 的波動閾值（90%&95%），設置監控告警。

  1. 流量衝擊期間，通過各個細分場景的 top-N 監控，快速定位熱點店鋪、商品、分組等信息，進行後續的應急處置（如擴容、隔離、控流等） 

【效果】

1、大流量問題由外部上報全部轉化爲內部發現，問題感知時效提升半小時以上

2、問題定位不強依賴特定的人員，問題定位時長下降 2/3。3、全盤呈現對業務影響範圍

4.2 流量隔離 - vip 隔離 

【問題】

1、在應用接口、存儲層，大商家和普通商家沒有獨立部署。目前的設計上，大流量商家操作會佔據大部分資源，這對全站商家的體驗極其糟糕。極端情況，甚至影響全站業務

【思路】

1、不同業務線之間的鏈路隔離或者接口獨立；對於不能拆分的接口增加來源和店鋪級別標籤區分；簡言之，非連鎖業務的商品增刪改和連鎖商品的增刪改業務鏈路拆分

2、基於總部做資源隔離（如店鋪 id、商品 id），我們的流量翻倍發生在接受消息之後的數據同步階段，消息真正消費之前拉取動態配置做消息通道隔離

【效果】

1、20 + 以上業務鏈路具備 vip 隔離能力，任何突發流量的連鎖支持鏈路隔離，在分配的資源裏面消費，其他店鋪不受流量波動干擾

4.3 流量控制 - 鏈路限流、消息合併消費

**4.3.1 鏈路限流 **

前文我們提到了設置的兩個關鍵節點：入口和流量放大點。與此而來的問題是，設置多少值相對合理？按照木桶定律，我們依據鏈路時序圖，找到當前生產環境的最短木板，確認該接口可分配給連鎖鏈路的流量資源值，按照調用的流量比例，倒推放大節點的限流閾值。

我們在設計流量控制能力，需要支持操作動作（比如商品新建和編輯在同步鏈路上有大量的接口是相同的）限流、流速控制、臨時中斷流量、強制跳過異常流量。

【效果】

高頻操作如商品、分組關聯關係增刪改具備操作動作限流能力，20 + 業務鏈路具備流控能力，加上前文的 vip 的隔離，具備隨時演練大連鎖的能力。

**  4.3.2 消息合併消費** 

業務監聽 binlog 進行業務邏輯處理，一些情況下不需要感知每一條 binlog 消息，可以按照固定時間窗口來對 binlog 消息進行合併，降低同步流量。以連鎖 c 端庫存扣減同步到分店的場景爲例，我們在扣減上面使用的是引用模式即扣總部庫存，查詢上面採用查詢分店。假定某連鎖在進行活動推廣期間，庫存扣減平均一分鐘 100 次，如果按照 10s 的時間窗口進行合併，壓縮比爲 16.7:1 左右。

4.4 應急預案 

**4.4.1 預案目標 **

讓不熟悉相關業務的同學在值班的時候可以低門檻快速執行預案，恢復生產正常服務。

**4.4.2 預案設計原則 **

1、在哪裏觀察到什麼指標可以判斷，可以執行預案；

2、如果執行，預案的干係人是誰，在哪裏操作，詳細操作步驟 

4.4.3 設計模板

 

**4.4.4 預案效果 **

預案就位之後，連鎖突發流量的止血時長由 40mins 收斂到 5 分鐘內，期間影響範圍從連鎖縮小到特定的店鋪或者商品、規格。

【不足之處】

1、目前我們的監控告警和預案之間沒有打通，相互之間的關係通過業務表徵由開發測試人員人爲維護，機動性不強

2、限流閾值是固定值，目前沒有根據集羣的負載和 rt 來動態調控

3、業務場景預警能力覆蓋待完善，目前僅具備高頻操作場景的監控大盤 當然，好的預案應該在預案平臺統一管理。針對不同程度的問題表現，值班同學一鍵執行預案，這一項目前正在建設中

4.5 生產演練 

按照以往經驗，我們做秒殺或者活動大促的全鏈路壓測，都會選擇凌晨低流量時段。本次開工之前，我突然想起之前老闆說過一句話，大意是國外用戶達到一定量，凌晨也就不再是所謂的低峯時段。回看項目整體目標，我們完全可以在具備預案能力的條件上，隨時演練。畢竟商家要做什麼操作並不會挑選時間段，也不會報備。按照小店鋪驗證 - 大連鎖試錯的思路，我們演練計劃設計如下：

**4.5.1 目標 **

當前性能數據採集 告警覆蓋完整 預案有效，執行時長 

**4.5.2 核心關注指標 **

監控告警接口 QPS、RT、機器 cpu、集羣水位、天網 error 日誌，連鎖監控大盤、消息堆積情況、中間件（存儲、緩存、定時任務等） 

4.5.3 設計維度（多熱點）

網店數量、商品數量、規格數量、併發操作店鋪數 

**4.5.4 演練效果 **

演練目前正在實施中，從 5 月中旬至今，我們累計發現問題 20+，其中有 5 次是阻塞性問題。業務鏈路優化 20+，調整預案裏面閾值近 10 次。在不間斷的演練中，逐步完善監控告警覆蓋面，最近 2 個月通過監控發現連鎖熱點操作、大盤定位業務場景、啓動預案控制線上毛刺流量，真實商家帶來的問題基本得到控制。

五、未來展望 

【短期】

連鎖業務流量監控支持自動發現異常流量，自動上報熱點（店鋪、商品），流量尖峯之後，自動回退熱點；

接入算法規則，推送開發人員適用的預案；

值班人員接收信息後，直接執行預案平臺上的預案，通過大盤觀察流量趨勢趨於平穩

【長期】

複製方案存在兩個劣勢，隨着連鎖分店數目的擴大帶來的影響直線上升。

首先，同樣的商品信息佔據大量的存儲資源，前文所提在 1k 分店數的規模連鎖中創建 1 個商品，在數據庫以及其他存儲組件中會插入 1001 條數據，其中八九成的字段信息完全一致；

其次，總部和分店數據一致性難以保障。在商家操作的體驗上來說，操作完成之後數據即時生效是基本訴求。但在大量的分店同步請求下，我們採用削峯的方式優先保障穩定性，數據同步的時長會逐步拉長。

在穩定性差、資源浪費、擴展性差的前提下，引用方案呼之欲出。引用：在連鎖模型中，總部存儲共享數據，分店存儲差異化數據。簡單而言，在強管控的連鎖模型中，複製是（1 + 分店數）個商品實體，引用是 1 個商品實體。從實現上消減分店同步流量，提升系統的穩定性。演化過程如下圖：

連鎖業務在穩定性實踐中，遇到並解決了不少本文沒有提及的問題和挑戰，如數據庫慢查打滿連接、hbase 數據熱點等，歡迎更多的朋友加入我們一起攻克問題。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XaK4eizOJo5uLgbjEumXPg

猜你喜歡