業(yè)務(wù)背景

平臺(tái)主要售賣(mài)電子商品和少量特定的實(shí)物商品。

經(jīng)營(yíng)模式，主要分為平臺(tái)商家和自營(yíng)店，自營(yíng)店的流量占整個(gè)平臺(tái)業(yè)務(wù)的50%以上，我負(fù)責(zé)自營(yíng)店交易履約相關(guān)業(yè)務(wù)。

以前的架構(gòu)，平臺(tái)交易和履約中心是所有流量共享，在發(fā)品的時(shí)候，可以針對(duì)產(chǎn)品的歸屬（平臺(tái)商家/自營(yíng)店）進(jìn)行打標(biāo)，后續(xù)可以針對(duì)產(chǎn)品的歸屬進(jìn)行流量染色和路由。

下圖以正向交易為例

PS：下圖簡(jiǎn)化了整個(gè)交易的核心鏈路，其他域還有產(chǎn)品域、商品域、資源域、購(gòu)物車(chē)域、出行人域、憑證域、商家域等很多強(qiáng)依賴(lài)以及弱依賴(lài)的相關(guān)域，后文所提到的商品和產(chǎn)品在本文的語(yǔ)義可以理解為一樣的（實(shí)際上，在平臺(tái)業(yè)務(wù)定義上，商品為C端所屬，商品有自己的特別屬性，比如：零售價(jià)，商品詳情等；產(chǎn)品為B端所屬，產(chǎn)品也有自己的特別屬性，比如供應(yīng)商、結(jié)算價(jià)、成本價(jià)等）

這個(gè)“采購(gòu)平臺(tái)”歷史悠久，領(lǐng)域邊界模糊，代碼和技術(shù)腐化嚴(yán)重，對(duì)后續(xù)的業(yè)務(wù)支撐非常不友好。

考慮到疫情結(jié)束，業(yè)務(wù)前景向好，于是，在慎重決定下，要在原有的平臺(tái)架構(gòu)上，構(gòu)建一套涵蓋交易、履約、產(chǎn)品、資源、合約、直連、風(fēng)控、計(jì)費(fèi)結(jié)算等多個(gè)領(lǐng)域的全新供應(yīng)鏈體系，期望能在短暫時(shí)間內(nèi)，能夠?qū)⒃械臉I(yè)務(wù)流量平滑遷移到新架構(gòu)上，并且新架構(gòu)在未來(lái)能夠友好的擴(kuò)展新的業(yè)務(wù)模式，顯著提高平臺(tái)收益。

因?yàn)槠脚_(tái)主要售賣(mài)電子商品，幾乎所有的商品走的都是線上履約方式，所以，交易和履約以及逆向業(yè)務(wù)都收斂到了我這里。

關(guān)鍵詞：電商、供應(yīng)鏈、交易履約、采購(gòu)中心、訂單中心、系統(tǒng)設(shè)計(jì)、技術(shù)方案、高并發(fā)、分布式

工程難點(diǎn)

時(shí)間

Question：這個(gè)新架構(gòu)是倒排需求，第一版迭代周期只有三個(gè)月。在保證工程質(zhì)量的情況下，需要在三個(gè)月之內(nèi)完成：需求評(píng)審 - 技術(shù)方案評(píng)審 - 研發(fā) - 自測(cè) - 聯(lián)調(diào) - QA - 上線 - 切流，并且能夠完全承接舊系統(tǒng)的業(yè)務(wù)流量。

Answer：敏捷開(kāi)發(fā)、做好規(guī)劃、風(fēng)險(xiǎn)把控、人力協(xié)調(diào)、視死如歸、我是牛馬。

業(yè)務(wù)

Question：舊系統(tǒng)的業(yè)務(wù)架構(gòu)單一，新架構(gòu)的業(yè)務(wù)復(fù)雜多變，未來(lái)預(yù)期很高，所以在系統(tǒng)設(shè)計(jì)之初，就需要具備一定的擴(kuò)展性，在領(lǐng)域設(shè)計(jì)時(shí)，也要處理好領(lǐng)域邊界和領(lǐng)域模型的建設(shè)。

Answer：深學(xué)平臺(tái)全鏈路業(yè)務(wù)；廣學(xué)行業(yè)內(nèi)相關(guān)業(yè)務(wù)和解決方案；向前輩求學(xué)問(wèn)道，無(wú)論如何先把東西學(xué)到手。

技術(shù)

Question：系統(tǒng)的流量和未來(lái)預(yù)期的流量很高，每天增量的訂單就有千萬(wàn)級(jí)別。

1. 新系統(tǒng)上線之后，如何將舊系統(tǒng)的數(shù)據(jù)和流量平滑遷移至新系統(tǒng)？
2. 面對(duì)復(fù)雜業(yè)務(wù)架構(gòu)，如何保證系統(tǒng)具備良好的業(yè)務(wù)擴(kuò)展性？
3. 面對(duì)復(fù)雜技術(shù)架構(gòu)，如何保證訂單數(shù)據(jù)的一致性？產(chǎn)品數(shù)據(jù)的一致性？
4. 流量會(huì)集中在某一天或一天的某段時(shí)間，如何保證系統(tǒng)的可用性和穩(wěn)定性？

Answer：具備領(lǐng)域驅(qū)動(dòng)知識(shí)、分布式解決方案、行業(yè)解決方案、高并發(fā)場(chǎng)景解決方案；深入理解集團(tuán)中間件。

組織

Question：平臺(tái)側(cè)的團(tuán)隊(duì)變動(dòng)頻繁，一套平臺(tái)工程經(jīng)歷了十幾個(gè)團(tuán)隊(duì)，業(yè)務(wù)邏輯不透明，平臺(tái)側(cè)的研發(fā)同學(xué)新人居多，接入很漫長(zhǎng)，心理壓力大，再加上組織架構(gòu)的隔離性比較高，平臺(tái)側(cè)的問(wèn)題很難推動(dòng)。

Answer：提供足夠的情緒價(jià)值、夸她、愛(ài)她、包容她；交付進(jìn)度阻塞必須風(fēng)險(xiǎn)上升，一切以解決問(wèn)題為主。

業(yè)務(wù)演進(jìn)

之前的“采購(gòu)平臺(tái)”僅支持平臺(tái)自營(yíng)店，新的架構(gòu)希望能夠擴(kuò)展業(yè)務(wù)模式，所以在原有的業(yè)務(wù)模式上，給新架構(gòu)設(shè)定了三個(gè)目標(biāo)。

目標(biāo)核心

1. 打通供應(yīng)鏈交易履約逆向鏈路，完成流量的平滑遷移
2. 在原有的業(yè)務(wù)基礎(chǔ)上，具備橫向縱向業(yè)務(wù)領(lǐng)域的擴(kuò)展
   a. 在原有類(lèi)目的基礎(chǔ)上，能夠自由擴(kuò)展更多的業(yè)務(wù)類(lèi)目
   b. 在原有銷(xiāo)售模式的基礎(chǔ)上，能夠擴(kuò)展更多的銷(xiāo)售模式（直銷(xiāo)、分銷(xiāo)、代理等）
   c. 在原有業(yè)務(wù)模式的基礎(chǔ)上，能夠擴(kuò)展更多的業(yè)務(wù)模式（秒殺、二次預(yù)約、囤貨、預(yù)售等）
   d. 在原有支付體系的基礎(chǔ)上，打造域內(nèi)的資金池等體系（預(yù)付款、授信等）
3. 能夠支持線上計(jì)費(fèi)結(jié)算，完全替代線下手工對(duì)賬體系

演進(jìn)階段

在初步設(shè)定好新架構(gòu)的目標(biāo)之后，規(guī)劃了一下業(yè)務(wù)演進(jìn)的方向，大致分為了 3 個(gè)階段。

• 第一個(gè)階段：構(gòu)建高可用、高擴(kuò)展的技術(shù)架構(gòu)，并支持單業(yè)務(wù)類(lèi)目單銷(xiāo)售單支付模式，完成上線切流。
• 第二個(gè)階段：持續(xù)建設(shè)系統(tǒng)的穩(wěn)定性，并支持單業(yè)務(wù)類(lèi)目多銷(xiāo)售模式單支付模式。
• 第三個(gè)階段：針對(duì)核心業(yè)務(wù)進(jìn)行極致優(yōu)化，并推動(dòng)系統(tǒng)平臺(tái)化發(fā)展，支持多業(yè)務(wù)類(lèi)目多銷(xiāo)售模式多支付模式。

收益體現(xiàn)

新架構(gòu)的收益總結(jié)

經(jīng)濟(jì)收益：

1. 針對(duì)自營(yíng)店，2023年的GMV大概為 n 億元，經(jīng)過(guò)業(yè)務(wù)戰(zhàn)略的調(diào)整和完善，2024年的GMV保守估計(jì)已達(dá) 2n+ 億元，完成了自營(yíng)店收益跨越式增長(zhǎng)。
2. 基于業(yè)務(wù)資源背景，打通分銷(xiāo)銷(xiāo)售渠道，一年入駐 分銷(xiāo)商/代理商 x 家，接入 核銷(xiāo)商/系統(tǒng)商/供應(yīng)商 y 家，資源數(shù)量級(jí)涌進(jìn)國(guó)內(nèi)行業(yè)前列。
3. 分銷(xiāo)和代理渠道的GMV在一年內(nèi)已遠(yuǎn)超自營(yíng)店2023年的GMV，2024年保守估計(jì)已達(dá) 1.3n+ 億元，成為平臺(tái)經(jīng)濟(jì)收益新來(lái)源。

技術(shù)收益：

1. 解決了高并發(fā)下的系統(tǒng)可用、數(shù)據(jù)一致等問(wèn)題，解鎖集團(tuán)域內(nèi)中間件新玩法。
2. 沉淀出一套完整的交易履約技術(shù)方案、系統(tǒng)治理方案以及業(yè)務(wù)領(lǐng)域架構(gòu)方案，實(shí)現(xiàn)域內(nèi)相關(guān)業(yè)務(wù)可復(fù)用能力。

團(tuán)隊(duì)收益：

1. 項(xiàng)目初期，周末加班雙倍工資，項(xiàng)目穩(wěn)定上線之后，每個(gè)人獲得1～3個(gè)月工資的項(xiàng)目獎(jiǎng)金，提升了團(tuán)隊(duì)人員流動(dòng)的穩(wěn)定性。
2. 團(tuán)隊(duì)在前3個(gè)月一直保持007高強(qiáng)度的工作節(jié)奏，無(wú)一人缺席，倡導(dǎo)的狼性文化得到驗(yàn)證，提升了團(tuán)隊(duì)的凝聚力。
3. 業(yè)務(wù)相關(guān)數(shù)據(jù)成指數(shù)級(jí)增長(zhǎng)，帶來(lái)了當(dāng)下和未來(lái)及其可觀的收益，供應(yīng)鏈側(cè)研發(fā)團(tuán)隊(duì)由 n 人，已經(jīng)擴(kuò)展到目前的 2n+ 人。

業(yè)務(wù)設(shè)計(jì)

交易角色

1. 對(duì)于整個(gè)平臺(tái)的交易角色，可以劃分為：C - B - P - S
2. 對(duì)于整個(gè)供應(yīng)鏈領(lǐng)域，可以劃分為：B - P - S
   C：用戶｜B：自營(yíng)店/分銷(xiāo)商/代理商｜P：采購(gòu)平臺(tái)主體｜S：供應(yīng)商

交易屬性

1. 對(duì)于自營(yíng)店，在 B - P 階段的交易，本質(zhì)上是虛擬交易。
2. 對(duì)于分銷(xiāo)商和代理商，是真實(shí)支付的線上交易。

交易階段

在供應(yīng)鏈交易這個(gè)領(lǐng)域，是兩階段交易：BP & PS。流量從 B 端過(guò)來(lái)，可能會(huì)涉及到拆單的操作，映射到系統(tǒng)設(shè)計(jì)上，BP 階段產(chǎn)生的訂單定義為主單（BP 單），主單拆成的訂單，也就是 PS 階段產(chǎn)生的訂單，定義為子單（PS 單）。

領(lǐng)域設(shè)計(jì)

在設(shè)計(jì)之初，需要將各個(gè)領(lǐng)域邊界劃分清晰，方便后續(xù)的系統(tǒng)迭代和架構(gòu)升級(jí)。

領(lǐng)域架構(gòu)

整個(gè)新團(tuán)隊(duì)，職責(zé)劃分非常明確和清晰，在經(jīng)過(guò)數(shù)次的“腦暴”后，領(lǐng)域框架選型成了最大的問(wèn)題。以前研究過(guò)Axon幾年，并且有過(guò)Axon在大型區(qū)塊鏈交易系統(tǒng)，從0到1的實(shí)戰(zhàn)經(jīng)驗(yàn)，所以在領(lǐng)域架構(gòu)選型上，首推Axon作為整個(gè)團(tuán)隊(duì)的領(lǐng)域基礎(chǔ)框架。

但是，在 “技術(shù)落地討論會(huì)” 中，發(fā)現(xiàn)團(tuán)隊(duì)內(nèi)的同學(xué)們，技術(shù)分散嚴(yán)重，只有一半是做過(guò)Java相關(guān)業(yè)務(wù)的，業(yè)務(wù)分散也很?chē)?yán)重，只有一半是做過(guò)/了解過(guò)電商相關(guān)業(yè)務(wù)的。因此，大家對(duì)行業(yè)的業(yè)務(wù)領(lǐng)域和這些領(lǐng)域驅(qū)動(dòng)框架，了解的不是特別多。

為了讓項(xiàng)目盡快落地，在領(lǐng)域框架設(shè)計(jì)上，并沒(méi)有嚴(yán)格采用DDD的思想，但是在系統(tǒng)設(shè)計(jì)上參考了Cola這類(lèi)框架的整潔結(jié)構(gòu)和Axon這類(lèi)框架的事件驅(qū)動(dòng)設(shè)計(jì)，結(jié)合平臺(tái)的業(yè)務(wù)，將“腦暴”后的領(lǐng)域模型，不斷推演，最后將傳統(tǒng)的領(lǐng)域驅(qū)動(dòng)框架進(jìn)行抽象和精簡(jiǎn)，就有了現(xiàn)在的基礎(chǔ)領(lǐng)域架構(gòu)。

scc-starter是在大學(xué)開(kāi)源的一套適配器組件的域內(nèi)升級(jí)版，方便靈活，一鍵啟動(dòng)。

領(lǐng)域劃分

最開(kāi)始綠色的領(lǐng)域，都是打散到紅色領(lǐng)域中，第一版上線以后，發(fā)現(xiàn)各個(gè)領(lǐng)域隨著業(yè)務(wù)迭代愈發(fā)臃腫，于是及時(shí)做了調(diào)整。
核心域：訂單域，支付域，資金域，履約域，退款域

支撐域：產(chǎn)品域，合約域，超時(shí)域，消息域

領(lǐng)域能力

訂單域：預(yù)下單、收單

支付域：正向付款、逆向扣款等

資金域：資金流

履約域：預(yù)定資源、確定資源、服務(wù)完成

退款域：申請(qǐng)退款、快速退、強(qiáng)制退、退款回調(diào)

產(chǎn)品域：產(chǎn)品查詢、庫(kù)存扣減、庫(kù)存回補(bǔ)、拆單、合單、Hold 單

合約域：合約信息查詢、合約合法性校驗(yàn)

超時(shí)域：集團(tuán)內(nèi)部通用的技術(shù)解決方案，旨在解決分布式事務(wù)（tcc）、消息丟失、任務(wù)補(bǔ)償?shù)?/p>

消息域：領(lǐng)域事件驅(qū)動(dòng)

領(lǐng)域事件

領(lǐng)域模型

實(shí)體對(duì)象：采購(gòu)單、資金單、履約單、退款單、預(yù)付款信息、預(yù)付款詳情、調(diào)度任務(wù)

值對(duì)象：聯(lián)系人信息、賬戶信息、合作關(guān)系、分銷(xiāo)商與供應(yīng)商信息、操作日志、退款規(guī)則、POI、憑證信息、出行人信息以及渠道信息

數(shù)據(jù)模型設(shè)計(jì)是整個(gè)系統(tǒng)最核心的環(huán)節(jié)，設(shè)計(jì)之初要保證數(shù)據(jù)結(jié)構(gòu)具備足夠的擴(kuò)展性和容忍性。比如訂單是否需要聚合、訂單模型是否能夠支撐未來(lái)的業(yè)務(wù)模式等。

訂單狀態(tài)

訂單態(tài)：訂單初始化 - 訂單交易中 - 訂單交易完成 - 訂單交易關(guān)閉

履約態(tài)：履約單初始化 - 履約單已創(chuàng)建 - 供應(yīng)商創(chuàng)單成功/失敗 - 待核銷(xiāo) - 部分核銷(xiāo) - 全部核銷(xiāo) - 履約完成

支付態(tài)：未支付 - 已支付

退款態(tài)：未退款 - 退款單初始化 - 已申請(qǐng)退款 - 同意/拒絕退款 - 退款關(guān)閉 - 退款成功

資金態(tài)：未付款 - 已付款 - 付款成功/失敗 - 分賬完成/失敗 - 結(jié)算完成/失敗 - 交易完成/失敗

系統(tǒng)設(shè)計(jì)

平臺(tái)全鏈路交易履約時(shí)序圖

新架構(gòu)的預(yù)期流程，如下面的時(shí)序圖所示（這是相對(duì)復(fù)雜的一種情況）
這個(gè)全鏈路時(shí)序圖，屏蔽了很多交易系統(tǒng)弱依賴(lài)應(yīng)用，希望能讓讀者輕松看懂整體的交易履約流程。

整體設(shè)計(jì)圖

整體是兩階段交易，正向交易主單驅(qū)動(dòng)子單，逆向履約子單推動(dòng)主單，從下圖來(lái)看：

第一階段：收單 - 支付，歸屬于BP交易范疇，因?yàn)槠脚_(tái)和分銷(xiāo)商合作的性質(zhì)不同，支付能力基于第三方支付平臺(tái)和域內(nèi)資金池等方式，但是整體而言都算是實(shí)時(shí)支付。

第二階段：預(yù)訂資源階段本質(zhì)上就是系統(tǒng)商創(chuàng)單的階段，如果創(chuàng)單成功，會(huì)記錄資金流水，同時(shí)也會(huì)給計(jì)費(fèi)結(jié)算平臺(tái)發(fā)送計(jì)費(fèi)事件。這里其實(shí)也是基于平臺(tái)和系統(tǒng)商合作的性質(zhì)，因?yàn)槠脚_(tái)和所有的系統(tǒng)商資金都是T+1月結(jié)。

解決方案

收單服務(wù)治理

收單服務(wù)接口，是整個(gè)交易平臺(tái)的流量口子，在收單過(guò)程中，會(huì)和域內(nèi)域外多個(gè)服務(wù)進(jìn)行交互，涉及到各種復(fù)雜的業(yè)務(wù)邏輯。比如合約服務(wù)、產(chǎn)品中心和直連網(wǎng)關(guān)等，這些服務(wù)都是交易平臺(tái)強(qiáng)依賴(lài)的，這些服務(wù)不可用，也會(huì)導(dǎo)致交易平臺(tái)不可用，本地基本上是沒(méi)有什么降級(jí)方案的。

除了本地服務(wù)基本的代碼優(yōu)化（減少調(diào)用鏈路，優(yōu)化代碼邏輯執(zhí)行順序，將阻斷校驗(yàn)流程前置，優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法，優(yōu)化查詢邏輯，減少I(mǎi)O次數(shù)，利用本地緩存等），合約服務(wù)接口性能、產(chǎn)品中心服務(wù)接口性能以及第三方支付平臺(tái)的接口性能，成為了影響收單服務(wù)接口性能的重要因素。

1. 合約服務(wù)：查詢合約信息等
2. 產(chǎn)品中心：查詢產(chǎn)品信息、扣減庫(kù)存、回補(bǔ)庫(kù)存等
3. 支付能力：支付寶代扣（查、付、退、取消、校驗(yàn)等）

第一階段開(kāi)發(fā)周期短，核心是如期交付上線，接住舊系統(tǒng)的線上流量，為后續(xù)的業(yè)務(wù)擴(kuò)展帶來(lái)可能。根據(jù)已有大KA的要求，收單RT在6秒之內(nèi)，收單服務(wù)即為可用，上線之后，收單服務(wù)的RT常態(tài)化Max為5秒。

治理前后各項(xiàng)指標(biāo)概要：

1. 總響應(yīng)時(shí)間（RT）顯著提升：
   治理前：4700ms
   治理后：250ms
   治理效果：提升了18倍
2. 本地計(jì)算響應(yīng)時(shí)間（RT）顯著縮短：
   治理前：200ms
   治理后：30ms
   治理效果：縮短了6倍
3. 查詢產(chǎn)品信息響應(yīng)時(shí)間（RT）大幅減少：
   治理前：800ms
   治理后：70ms
   治理效果：提升了11倍
4. 查詢合約信息響應(yīng)時(shí)間（RT）大幅降低：
   治理前：1200ms
   治理后：60ms
   治理效果：提升了20倍
5. 校驗(yàn)支付能力響應(yīng)時(shí)間（RT）極大縮短：
   治理前：500ms
   治理后：10ms
   治理效果：提升了50倍
6. 預(yù)占庫(kù)存響應(yīng)時(shí)間（RT）顯著減少：
   治理前：2000ms
   治理后：80ms
   治理效果：提升了25倍
7. 單機(jī)QPS（每秒查詢次數(shù)）大幅提高：
   治理前：40qps
   治理后：800qps
   治理效果：提升了20倍
8. 集群Max QPS顯著提升：
   治理前：1100
   治理后：4000
   治理效果：提升了4倍
9. 收單Max QPS顯著提升：
   治理前：300
   治理后：1200
   治理效果：提升了4倍
10. 服務(wù)器數(shù)量?jī)?yōu)化：
    治理前：40臺(tái)（4C8G）
    治理后：21臺(tái)（4C12G），包括10臺(tái)、8臺(tái)和3臺(tái)不同配置
    治理效果：服務(wù)器數(shù)量減少，配置提升。

庫(kù)存扣減

https://blog.csdn.net/CSDN_SAVIOR/article/details/142887066

產(chǎn)品查詢

https://issavior.blog.csdn.net/article/details/140734888

支付能力

正式創(chuàng)單之前，會(huì)進(jìn)行支付校驗(yàn)，域外的支付服務(wù)，非常不穩(wěn)定，因此，增加了重試、補(bǔ)償?shù)热蒎e(cuò)手段。為了徹底解決這種問(wèn)題，提高成單率，平臺(tái)在域內(nèi)打造資金池，分銷(xiāo)商可在平臺(tái)預(yù)付款，每次支付從資金池扣減。

流量平滑遷移

https://issavior.blog.csdn.net/article/details/141201666

業(yè)務(wù)擴(kuò)展能力

https://issavior.blog.csdn.net/article/details/140891892
https://issavior.blog.csdn.net/article/details/140903785

系統(tǒng)數(shù)據(jù)治理

訂單數(shù)據(jù)一致性

https://issavior.blog.csdn.net/article/details/141275722

訂單全局唯一ID

https://issavior.blog.csdn.net/article/details/141279168

存量數(shù)據(jù)

針對(duì)舊采購(gòu)系統(tǒng)的訂單數(shù)據(jù)，新交易系統(tǒng)不必感知。

舊系統(tǒng)的存量數(shù)據(jù)和新系統(tǒng)的增量數(shù)據(jù)由買(mǎi)家域和賣(mài)家域自行處理這些數(shù)據(jù)即可。處理數(shù)據(jù)需要注意數(shù)據(jù)的一致性，在平滑切流的過(guò)程中，新系統(tǒng)可能會(huì)存在舊系統(tǒng)的數(shù)據(jù)，域外在同步數(shù)據(jù)的時(shí)候可以做一層清洗和過(guò)濾。

數(shù)據(jù)的分片

隨著分銷(xiāo)商和供應(yīng)商資源的不斷涌入，流量在一段時(shí)間內(nèi)成指數(shù)增長(zhǎng)，龐大的訂單數(shù)據(jù)該如何存儲(chǔ)？這里的方案是采用分庫(kù)分表（未分區(qū)）和讀寫(xiě)分離架構(gòu)，將數(shù)據(jù)和流量打散。

將采購(gòu)單表、資金單表、履約單表、任務(wù)表進(jìn)行水平拆分，設(shè)計(jì)到相關(guān)的技術(shù)是TDDL，核心原理和Sharding-JDBC差不多。

拆分規(guī)則

因?yàn)椴少?gòu)單數(shù)據(jù)不涉及到實(shí)時(shí)查詢，所以根據(jù)訂單ID直接取模即可。

分片規(guī)則

根據(jù)以前業(yè)務(wù)的數(shù)據(jù)規(guī)模以及業(yè)務(wù)方針對(duì)未來(lái)的流量期望，每天的增量訂單會(huì)有千萬(wàn)級(jí)別。

根據(jù)集團(tuán)的數(shù)據(jù)庫(kù)和存儲(chǔ)引擎性能，最終采取的分庫(kù)分表方案如下：
8庫(kù) - 32張表/庫(kù) - 256張表

數(shù)據(jù)清理

供應(yīng)鏈交易履約平臺(tái)的訂單的生命周期比較短，目前已知訂單最長(zhǎng)的生命周期是一個(gè)月，所以可以將數(shù)月之前的數(shù)據(jù)同步到冷庫(kù)中。

讀寫(xiě)分離

準(zhǔn)確的說(shuō)，讀寫(xiě)分離在交易系統(tǒng)上的實(shí)踐是有風(fēng)險(xiǎn)的，交易系統(tǒng)大多為實(shí)時(shí)查詢，如果因?yàn)榇笫聞?wù)、網(wǎng)絡(luò)抖動(dòng)等原因，導(dǎo)致從庫(kù)的數(shù)據(jù)同步有延時(shí)，那對(duì)于交易系統(tǒng)的穩(wěn)定性是非常致命的。

這里讀寫(xiě)分離主要是用在一些域內(nèi)非核心應(yīng)用（小二系統(tǒng)），給這些非核心且關(guān)鍵的業(yè)務(wù)透出一個(gè)口子，做一些必要操作，但是也要注意這些接口的穩(wěn)定性，比如限流措施等。交易等核心業(yè)務(wù)，對(duì)于數(shù)據(jù)的實(shí)時(shí)性要求比較高，讀寫(xiě)都需要在master節(jié)點(diǎn)上。

但是這樣的設(shè)計(jì)顯然不合理，應(yīng)該要將這些依賴(lài)交易系統(tǒng)的非核心應(yīng)用全部干掉，讓他們通過(guò)其他渠道去獲取數(shù)據(jù)，以此來(lái)提升交易系統(tǒng)的穩(wěn)定性。

系統(tǒng)治理

流量分組

1. 交易平臺(tái)將自營(yíng)店流量和分銷(xiāo)/代理流量進(jìn)行分組，避免銷(xiāo)售渠道相互影響。
2. 全鏈路服務(wù)將交易的流量單獨(dú)隔離開(kāi)，避免非核心業(yè)務(wù)影響到交易鏈路。
   異常監(jiān)控
   針對(duì)系統(tǒng)和業(yè)務(wù)級(jí)別的異常，劃分嚴(yán)重等級(jí)，做聚合告警（整合行業(yè)AI大模型，做智能監(jiān)控），通知運(yùn)營(yíng)和研發(fā)同學(xué)，及時(shí)處理。

發(fā)布流程

上線之前，嚴(yán)格按著發(fā)布流程來(lái)，研發(fā) - 自測(cè) - QA - CR - 安全環(huán)境回歸 - 觀察 - 灰度發(fā)布 - 觀察 - 分批上線 - 觀察，而且CR務(wù)必經(jīng)過(guò)Owner，血的教訓(xùn)。

埋點(diǎn)日志

針對(duì)各個(gè)交易節(jié)點(diǎn)，做全鏈路trace埋點(diǎn)，除了排查問(wèn)題之外，還可以溯源，很多次，系統(tǒng)商服務(wù)的問(wèn)題，無(wú)法追溯，導(dǎo)致結(jié)算出問(wèn)題。

風(fēng)控巡檢

上線之后，發(fā)現(xiàn)系統(tǒng)商這服務(wù)說(shuō)掛就掛，很不穩(wěn)定，用風(fēng)控巡檢來(lái)對(duì)所有的系統(tǒng)商服務(wù)接口做探針探活，有問(wèn)題就熔斷掉異常系統(tǒng)商服務(wù)，服務(wù)存活后，再恢復(fù)系統(tǒng)商服務(wù)能力。

熔斷限流

對(duì)外的接口，上線之前要進(jìn)行服務(wù)接口進(jìn)行壓測(cè)，并根據(jù)壓測(cè)結(jié)果，設(shè)置合理的限流閾值，防止服務(wù)掛掉。

日常工具

常見(jiàn)的不可抗拒的問(wèn)題，需要制定相應(yīng)的工具，遇到問(wèn)題時(shí)可以提供給運(yùn)營(yíng)或者研發(fā)同學(xué)。

緊急預(yù)案

如果出現(xiàn)線上的問(wèn)題，需要有止血措施，比如在上線之前，可以針對(duì)改動(dòng)點(diǎn)增加動(dòng)態(tài)配置開(kāi)關(guān)，如果出現(xiàn)問(wèn)題，可以秒級(jí)止血，即在1秒內(nèi)關(guān)閉上線功能，然后在進(jìn)行回滾以及問(wèn)題排查等措施。

問(wèn)題復(fù)盤(pán)

出現(xiàn)問(wèn)題不要怕，要及時(shí)復(fù)盤(pán)、總結(jié)，不能秉持“少做少錯(cuò)，不做不錯(cuò)”的態(tài)度。

節(jié)前準(zhǔn)備

針對(duì)于預(yù)知的流量（節(jié)假日、營(yíng)銷(xiāo)活動(dòng)等）要做好擴(kuò)容，值班人員必須保證問(wèn)題響應(yīng)效率和解決質(zhì)量。

風(fēng)險(xiǎn)排查

成單率、消息堆積、磁盤(pán)內(nèi)存、ES容量、數(shù)據(jù)同步延遲、慢SQL等。

提效秘籍

自己這幾年用的還不錯(cuò)的復(fù)盤(pán)計(jì)劃，分享一下，希望能對(duì)大家有所幫助。

結(jié)束語(yǔ)

本文對(duì)“交易履約平臺(tái)”做了簡(jiǎn)單敘述，主要從宏觀視角概述了繁雜業(yè)務(wù)中僅一條相對(duì)復(fù)雜的“交易”業(yè)務(wù)線的相關(guān)要點(diǎn)，當(dāng)然，履約和逆向業(yè)務(wù)也是非常的好玩并且具備難點(diǎn)和技術(shù)挑戰(zhàn)，若有機(jī)會(huì)，我將分享這些領(lǐng)域的心得。

期望本文能為初涉電商交易領(lǐng)域的小伙伴們提供一些有價(jià)值的啟發(fā)。同時(shí)，希望各位老師不吝批評(píng)指正，指出文中的瑕疵與待改進(jìn)之處。更期盼大家在評(píng)論區(qū)踴躍留言，共同交流心得、探討問(wèn)題，攜手促進(jìn)我們的成長(zhǎng)與進(jìn)步。