從用戶視角，線上渠道無論大小平臺其購物流程大同小異 ，基本上是對現實世界的購物流程進行了抽象復刻，這就是俗稱的電商黃金交易流程。本文不做具體模塊的設計細節講述，因為各平臺的業務屬性和發展階段不盡相同，不具備完全的參照意義，只是從產品架構的視角來剖析電商產品。

產品架構序言

人人都是產品經理流行了多年，隨著市場蓬勃的發展後，也迎來了產品經理的下半場：越來越細分，越來越2B。在面向C端的產品開發及體驗進入到瓶頸期後，B端產品開始流行起來，那麼構建高可靠、高併發、高容錯、高開放的產品架構是必然趨勢，所以產品架構這個角色正逐漸進入大眾視野，也必然會成為產品專業的燈塔。

自然情況下，一個孤立系統會由有序變為無序，即它的”熵”會不斷增加，最終寂滅。而生物可以通過和外界交互，主動進行新陳代謝，製造“負熵”來保證自身有序，繼續生存。

系統其實跟人很像，隨著功能越來越多，調用量急劇增長，整個系統變得越來越無序，如果不做合理的干預和設計，最終會導致無法維護和擴展，成為業務發展的瓶頸。架構的本質就是對系統進行有序化重構，不斷減少系統的“熵”，使系統不斷進化。

從用戶視角，線上渠道無論大小平臺其購物流程大同小異：選擇商品、加購物車、結算確認、收銀支付、生成訂單、等待收貨 ，基本上是對現實世界的購物流程進行了抽象復刻，這就是俗稱的電商黃金交易流程。雖然“看上去”一樣，但是其背後的運轉機制卻千差萬別。

本文不做具體模塊的設計細節講述，因為各平臺的業務屬性和發展階段不盡相同，不具備完全的參照意義，只是從產品架構的視角來剖析電商產品。

電商產品架構

電商正向流程核心為5大部分：推薦引擎、交易引擎、訂單引擎、履約引擎，風控引擎，在各引擎中信息流、資金流、實物流有序的流淌著，最終讓客戶如約收到完好的商品。

1. 推薦引擎

作為產品人員，更重要的是思維轉變，不在簡單的是功能和業務，善於應用數據思維來更好的滿足用戶需求，而且是動態的和用戶進行互動，再也不是完全靜態的讓用戶按照你既有的設計思路來交流。

當然推薦引擎不是電商的專利，但目前是電商撮合交易最重要的前戲，用戶體驗是否愉悅舒暢直接影響了最後的買單付款。

推薦引擎和用戶每一次的接觸都有價值，引擎都需要實時計算返回給用戶結果，用戶獲得結果後的行為，如瀏覽路徑、停留時長等都及時反饋到引擎，形成一次閉環，如此循環反覆下去。

很多反饋說，我們沒有大數據，沒有海量的信息，根本用不到推薦引擎。推薦引擎是極其複雜的系統，不做實現贅述。

2. 交易引擎

電商平臺通過合適商品、促銷優惠等手段來吸引用戶促成交易，而促成交易本質是為用戶提供一個待籤的草擬合同，合同的內容要素：商品屬性信息、訂單金額信息、促銷優惠信息、收貨地址信息、履約時效信息、運費服務費信息、發票相關信息等，這些都是建立在交易雙方自由平等的基礎上草擬的合同內容。

交易引擎從用戶視角是結算頁，而從系統視角是大腦中樞，要求的性能是幾十毫秒級，最快速度草擬合同，並且不停地根據用戶的選擇來呈現最新內容，等待著用戶點擊提交訂單那一刻。

我們以天貓的交易頁面來示意說明：

看起來像不像一頁合同，正翹首等待著用戶提交訂單那一刻完成簽字畫押。每項合同條款的規則就是產品架構要定義的，而每一個元素的具體可選的枚舉值是由合同履約方來定義，那麼一旦用戶覺得此合同條款及內容可以接受，就會按下提交訂單完成合同的簽署。

（1）條款註冊框架

合同的每一項條款背後都是一個複雜的應用系統來提供服務，比如配送時間服務，就是一個單獨的系統來維護，其可以在交易無感知情況下，更新其可以提供的配送服務。交易引擎只是提供條款服務方可以自定義合同條款及履約方法的一套條款框架自運行機制。

（2）合同模板引擎

用來根據用戶的選擇來調取條款服務方加載對應的條款內容。任意店鋪根據所有可選合同條款及內容自選需要多少供用戶選擇。那麼當用戶購買了此店鋪的商品且開始結算的時候，交易引擎就會根據店鋪已選擇的模板內容來調取相關的應用系統來加載合同具體內容展示給用戶。

（3）引擎靈活擴展

由於業務發展需求變化快，交易引擎需要更加高效的支持，那麼必須做到所有的數據交互要做到最小粒度，並提供擴展點供讓業務自定義數據來影響相關履約流程。如SKU維度入參和作為通道將自定義參數透傳。

3. 訂單引擎

交易引擎是草擬合同，而訂單則是雙方白紙黑字簽約，乙方要按照合同為用戶來履約。那麼系統究竟是如何來為用戶履約的呢？

在整個流程中需多個系統精密協作來完成一個訂單履約。大型電商大都採用微服務架構，恰好消息中間件成了解決微服務之間交互問題的重要組件，如應用耦合、異步通知、流量削鋒等問題，最終實現高性能、高可用、可伸縮、一致性的產品架構。

（1）訂單數據分發

各個系統都在嗷嗷待哺，等著訂單數據來觸發其業務流轉，這是訂單系統核心工作之一。隨著訂單在主幹道和分支業務系統之間交互流轉，其會影響訂單的流轉速度和方向，而每次的交互都可能產生新的數據，那麼保證任意時刻數據一致性是至關重要的。

分佈式系統幾乎不可能每一個時刻完全保證數據一致性，所以需要建立一個數據使用白皮書來規範數據的交互和使用。

1）主數據機制

任何提供服務的系統都要維護其邊界內核心數據的準確性，即主數據。其他系統的這部分數據需來源於主數據，尤其是強依賴的數據，無論什麼情況都首先需以主數據為準，甚至要通過反查來確認數據準確性。

主數據的數據來源也不是完全可以自己閉環，也會依賴其他系統的數據上收，所以其必然也存在數據時間差。

2）過程數據機制

典型的是訂單狀態數據，其狀態是在流轉變化的，由訂單生成到訂單完成之間會經歷大大小小的十多個狀態，而狀態數據由於是異步更新的。那麼利用消息機制進行廣播，相關係統監聽這部分消息來觸發其業務邏輯。如到了訂單到了支付完成狀態其主數據會發出支付完成消息，生產系統會監聽並消費到此消息來觸發其拆單揀貨打包配送等操作。

基於訂單狀態的變化而廣播消息是訂單數據分發的核心機制之一，另外一部分是關鍵業務數據或個性化業務特殊觸發的消息。

3）結果數據機制

訂單號是典型的結果數據，無特殊情況是不能被修改的。結果數據通常是可以信賴的，但隨著業務發展，系統中會有各種錯誤而需要數據修復，這可能會導致結果數據被修改。

4）數據版本機制

隨著用戶場景越來越豐富，業務發展越來越複雜，必然存在修改訂單數據的場景，這對分佈式的異步系統是非常挑戰的，核心原因為過程和結果數據分發到相關係統已經觸發其業務進程中，而在這期間修改數據對於已經或正在執行的業務產生致命影響。如修改收貨地址，直接影響到運費價格和履約時效的重新計算，會引發很多相關係統做出應變。

所以通常提供訂單後修改數據的能力是非常慎重的，且這部分數據通常會通過帶有版本號的數據快照來記錄，以區分和追溯。

5）數據分發機制

由於主幹道對數據時效要求極高，此時大部分是通過接口進行數據通信交互，而對其他系統並不在主幹道或對時效要求不高，可通過消息機制的方式來實現數據交互。消息隊列是基礎數據結構中的“先進先出”的一種數據機構。生活中排隊買東西，就是典型的“先進先出”。通過消息廣播數據的機制，可以解決：應用解耦、流量消峰、消息分發、異步通知等。

應用解耦：應用中有訂單系統、財務系統、倉配系統等各種業務系統。用戶創建訂單後，如果耦合調用所有相關係統，任何一個子系統出了故障，都會造成下單操作異常。當轉變成基於消息隊列的方式後，系統間調用的問題會減少很多，比如物流系統因為發生故障，需要幾分鐘來修復。

在這幾分鐘的時間裡，物流系統要處理的內存被緩存在消息隊列中，用戶的下單操作可以正常完成。當物流系統恢復後，繼續處理訂單信息即可，中單用戶感受不到物流系統的故障。提升系統的可用性。

流量消峰：

消息分發：多個服務對數據感興趣，只需要監聽同一類消息即可處理。

例如A產生數據，B對數據感興趣。如果沒有消息的隊列A每次處理完需要調用一下B服務，過了一段時間C對數據也感性，A就需要改代碼，調用B服務，調用C服務。只要有服務需要，A服務都要改動代碼，很不方便。

有了消息隊列後，A只管發送一次消息，B對消息感興趣，只需要監聽消息。C感興趣，C也去監聽消息。A服務作為基礎服務完全不需要有改動。

異步消息：有些服務間調用是異步的，例如A調用B，B需要花費很長時間執行，但是A需要知道B什麼時候可以執行完，以前一般有兩種方式，A過一段時間去調用B的查詢api查詢。或者A提供一個callback api，B執行完之後調用api通知A服務。這兩種方式都不是很優雅。

使用消息總線，可以很方便解決這個問題，A調用B服務後，只需要監聽B處理完成的消息，當B處理完成後，會發送一條消息給MQ，MQ會將此消息轉發給A服務。這樣A服務既不用循環調用B的查詢api，也不用提供callback api。同樣B服務也不用做這些操作。A服務還能及時的得到異步處理成功的消息。

（2）訂單狀態流轉

訂單狀態由訂單系統來維護，也是其最重要的數據。其幾乎控制著整個電商系統的運行流轉。

每一個狀態的變化會影響和指引訂單的信息流、實物流、資金流的流向。通常在大型電商平臺會有上百個系統來監聽訂單狀態的變化來觸發業務，作為業務開始的起點。每個狀態都是在不同的作業流程中各系統來觸發改變，並將數據回傳到訂單主數據，由訂單主數據來統一維護和調度訂單狀態，以確保數據一致性。

由於訂單狀態的重要性，其在設計之初要特別小心。個性化狀態不能加到主幹流程，可作為訂單擴展數據存在。每個狀態的流轉需有前置和後置狀態的合法性校驗，且作為可配置。如能從狀態1到2，但是不能從狀態3到2。

4. 履約引擎

所謂的訂單履約就是按照訂單上的承諾來履行和用戶的一個承諾的約定。而通常為了考慮履約成本，且由於商品所在物理上並不是一個不可拆分的單元，也即：它不是一個顆粒度最小的實體，可以進行多種形式的分解，具體如何分解根據不同的業務場景，可以進行不同形式的拆分。

（1）訂單拆分

訂單拆分是通過客戶在前臺提交的訂單，把客戶承諾的合同或履行約定，拆成貨主可生產的一系列子單，其實最核心的是拆信息、拆資金、拆實物。其實不同的平臺拆分維度很多，不做贅述。拆分後，比如說倉庫生產、配送環節、售後環節，實際上都是參照子單去進行操作。

1）實物拆分

像雙11或者618等這種大促的時候，我們的購物車可能一次性會有10個甚至有若干個東西要購買，最後發現被拆成多個訂單，什麼原因呢？

維度1：庫房位置

即使針對同一個貨主，也有可能其不同品類的商品由於儲存環境等因素會被放到不同的倉，這樣就會帶來一個拆分，這是最主要的一個維度，即庫房。

維度2：貨主不同

京東為例，京東現在有自營和POP，而POP裡邊有不同的商家，京東為了要給不同的商家進行結算，不可能在一張訂單上同時存在兩個商家的商品，這將導致京東無法跟商家做結算。因而，京東會根據商家去進行拆單。

維度3：特殊業務

有些是業務本身的特殊性，需要單獨履約。比如用戶下單買了A和B商品，但是B暫時無貨，那麼可以選擇有貨先發，那麼就會被拆開分別履約。

2）信息拆分

將原始訂單信息複製或者分攤計算到子單。

3）資金拆分

基本365天都會有不同類型的促銷。比如買個東西，滿199減 100啊（活動預熱），大家都會湊單湊到199。於是，用戶就會買食品湊夠199然後減掉100。假如用戶買了10件商品，減了100元，那麼具體這100塊錢怎麼減呢？

對於客戶來說，他們不理會平臺怎麼操作這個優惠折扣，只要這100塊錢在自己結算的時候抵扣即可。比如，用戶花了200塊錢，而實際只是收了用戶100塊錢，這就可以了。但對於平臺來說，這100塊錢並不是直接減100這樣來登記的，其不在訂單裡，是以商品的金額訂單裡，商品金額的比例分拆優惠的錢。

（2）訂單履約計劃

訂單轉移可以理解為訂單的計劃，其是為了實現訂單履約，而制定的生產方案。一個合理的生產計劃，能在保證時效承諾的前提下，起到優化生產，降低成本的作用。由於平臺越來越開放，不同的訂單來源於不同渠道，需要由不同的生產系統來履約。

那系統是如何確定以什麼方式為客戶履約？

其實訂單履約計劃是履約的一個核心環節，將待履約的訂單按照履約計劃分發到不同的庫房去生產。但對於庫房來說，不可能來了一張訂單就生產一個訂單，這樣的庫房是沒有計劃性的，容易導致生產混亂，所以訂單都會按照履約計劃成堆生產，而不是單獨去生產。

FTP，即Fulfill to Promise，即針對現貨去做履約計劃。ATP，即Availableto Promise，即針對沒有現貨去做履約計劃。未來的趨勢一定是ATP的比重會變大，就是怎麼把供應商的庫存，怎麼把在途的庫存，怎麼把一些計劃裡的東西，都能實際的用起來。

在大促期間，用戶的第一的需求是我能買到這個貨（因為便宜）。可能就對時效的要求不高，有一些東西會通過讓用戶選擇犧牲時效，而把一些在途的庫存或在供應商倉庫裡的庫存，都會去把這個東西認為是可以生產履約的庫存。最後，會讓消費者真正的能享受到這個實際的優惠。

6. 風控引擎

風控引擎需在事前、事中、事後對可疑行為進行系統或人工干預。目前由於大量黑灰產、羊毛黨、黑客們的存在，這些人已不是單打獨鬥，而是與時俱進地團隊作戰。如果系統不針對這些人或系統的行為進行防範，隨時有可能被惡意攻擊而導致系統癱瘓，從而無法給真正的用戶提供服務。因此，在電商系統裡面，風控是極其重要的系統，甚至是凌駕於其他系統之上，否則一旦發生就會產生鉅額經濟損失。

（1）內容風控

任何數據寫入的地方，那麼這兩個前端界面可輸入的地方，都會存在安全隱患。這些可輸入的內容，比如文字、圖片、視頻等存在的風險，屬於內容風險。我們需要對文字進行敏感詞過濾，對圖片進行籤黃以及對圖片上的文字進行審核，對視頻的內容也需要進行審核。

（2）系統漏洞

所有系統必然存在漏洞，只是還沒有被發現而已。營銷作弊、刷紅包、薅羊毛、推廣作弊等欺詐風險。目前黑客們每天躍躍欲試，其每天可能針對目標攻擊數次，常見的批量註冊、批量登錄、批量搶單、報文篡改等。

（3）運營漏洞

電商平臺每天各種促銷優惠活動，在促銷優惠設置及相互疊加後極有可能出現極低價格，甚至0元單的出現，那麼瞬間就會被用戶尤其黑灰產、羊毛黨等薅個精光。所以針對價格相關影響因素需要有實時監控系統，滿足預設規則及時報警，甚至系統直接鎖定。

以支付為示意，風控模型是多維度異常複雜的系統，而且都是實時性要求極高，否則會影響主流程的繼續運行。

總結

產品架構最大的特點在於，眼中沒有產品形態的概念，是需要在充分理解用戶需求的基礎上，規劃設計在生態內各角色協同完成工作的一套機制。

產品架構設計，需盡最大努力感知不到業務的存在，應只專注於數據結構、數據分發、數據協同，但卻可以提供一個舒適的、自由的、開放的環境讓業務茁壯成長。

題圖來自Unsplash，基於CC0協議

閱讀更多 人人都是產品經理 的文章

關鍵字: 美好，一直在身邊 支付 設計