一、前情提要

時節如流，兩年前的今天寫了有贊訂單管理的三生三世與十面埋伏，轉眼兩年過去了，這套架構發展的如何，遇到了什麼新的挑戰和收穫，今天主要來一起整理回顧下有贊訂單搜尋AKF架構演進之路。

1.1 分久必合

之前將散落在 DB 多個分片中的資料在 ES 做了一次聚合，帶來了巨大的好處，同步任務少，維護成本低。尤其是訂單遷移這一塊，之前由於是分片設計，所以當訂單觸發遷移時候，需要將資料插入新分片，確認無誤後還需要刪除老分片資料，流程繁瑣易錯，統一收攏後對於 ES 來說，各個端訂單遷移，都只是一次更新操作，無比簡單。補充介紹下訂單遷移：

• 買家訂單遷移 針對新使用者轉變為關注使用者，從系統 mock 的 buyerId 到真正分配的 buyerId 訂單的遷移。
• 賣家訂單遷移 針對店鋪模型升級，比如從微商城到零售連鎖，原門店獨立需要遷移訂單。

二、新的挑戰

然而隨著業務的不斷髮展，聚合後的索引也開始暴露各種問題。

• 資料量增長比預期要快很多，億級別的索引，慢查也開始出現，像一個龐然大物蠢蠢欲動。
• 為了滿足商家的一些個性搜尋需求，很多搜尋需求都屬於極少數會查詢到的，但是都會被加到同一個主索引中，使得主索引欄位不斷增多。

三、應對

3.1 合久必分

為了解決以上挑戰，踏上了可擴充套件性架構拆分之路。簡單介紹下有贊訂單搜尋的幾個維度：

• B 端商家單店搜尋（商家管理單店訂單）
• B 端商家總店跨分店搜尋（連鎖總店管理分店訂單）
• C 端買家跨店鋪搜尋（買家管理跨店所有訂單）

由於既要 ToB 又要 ToC ，而 B 端零售連鎖商家的引入，增加了不少複雜度，因為有總店 MU 來管理多個 BU 單元，需要跨多個店鋪查詢。無論怎麼分片，單一維度都必然存在跨分片搜尋的場景。計劃優先按資料冷熱分離來拆分，而如何區分和定義這個冷熱資料？最近一天，一月，一段時間的搜尋，都比較範，缺乏資料支撐。

念念不忘，必有迴響。

3.1.1 熱狀態索引

於是觀察了下我們的監控，發現了奇妙的規律。所有搜尋場景中，常見的按支付方式，物流型別，商品名稱，訂單型別等搜尋佔比很少，而按訂單狀態搜尋佔比最多，約 53% ，也就是一半多的搜尋流量全部來自於訂單狀態檢索。

而細化了下這 53% 的訂單狀態搜尋中，其中 3% 左右搜尋終態訂單(已完成，已關閉),其中 50% 所有流量全部都是搜熱狀態訂單(待付款，待發貨，待成團，待接單，已發貨），-_- 忽略比較亂的列舉，歷史多個版本統計合一。

不禁讓人興奮，為什麼？因為無論訂單量如何激增，處於熱狀態的訂單數不會持續暴增，因為所有訂單都會陸續流轉到終態，比如超時 30 分鐘未付款，訂單從待支付變成已關閉狀態，比如訂單發貨 7 天后，從已發貨狀態變成已完成。統計了下，熱狀態訂單總量在千萬級別，且一直比較平穩的進行流轉。

也就是說我們用這個千萬級小索引，就承接了整個訂單搜尋一半左右的流量。無論是統計，總店查詢，各種跨分片維度查詢，都可以支援。因為它是一個熱狀態訂單資料全集，包含所有分片場景，無比興奮。目前該索引已線上上平穩執行近一年。

3.1.2 時間分片索引

那麼對於那些終態訂單，資料量隨著訂單狀態流轉會變得越來越大，如何擴充套件，時間分片是個不錯的選擇，有贊訂單搜尋早期最早做的切分就是按下單時間分片，之前業務資料量小，每半年一個，到後來發展改成了每 3 個月一個，到現在即使每一個月一個索引都顯得有些龐大。具體還是要結合搜尋場景，理論上終態訂單檢索的量比較小，也可以換個思維從產品層面有個引導，比如預設只展示最近半年訂單，也是一種思路。

3.2 擴充套件依據

3.2.1 AKF 擴充套件立方體

在《架構即未來》與《架構真經》中都反覆提到這個立方體，結合我們的實際情況，確實受益匪淺，給了我們指引的方法論。

X 軸 : 關注水平的資料和服務克隆，比如主備叢集，資料完全一樣複製。克隆多個系統(加機器)負載均衡分配請求。

• 優點：成本最低，實施簡單
• 缺點：當個產品過大時，服務響應變慢
• 場景：發展初期，業務複雜度低，需要增加系統容量

Y 軸 : 關注應用中職責的劃分，比如資料業務維度拆分。比如交易庫，商品庫，會員庫拆分。

• 優點：故障隔離，提高響應時間，更聚焦
• 缺點：成本相對較高
• 場景：業務複雜，資料量大，程式碼耦合度高，團隊規模大

Z 軸 : 關注服務和資料的優先順序劃分，資料使用者維度拆分。比如常見的按使用者維度買賣家切分資料分片。

• 優點：降低故障風險，影響範圍可控，可以帶來更大的擴充套件性
• 缺點：成本最高
• 場景：使用者指數級快速增長

上面介紹的熱狀態訂單拆分其實就是朝 Y 軸方向擴充套件，當然 AKF 可擴充套件立方體的精髓就在於不要一直只在一個軸方向上擴充套件，要根據不同的業務場景，資料規模，做到有針對性的擴充套件，理論上 XYZ 軸可以做到某種程度的無限擴充套件。目前有贊訂單搜尋的總體索引架構如下，涵蓋 3 個軸方向。

3.3 現狀

四、收穫

上面簡單介紹了下有贊訂單搜尋 AKF 擴充套件之路，下面再簡單聊下過程中的幾個意外收穫，受益良多，可以給類似業務同學一個可以嘗試的參考。

4.1 可擴充套件性索引欄位設計

之前遷移到 ES 裡就是看中 ES 的多索引檢索能力，然而多變的產品需求通過不斷加欄位的模式，也會使索引變得越來越大，不好維護，有沒有一種可擴充套件性的方式，來以不變或者以小變應對需求的萬變呢。答案是肯定的，list< String > 欄位設計，比如目前開放了搜尋擴充套件點給有贊雲，商家可以自定義的建立自己的檢索欄位，K 和 V 都有商家自己把控，如何做到程式碼可配置化，業務程式碼無感知呢，按照我們的約定需要檢索的欄位進入 list< k_v > 格式，即可做到。關於細節訂單管理系列博文之可配置化訂單搜尋博文中會詳細進一步介紹。

4.2 輕量級統計

統計一直是各大公司比較重要的一塊，有贊也是，幾乎有訂單的地方都會看到各種訂單數統計，早期統計場景比較簡單，比如統計待發貨，已發貨，退款訂單等都可以通過一個 sql 或者一個指令碼任務就可以統計出來，但是隨著有贊業務發展的越來越快，比如統計一個加入擔保交易+已經完成7天內+發生退款的訂單數，普通的統計模式通過更改統計 sql ,再刷個離線資料也是能做到的，但是週期往往較長，而且不夠靈活，一旦有部分統計失敗報錯的，排查問題很困難，只能再全量重新統計。而這裡我們採用了另一種視角，用搜尋來做統計，依賴於ES搜尋預設返回的 total 作為統計值，可以無縫利用現有資料做任意維度任意組合的任意統計，隨時提需求，即用即拿，非常輕量。關於細節也會在訂單管理系列博文之配置化訂單統計博文中會做詳細進一步介紹。

五、展望

回望有贊訂單管理 4 年的心路歷程，收穫良多，配置化訂單搜尋，配置化訂單統計，配置化訂單同步系列博文也會陸續發出(配置化訂單匯出博文已發)，目前已從訂單管理順利畢業，後續主要負責有贊搜尋中臺業務線，誠邀有成長型思維，大資料思維和業務敏感度的同學加入，共建有贊搜尋中臺大業，簡歷直郵 wangye@youzan.com