當(dāng)你的電商平臺(tái)在促銷(xiāo)夜因?yàn)閹?kù)存扣減邏輯錯(cuò)誤超賣(mài) 237 單，而客服電話被打到占線，你才會(huì)真正意識(shí)到：一個(gè)能跑通的 Demo 和一個(gè)能扛住真實(shí)流量的電商平臺(tái)之間，隔著的不只是服務(wù)器配置。
電商平臺(tái)開(kāi)發(fā)不是單純的 CRUD 項(xiàng)目。它要求系統(tǒng)在峰值流量下保持?jǐn)?shù)據(jù)強(qiáng)一致、支付鏈路絕對(duì)可靠、商品狀態(tài)實(shí)時(shí)同步，且允許業(yè)務(wù)規(guī)則快速變更。大多數(shù)初次啟動(dòng)該項(xiàng)目的團(tuán)隊(duì)會(huì)低估兩個(gè)維度：狀態(tài)管理的復(fù)雜度和分布式場(chǎng)景下的故障傳播速度。本文將圍繞這兩個(gè)維度，拆解從架構(gòu)設(shè)計(jì)到核心模塊實(shí)現(xiàn)中最容易踩的坑，并給出可實(shí)施的決策框架。
架構(gòu)選擇：別再拿單體應(yīng)付高并發(fā)
一個(gè)常見(jiàn)的錯(cuò)誤假設(shè)是：“先快速上線，流量大了再拆微服務(wù)”。但電商業(yè)務(wù)的關(guān)鍵模塊——商品、庫(kù)存、訂單、支付——耦合度極高，單體架構(gòu)一旦觸及數(shù)據(jù)庫(kù)連接池上限，擴(kuò)容手段極其有限。你無(wú)法單獨(dú)擴(kuò)容庫(kù)存服務(wù)，只能整體加機(jī)器，而這會(huì)連帶拖垮那些本不需要擴(kuò)容的模塊。
怎樣分拆服務(wù)才能不把事務(wù)拆爛
拆分的第一原則不是按功能模塊切，而是按數(shù)據(jù)所有權(quán)和事務(wù)邊界切。庫(kù)存數(shù)據(jù)屬于庫(kù)存服務(wù)，訂單數(shù)據(jù)屬于訂單服務(wù)，二者之間的“扣庫(kù)存、生訂單”操作必須定義明確的事務(wù)邊界。
推薦采用聚合根模型劃分微服務(wù)：
- 庫(kù)存聚合：持有 SKU、庫(kù)存量、預(yù)占記錄。
- 訂單聚合：持有訂單狀態(tài)、訂單項(xiàng)、支付信息。
- 商品聚合：持有 SPU、SKU 基礎(chǔ)屬性、價(jià)格快照。
跨服務(wù)的操作使用最終一致性方案，不要試圖用分布式事務(wù)強(qiáng)行維持實(shí)時(shí)一致。典型模式是“預(yù)占庫(kù)存 → 創(chuàng)建訂單 → 支付確認(rèn) → 實(shí)際扣減”，通過(guò)消息隊(duì)列串聯(lián)狀態(tài)變化。
下面是一個(gè)簡(jiǎn)化的庫(kù)存預(yù)占數(shù)據(jù)庫(kù)操作示例，說(shuō)明如何在應(yīng)用層保證冪等和防超賣(mài)：
-- 預(yù)占庫(kù)存：僅當(dāng)可用庫(kù)存充足時(shí)更新預(yù)占量
UPDATE inventory
SET locked_stock = locked_stock + :qty,
version = version + 1
WHERE sku_id = :skuId
AND version = :currentVersion
AND stock - locked_stock >= :qty;必須帶上版本號(hào)（樂(lè)觀鎖）和庫(kù)存余量判斷，否則高并發(fā)下必然出現(xiàn)超賣(mài)。這個(gè) SQL 必須在庫(kù)存服務(wù)內(nèi)部執(zhí)行，不對(duì)外暴露直接操作庫(kù)存表的接口。
核心模塊設(shè)計(jì)：訂單支付鏈路的實(shí)現(xiàn)約束
訂單和支付是電商平臺(tái)的神經(jīng)中樞，設(shè)計(jì)缺陷會(huì)直接引發(fā)資金損失。常見(jiàn)的坑包括：重復(fù)支付、支付回調(diào)和訂單狀態(tài)不一致、取消訂單時(shí)庫(kù)存釋放失敗。
訂單狀態(tài)機(jī)的正確建模
不要用 status 字段存儲(chǔ)一連串的隱含狀態(tài)（如 0,1,2,3...），必須顯式建模狀態(tài)和允許的轉(zhuǎn)換路徑。一個(gè)最小可行的訂單狀態(tài)機(jī)包含：
- CREATED（已創(chuàng)建，待支付）
- PAYING（支付中，回調(diào)處理中）
- PAID（已支付）
- CANCELLED（已取消）
禁止直接從 CREATED 跳到 CANCELLED 而不處理庫(kù)存釋放。 取消動(dòng)作必須先發(fā)起庫(kù)存釋放請(qǐng)求，收到確認(rèn)后才能變更訂單狀態(tài)為 CANCELLED。如果庫(kù)存釋放失敗，訂單應(yīng)進(jìn)入“取消中”中間狀態(tài)并觸發(fā)重試。
支付回調(diào)處理的冪等性示例（偽代碼）：
// 基于支付網(wǎng)關(guān)的訂單號(hào)和支付流水號(hào)做冪等校驗(yàn)
String idempotencyKey = callback.getPaymentGatewayOrderId();
boolean processed = idempotencyService.checkAndMark(idempotencyKey);
if (processed) {
return acknowledge(); // 直接返回成功響應(yīng)，避免重復(fù)處理
}
orderService.confirmPayment(orderId, callback.getAmount());任何支付回調(diào)都必須在處理前做冪等檢查，并且支付金額必須與訂單金額強(qiáng)校驗(yàn)，防止金額篡改。
性能與容錯(cuò)：流量峰值下的降級(jí)鏈
促銷(xiāo)場(chǎng)景的流量會(huì)瞬間壓滿數(shù)據(jù)庫(kù)連接、帶寬和第三方 API 限流額度。你不能指望“加機(jī)器”來(lái)解決所有問(wèn)題，必須預(yù)定義降級(jí)路徑。
定義強(qiáng)弱依賴和降級(jí)邊界
將系統(tǒng)依賴分級(jí)：
- 強(qiáng)依賴：庫(kù)存扣減、訂單落庫(kù)。這些服務(wù)必須在任何情況下都可用，不能降級(jí)。
- 弱依賴：用戶積分獲取、推薦商品展示、實(shí)時(shí)銷(xiāo)量統(tǒng)計(jì)。這些可以在高負(fù)載時(shí)關(guān)閉或返回緩存數(shù)據(jù)。
降級(jí)策略必須提前編碼進(jìn)系統(tǒng)，而不是等事故時(shí)手動(dòng)關(guān)功能。例如，當(dāng)用戶積分服務(wù)的響應(yīng)時(shí)間超過(guò) 200ms 時(shí)，自動(dòng)跳過(guò)積分發(fā)放并記錄事件，由補(bǔ)償任務(wù)事后補(bǔ)發(fā)。
緩存策略也必須匹配業(yè)務(wù)容忍度。商品詳情頁(yè)可以承受分鐘級(jí)的緩存延遲，但庫(kù)存顯示必須近實(shí)時(shí)。你可以采用兩級(jí)緩存：本地緩存（5 秒過(guò)期）加 Redis（1 秒過(guò)期），并通過(guò)庫(kù)存服務(wù)的消息廣播刷新緩存。永遠(yuǎn)不要直接把數(shù)據(jù)庫(kù)的庫(kù)存值實(shí)時(shí)展示給用戶，所有展示都經(jīng)過(guò)緩存層。
壓測(cè)和熔斷的硬性指標(biāo)
上線前至少完成一次全鏈路壓測(cè)，并發(fā)量級(jí)按歷史峰值的 3 倍設(shè)定。熔斷器應(yīng)建立在每個(gè)服務(wù)調(diào)用鏈路上，當(dāng)錯(cuò)誤率超過(guò) 20% 或 P99 延遲超過(guò) 500ms 時(shí)主動(dòng)熔斷，并返回預(yù)定義的 fallback 響應(yīng)，而不是把請(qǐng)求堆死在隊(duì)列里。
行動(dòng)建議：從第一天就搭建的防護(hù)網(wǎng)
- 事務(wù)邊界文檔化：畫(huà)出所有跨服務(wù)的業(yè)務(wù)流程，明確每一步的數(shù)據(jù)所有權(quán)、失敗補(bǔ)償動(dòng)作和超時(shí)處理。
- 冪等性設(shè)計(jì)前置：所有涉及支付、庫(kù)存、優(yōu)惠券核銷(xiāo)的接口，必須使用冪等鍵，并在數(shù)據(jù)庫(kù)層保證唯一約束。
- 壓力測(cè)試腳本納入 CI：不要只在發(fā)版前壓測(cè)一次。將壓測(cè)腳本集成到持續(xù)交付流水線，每次大版本變更必須通過(guò)基準(zhǔn)性能測(cè)試。
- 監(jiān)控指標(biāo)不遺漏業(yè)務(wù)數(shù)據(jù)：除了 CPU、內(nèi)存，必須監(jiān)控業(yè)務(wù)指標(biāo)——待支付訂單數(shù)量、庫(kù)存預(yù)占比率、消息隊(duì)列堆積量。當(dāng)預(yù)占庫(kù)存超過(guò)實(shí)際庫(kù)存 50% 且持續(xù)超過(guò) 5 分鐘時(shí)，觸發(fā)告警。
電商平臺(tái)開(kāi)發(fā)的難點(diǎn)從來(lái)不是某個(gè)單一技術(shù)點(diǎn)，而是分布式狀態(tài)下將“看起來(lái)簡(jiǎn)單的業(yè)務(wù)操作”拆解為有序、可恢復(fù)、可觀測(cè)的機(jī)器步驟。你越早正視狀態(tài)一致性和故障傳播的控制，后期修復(fù)的成本越低。