起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識解密「零售」系列（二）：產品架構
從用戶視角，線上渠道無論大小平臺其購物流程大同小異 ，基本上是對現(xiàn)實世界的購物流程進行了抽象復刻，這就是俗稱的電商黃金交易流程。本文不做具體模塊的設計細節(jié)講述，因為各平臺的業(yè)務屬性和發(fā)展階段不盡相同，不具備完全的參照意義，只是從產品架構的視角來剖析電商產品。
產品架構序言
人人都是產品經理流行了多年，隨著市場蓬勃的發(fā)展后，也迎來了產品經理的下半場：越來越細分，越來越2B。在面向C端的產品開發(fā)及體驗進入到瓶頸期后，B端產品開始流行起來，那么構建高可靠、高并發(fā)、高容錯、高開放的產品架構是必然趨勢，所以產品架構這個角色正逐漸進入大眾視野，也必然會成為產品專業(yè)的燈塔。
自然情況下，一個孤立系統(tǒng)會由有序變?yōu)闊o序，即它的”熵”會不斷增加，最終寂滅。而生物可以通過和外界交互，主動進行新陳代謝，制造“負熵”來保證自身有序，繼續(xù)生存。
系統(tǒng)其實跟人很像，隨著功能越來越多，調用量急劇增長，整個系統(tǒng)變得越來越無序，如果不做合理的干預和設計，最終會導致無法維護和擴展，成為業(yè)務發(fā)展的瓶頸。架構的本質就是對系統(tǒng)進行有序化重構，不斷減少系統(tǒng)的“熵”，使系統(tǒng)不斷進化。
從用戶視角，線上渠道無論大小平臺其購物流程大同小異：選擇商品、加購物車、結算確認、收銀支付、生成訂單、等待收貨 ，基本上是對現(xiàn)實世界的購物流程進行了抽象復刻，這就是俗稱的電商黃金交易流程。雖然“看上去”一樣，但是其背后的運轉機制卻千差萬別。
本文不做具體模塊的設計細節(jié)講述，因為各平臺的業(yè)務屬性和發(fā)展階段不盡相同，不具備完全的參照意義，只是從產品架構的視角來剖析電商產品。
電商產品架構
電商正向流程核心為5大部分：推薦引擎、交易引擎、訂單引擎、履約引擎，風控引擎，在各引擎中信息流、資金流、實物流有序的流淌著，最終讓客戶如約收到完好的商品。
1.?推薦引擎
作為產品人員，更重要的是思維轉變，不在簡單的是功能和業(yè)務，善于應用數(shù)據(jù)思維來更好的滿足用戶需求，而且是動態(tài)的和用戶進行互動，再也不是完全靜態(tài)的讓用戶按照你既有的設計思路來交流。
當然推薦引擎不是電商的專利，但目前是電商撮合交易最重要的前戲，用戶體驗是否愉悅舒暢直接影響了最后的買單付款。
推薦引擎和用戶每一次的接觸都有價值，引擎都需要實時計算返回給用戶結果，用戶獲得結果后的行為，如瀏覽路徑、停留時長等都及時反饋到引擎，形成一次閉環(huán)，如此循環(huán)反復下去。
很多反饋說，我們沒有大數(shù)據(jù)，沒有海量的信息，根本用不到推薦引擎。推薦引擎是極其復雜的系統(tǒng)，不做實現(xiàn)贅述。
2.?交易引擎
電商平臺通過合適商品、促銷優(yōu)惠等手段來吸引用戶促成交易，而促成交易本質是為用戶提供一個待簽的草擬合同，合同的內容要素：商品屬性信息、訂單金額信息、促銷優(yōu)惠信息、收貨地址信息、履約時效信息、運費服務費信息、發(fā)票相關信息等，這些都是建立在交易雙方自由平等的基礎上草擬的合同內容。
交易引擎從用戶視角是結算頁，而從系統(tǒng)視角是大腦中樞，要求的性能是幾十毫秒級，最快速度草擬合同，并且不停地根據(jù)用戶的選擇來呈現(xiàn)最新內容，等待著用戶點擊提交訂單那一刻。
我們以天貓的交易頁面來示意說明：
看起來像不像一頁合同，正翹首等待著用戶提交訂單那一刻完成簽字畫押。每項合同條款的規(guī)則就是產品架構要定義的，而每一個元素的具體可選的枚舉值是由合同履約方來定義，那么一旦用戶覺得此合同條款及內容可以接受，就會按下提交訂單完成合同的簽署。
（1）條款注冊框架
合同的每一項條款背后都是一個復雜的應用系統(tǒng)來提供服務，比如配送時間服務，就是一個單獨的系統(tǒng)來維護，其可以在交易無感知情況下，更新其可以提供的配送服務。交易引擎只是提供條款服務方可以自定義合同條款及履約方法的一套條款框架自運行機制。
（2）合同模板引擎
用來根據(jù)用戶的選擇來調取條款服務方加載對應的條款內容。任意店鋪根據(jù)所有可選合同條款及內容自選需要多少供用戶選擇。那么當用戶購買了此店鋪的商品且開始結算的時候，交易引擎就會根據(jù)店鋪已選擇的模板內容來調取相關的應用系統(tǒng)來加載合同具體內容展示給用戶。
（3）引擎靈活擴展
由于業(yè)務發(fā)展需求變化快，交易引擎需要更加高效的支持，那么必須做到所有的數(shù)據(jù)交互要做到最小粒度，并提供擴展點供讓業(yè)務自定義數(shù)據(jù)來影響相關履約流程。如SKU維度入?yún)⒑妥鳛橥ǖ缹⒆远x參數(shù)透傳。
3. 訂單引擎
交易引擎是草擬合同，而訂單則是雙方白紙黑字簽約，乙方要按照合同為用戶來履約。那么系統(tǒng)究竟是如何來為用戶履約的呢？
在整個流程中需多個系統(tǒng)精密協(xié)作來完成一個訂單履約。大型電商大都采用微服務架構，恰好消息中間件成了解決微服務之間交互問題的重要組件，如應用耦合、異步通知、流量削鋒等問題，最終實現(xiàn)高性能、高可用、可伸縮、一致性的產品架構。
（1）訂單數(shù)據(jù)分發(fā)
各個系統(tǒng)都在嗷嗷待哺，等著訂單數(shù)據(jù)來觸發(fā)其業(yè)務流轉，這是訂單系統(tǒng)核心工作之一。隨著訂單在主干道和分支業(yè)務系統(tǒng)之間交互流轉，其會影響訂單的流轉速度和方向，而每次的交互都可能產生新的數(shù)據(jù)，那么保證任意時刻數(shù)據(jù)一致性是至關重要的。
分布式系統(tǒng)幾乎不可能每一個時刻完全保證數(shù)據(jù)一致性，所以需要建立一個數(shù)據(jù)使用白皮書來規(guī)范數(shù)據(jù)的交互和使用。
1）主數(shù)據(jù)機制
任何提供服務的系統(tǒng)都要維護其邊界內核心數(shù)據(jù)的準確性，即主數(shù)據(jù)。其他系統(tǒng)的這部分數(shù)據(jù)需來源于主數(shù)據(jù)，尤其是強依賴的數(shù)據(jù)，無論什么情況都首先需以主數(shù)據(jù)為準，甚至要通過反查來確認數(shù)據(jù)準確性。
主數(shù)據(jù)的數(shù)據(jù)來源也不是完全可以自己閉環(huán)，也會依賴其他系統(tǒng)的數(shù)據(jù)上收，所以其必然也存在數(shù)據(jù)時間差。
2）過程數(shù)據(jù)機制
典型的是訂單狀態(tài)數(shù)據(jù)，其狀態(tài)是在流轉變化的，由訂單生成到訂單完成之間會經歷大大小小的十多個狀態(tài)，而狀態(tài)數(shù)據(jù)由于是異步更新的。那么利用消息機制進行廣播，相關系統(tǒng)監(jiān)聽這部分消息來觸發(fā)其業(yè)務邏輯。如到了訂單到了支付完成狀態(tài)其主數(shù)據(jù)會發(fā)出支付完成消息，生產系統(tǒng)會監(jiān)聽并消費到此消息來觸發(fā)其拆單揀貨打包配送等操作。
基于訂單狀態(tài)的變化而廣播消息是訂單數(shù)據(jù)分發(fā)的核心機制之一，另外一部分是關鍵業(yè)務數(shù)據(jù)或個性化業(yè)務特殊觸發(fā)的消息。
3）結果數(shù)據(jù)機制
訂單號是典型的結果數(shù)據(jù)，無特殊情況是不能被修改的。結果數(shù)據(jù)通常是可以信賴的，但隨著業(yè)務發(fā)展，系統(tǒng)中會有各種錯誤而需要數(shù)據(jù)修復，這可能會導致結果數(shù)據(jù)被修改。
4）數(shù)據(jù)版本機制
隨著用戶場景越來越豐富，業(yè)務發(fā)展越來越復雜，必然存在修改訂單數(shù)據(jù)的場景，這對分布式的異步系統(tǒng)是非常挑戰(zhàn)的，核心原因為過程和結果數(shù)據(jù)分發(fā)到相關系統(tǒng)已經觸發(fā)其業(yè)務進程中，而在這期間修改數(shù)據(jù)對于已經或正在執(zhí)行的業(yè)務產生致命影響。如修改收貨地址，直接影響到運費價格和履約時效的重新計算，會引發(fā)很多相關系統(tǒng)做出應變。
所以通常提供訂單后修改數(shù)據(jù)的能力是非常慎重的，且這部分數(shù)據(jù)通常會通過帶有版本號的數(shù)據(jù)快照來記錄，以區(qū)分和追溯。
5）數(shù)據(jù)分發(fā)機制
由于主干道對數(shù)據(jù)時效要求極高，此時大部分是通過接口進行數(shù)據(jù)通信交互，而對其他系統(tǒng)并不在主干道或對時效要求不高，可通過消息機制的方式來實現(xiàn)數(shù)據(jù)交互。消息隊列是基礎數(shù)據(jù)結構中的“先進先出”的一種數(shù)據(jù)機構。生活中排隊買東西，就是典型的“先進先出”。通過消息廣播數(shù)據(jù)的機制，可以解決：應用解耦、流量消峰、消息分發(fā)、異步通知等。
應用解耦：應用中有訂單系統(tǒng)、財務系統(tǒng)、倉配系統(tǒng)等各種業(yè)務系統(tǒng)。用戶創(chuàng)建訂單后，如果耦合調用所有相關系統(tǒng)，任何一個子系統(tǒng)出了故障，都會造成下單操作異常。當轉變成基于消息隊列的方式后，系統(tǒng)間調用的問題會減少很多，比如物流系統(tǒng)因為發(fā)生故障，需要幾分鐘來修復。
在這幾分鐘的時間里，物流系統(tǒng)要處理的內存被緩存在消息隊列中，用戶的下單操作可以正常完成。當物流系統(tǒng)恢復后，繼續(xù)處理訂單信息即可，中單用戶感受不到物流系統(tǒng)的故障。提升系統(tǒng)的可用性。
流量消峰：舉個例子，如果訂單系統(tǒng)最多能處理一萬次訂單，這個處理能力應付正常時段的下單綽綽有余，正常時段下單一秒后就能返回結果。但是在高峰期，如果有兩萬次下單操作系統(tǒng)是處理不了的，只能限制訂單超過一萬后不允許用戶下單。使用消息隊列做緩沖，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這使有些用戶可能在下單十幾秒后才能收到下單成功的操作，但是比不能下單的體驗要好。
消息分發(fā)：多個服務對數(shù)據(jù)感興趣，只需要監(jiān)聽同一類消息即可處理。
例如A產生數(shù)據(jù)，B對數(shù)據(jù)感興趣。如果沒有消息的隊列A每次處理完需要調用一下B服務，過了一段時間C對數(shù)據(jù)也感性，A就需要改代碼，調用B服務，調用C服務。只要有服務需要，A服務都要改動代碼，很不方便。
有了消息隊列后，A只管發(fā)送一次消息，B對消息感興趣，只需要監(jiān)聽消息。C感興趣，C也去監(jiān)聽消息。A服務作為基礎服務完全不需要有改動。
異步消息：有些服務間調用是異步的，例如A調用B，B需要花費很長時間執(zhí)行，但是A需要知道B什么時候可以執(zhí)行完，以前一般有兩種方式，A過一段時間去調用B的查詢api查詢?；蛘逜提供一個callback api，B執(zhí)行完之后調用api通知A服務。這兩種方式都不是很優(yōu)雅。
使用消息總線，可以很方便解決這個問題，A調用B服務后，只需要監(jiān)聽B處理完成的消息，當B處理完成后，會發(fā)送一條消息給MQ，MQ會將此消息轉發(fā)給A服務。這樣A服務既不用循環(huán)調用B的查詢api，也不用提供callback api。同樣B服務也不用做這些操作。A服務還能及時的得到異步處理成功的消息。
（2）訂單狀態(tài)流轉
訂單狀態(tài)由訂單系統(tǒng)來維護，也是其最重要的數(shù)據(jù)。其幾乎控制著整個電商系統(tǒng)的運行流轉。
每一個狀態(tài)的變化會影響和指引訂單的信息流、實物流、資金流的流向。通常在大型電商平臺會有上百個系統(tǒng)來監(jiān)聽訂單狀態(tài)的變化來觸發(fā)業(yè)務，作為業(yè)務開始的起點。每個狀態(tài)都是在不同的作業(yè)流程中各系統(tǒng)來觸發(fā)改變，并將數(shù)據(jù)回傳到訂單主數(shù)據(jù)，由訂單主數(shù)據(jù)來統(tǒng)一維護和調度訂單狀態(tài)，以確保數(shù)據(jù)一致性。
由于訂單狀態(tài)的重要性，其在設計之初要特別小心。個性化狀態(tài)不能加到主干流程，可作為訂單擴展數(shù)據(jù)存在。每個狀態(tài)的流轉需有前置和后置狀態(tài)的合法性校驗，且作為可配置。如能從狀態(tài)1到2，但是不能從狀態(tài)3到2。
4. 履約引擎
所謂的訂單履約就是按照訂單上的承諾來履行和用戶的一個承諾的約定。而通常為了考慮履約成本，且由于商品所在物理上并不是一個不可拆分的單元，也即：它不是一個顆粒度最小的實體，可以進行多種形式的分解，具體如何分解根據(jù)不同的業(yè)務場景，可以進行不同形式的拆分。
（1）訂單拆分
訂單拆分是通過客戶在前臺提交的訂單，把客戶承諾的合同或履行約定，拆成貨主可生產的一系列子單，其實最核心的是拆信息、拆資金、拆實物。其實不同的平臺拆分維度很多，不做贅述。拆分后，比如說倉庫生產、配送環(huán)節(jié)、售后環(huán)節(jié)，實際上都是參照子單去進行操作。
1）實物拆分
像雙11或者618等這種大促的時候，我們的購物車可能一次性會有10個甚至有若干個東西要購買，最后發(fā)現(xiàn)被拆成多個訂單，什么原因呢？
維度1：庫房位置
即使針對同一個貨主，也有可能其不同品類的商品由于儲存環(huán)境等因素會被放到不同的倉，這樣就會帶來一個拆分，這是最主要的一個維度，即庫房。
維度2：貨主不同
京東為例，京東現(xiàn)在有自營和POP，而POP里邊有不同的商家，京東為了要給不同的商家進行結算，不可能在一張訂單上同時存在兩個商家的商品，這將導致京東無法跟商家做結算。因而，京東會根據(jù)商家去進行拆單。
維度3：特殊業(yè)務
有些是業(yè)務本身的特殊性，需要單獨履約。比如用戶下單買了A和B商品，但是B暫時無貨，那么可以選擇有貨先發(fā)，那么就會被拆開分別履約。
2）信息拆分
將原始訂單信息復制或者分攤計算到子單。
3）資金拆分
基本365天都會有不同類型的促銷。比如買個東西，滿199減 100?。ɑ顒宇A熱），大家都會湊單湊到199。于是，用戶就會買食品湊夠199然后減掉100。假如用戶買了10件商品，減了100元，那么具體這100塊錢怎么減呢？
對于客戶來說，他們不理會平臺怎么操作這個優(yōu)惠折扣，只要這100塊錢在自己結算的時候抵扣即可。比如，用戶花了200塊錢，而實際只是收了用戶100塊錢，這就可以了。但對于平臺來說，這100塊錢并不是直接減100這樣來登記的，其不在訂單里，是以商品的金額訂單里，商品金額的比例分拆優(yōu)惠的錢。
（2）訂單履約計劃
訂單轉移可以理解為訂單的計劃，其是為了實現(xiàn)訂單履約，而制定的生產方案。一個合理的生產計劃，能在保證時效承諾的前提下，起到優(yōu)化生產，降低成本的作用。由于平臺越來越開放，不同的訂單來源于不同渠道，需要由不同的生產系統(tǒng)來履約。
那系統(tǒng)是如何確定以什么方式為客戶履約？
其實訂單履約計劃是履約的一個核心環(huán)節(jié)，將待履約的訂單按照履約計劃分發(fā)到不同的庫房去生產。但對于庫房來說，不可能來了一張訂單就生產一個訂單，這樣的庫房是沒有計劃性的，容易導致生產混亂，所以訂單都會按照履約計劃成堆生產，而不是單獨去生產。
FTP，即Fulfill to Promise，即針對現(xiàn)貨去做履約計劃。ATP，即Availableto Promise，即針對沒有現(xiàn)貨去做履約計劃。未來的趨勢一定是ATP的比重會變大，就是怎么把供應商的庫存，怎么把在途的庫存，怎么把一些計劃里的東西，都能實際的用起來。
在大促期間，用戶的第一的需求是我能買到這個貨（因為便宜）?？赡芫蛯r效的要求不高，有一些東西會通過讓用戶選擇犧牲時效，而把一些在途的庫存或在供應商倉庫里的庫存，都會去把這個東西認為是可以生產履約的庫存。最后，會讓消費者真正的能享受到這個實際的優(yōu)惠。
6.?風控引擎
風控引擎需在事前、事中、事后對可疑行為進行系統(tǒng)或人工干預。目前由于大量黑灰產、羊毛黨、黑客們的存在，這些人已不是單打獨斗，而是與時俱進地團隊作戰(zhàn)。如果系統(tǒng)不針對這些人或系統(tǒng)的行為進行防范，隨時有可能被惡意攻擊而導致系統(tǒng)癱瘓，從而無法給真正的用戶提供服務。因此，在電商系統(tǒng)里面，風控是極其重要的系統(tǒng)，甚至是凌駕于其他系統(tǒng)之上，否則一旦發(fā)生就會產生巨額經濟損失。
（1）內容風控
任何數(shù)據(jù)寫入的地方，那么這兩個前端界面可輸入的地方，都會存在安全隱患。這些可輸入的內容，比如文字、圖片、視頻等存在的風險，屬于內容風險。我們需要對文字進行敏感詞過濾，對圖片進行簽黃以及對圖片上的文字進行審核，對視頻的內容也需要進行審核。
（2）系統(tǒng)漏洞
所有系統(tǒng)必然存在漏洞，只是還沒有被發(fā)現(xiàn)而已。營銷作弊、刷紅包、薅羊毛、推廣作弊等欺詐風險。目前黑客們每天躍躍欲試，其每天可能針對目標攻擊數(shù)次，常見的批量注冊、批量登錄、批量搶單、報文篡改等。
（3）運營漏洞
電商平臺每天各種促銷優(yōu)惠活動，在促銷優(yōu)惠設置及相互疊加后極有可能出現(xiàn)極低價格，甚至0元單的出現(xiàn)，那么瞬間就會被用戶尤其黑灰產、羊毛黨等薅個精光。所以針對價格相關影響因素需要有實時監(jiān)控系統(tǒng)，滿足預設規(guī)則及時報警，甚至系統(tǒng)直接鎖定。
以支付為示意，風控模型是多維度異常復雜的系統(tǒng)，而且都是實時性要求極高，否則會影響主流程的繼續(xù)運行。
總結
產品架構最大的特點在于，眼中沒有產品形態(tài)的概念，是需要在充分理解用戶需求的基礎上，規(guī)劃設計在生態(tài)內各角色協(xié)同完成工作的一套機制。
產品架構設計，需盡最大努力感知不到業(yè)務的存在，應只專注于數(shù)據(jù)結構、數(shù)據(jù)分發(fā)、數(shù)據(jù)協(xié)同，但卻可以提供一個舒適的、自由的、開放的環(huán)境讓業(yè)務茁壯成長。
作者：勝己半子；公號：勝己半子。
本文由 @勝己半子 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協(xié)議
系統(tǒng)化方案
是的。目前b端越來越多