有贊訂單搜索AKF架構演進之路

1、前情提要

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

1.1 分久必合

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

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

2、新的挑戰

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

• 數據量增加比預期要快不少，億級別的索引，慢查也開始出現，像一個龐然大物蠢蠢欲動。
• 爲了知足商家的一些個性搜索需求，不少搜索需求都屬於極少數會查詢到的，可是都會被加到同一個主索引中，使得主索引字段不斷增多。

3、應對

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 現狀

4、收穫

上面簡單介紹了下有贊訂單搜索 AKF 擴展之路，下面再簡單聊下過程當中的幾個意外收穫，受益良多，能夠給相似業務同窗一個能夠嘗試的參考。

4.1 可擴展性索引字段設計

以前遷移到 ES 裏就是看中 ES 的多索引檢索能力，然而多變的產品需求經過不斷加字段的模式，也會使索引變得愈來愈大，很差維護，有沒有一種可擴展性的方式，來以不變或者以小變應對需求的萬變呢。答案是確定的，list< String > 字段設計，好比目前開放了搜索擴展點給有贊雲，商家能夠自定義的創建本身的檢索字段，K 和 V 都有商家本身把控，如何作到代碼可配置化，業務代碼無感知呢，按照咱們的約定須要檢索的字段進入 list< k_v > 格式，便可作到。關於細節訂單管理系列博文之可配置化訂單搜索博文中會詳細進一步介紹。

4.2 輕量級統計

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

5、展望

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