前言
電商誕生已經有20多個年頭了，從早期很多人的質疑、騙子、不接受、甚至肄業排斥、打壓，到現在徹底融入我們生活的方方面面，並號稱中國的 “新四大發明”，“認知教育”使命已經完成。人們足不出戶，網上下個單，就可以在家坐等收包裹，確實是一種享受。
今天就跟大家聊聊電商技術裏面最重要的交易部分
核心模塊
-
購物車
-
下單
-
付款
-
庫存
-
優惠
-
收穫地址
-
訂單管理
-
退款
-
成交記錄
-
評價
隨着業務的發展可能面臨的問題
1、創業早期，人手資源都比較缺乏，講究靈活策略，爲了快速上線，通常會採用集中式系統架構。等後面業務稍微穩定些，再喘口氣慢慢做系統架構衍化、升級。
2、電商業務比較特殊，貼近生活，特別是經過十幾年的淘寶電商教育，人們對網上購物已經形成習慣，如果你做垂直電商、社區電商、生鮮電商，雖然是切入部分人羣，但高頻交易依然會產生海量數據，底層存儲設計要提前預留擴展。
3、電商營銷活動總是特別多，市場同學經常搞個大促、秒殺，要注意高併發流量設計
4、電商的業務玩法總是特別多，要學會抽離共性組件，模塊化，採用流程引擎靈活滿足不同業務訴求
5、古話說得好，船小好掉頭。臃腫龐大的系統、複雜歷史包袱，不但協同效率低下，而且穩定性、擴展性也比較差。“拆” 是不可避免的選擇，按DDD設計思想，確定好限界上下文，拆分一系列子域，如：會員域、商品域、交易域、庫存域、支付域、物流域、營銷域等等。
當然，隨着業務的日積月累，子域系統逐漸複雜起來，可能還需要進一步拆分子子域。所以說，“複雜的系統架構都是隨着業務發展逐漸演化而來的！”
交易流程
1、正向流程
-
用戶添加購物車分爲登錄態和非登錄態，登錄態好理解，將商品及購買數量關聯到用戶id上。對於非登錄態，server端會創建用戶臨時token標識，除了關聯商品記錄外，還會將標識緩存到客戶端。如果處於登錄態，會將臨時表的數據合併到購物車表。
-
新創建的訂單會放入超時表，由定時任務掃描記錄，未付款超時執行訂單關閉，釋放庫存
-
購物車批量下單，如果涉及多個店鋪，會進行拆單
-
發貨環節，如果涉及多個商品，可能會拆包分批發貨，關聯多個物流單
-
對於惡意刷單要接入風控處理
2、逆向流程
-
逆向流程裏有一個重要的子域業務，人工介入平臺。早期訂單不多時可以內部人工消化，隨着業務量的快速增長，可以考慮智能客服，或者大衆評審。
-
買家可以整單或部分申請退款
-
風控檢測到訂單存在風險會自動發起退款
-
如果有使用優惠券，部分退款，要扣掉優惠券部分
經驗技巧
1、任何事物都有自己的生命週期，透過現象直達本質，可以幫我們以較低成本解決很多難題。交易訂單分爲在線庫（只保留近三個月的訂單數據），對於超過三個月且狀態結束（交易成功、交易關閉）的訂單會移到歸檔庫中，大大提高了查詢性能。
2、電商平臺一般發展比較迅猛，如果再搞點市場活動，訂單數據是比較容易出現因爲單個數據庫表中的數據量過大而造成性能的瓶頸。如何選擇分表鍵，買家uid、還是訂單id、又或者是賣家uid，貌似都無法滿足所有的業務場景。
可以參考淘寶的做法，規則最大化適用原則，訂單號拆成兩部分，前面爲全局唯一自增id，後面爲買家id的後六位，分表鍵按照買家uid的後6位來計算，未來最大支持擴展100萬張邏輯分表。可以支持按訂單id或買家uid來查詢，至於賣家部分，採用數據異構方式，將賣家uid及訂單id放入另一張數據表中。
3、大多數業務都是讀多寫少，如果訪問性能開始出現瓶頸，可以考慮一主多從、讀寫分離等優化策略
主從存儲間數據同步都是異步操作，如果延遲較大，很容易影響用戶體驗。對於實時性要求較高的業務，可以依賴主庫，或者藉助緩存。
4、系統拆分
基礎業務邏輯下沉到服務，業務模型需要統一抽象，能支持定製擴展。比如，對不同規格優惠券原子性拆分、動作類型定義，數據重組。非核心數據可以考慮複合字段，數據異構化並考慮引入搜索，滿足多維度查詢。
Web 產品層專注表示邏輯和編排，可以藉助 SPI 業務框架、流程引擎、規則引擎等這些基礎業務框架，在業務支撐上做到了靈活可擴展。系統也做了比較合理的分層，每層只需要關心本層所需關注的能力即可。
5、複雜且較多外部RPC依賴，如何保證全局性的事務處理，最直接場景就是交易的下單。
-
營銷優惠券服務、庫存服務、下單服務是分開部署。交易創建流程中，訂單、券和庫存的狀態必須要保證一致性
-
調用券/庫存服務超時/失敗，異步發消息通知回滾；複雜性可控
-
MQ 生產端發送失敗，可以重試，消息框架要採用冪等性生產者 。消費端通過ACK 機制保證最終一致
-
消除了二階段提交等分佈式事務框架的侵入性影響
-
最後一步的數據庫訂單置爲 “可見” 要採用事務性消息，保證一致性。
注意：也可能存在優惠券預凍結後，交易這邊的服務器宕機了，廢單消息沒有發送成功。此時可以參考RocketMQ的回查機制，通過輪詢任務，掃描出相關記錄，反查訂單狀態，決定最終提交或回滾。
6、支付環節如何保證多節點間數據一致性。採用消息+異步任務補償
-
訂單創建成功後，會自動拉起三方支付的收銀臺，待用戶付款成功後，會通過回調頁面或API接口的方式通知支付系統，有支付系統發送MQ消息
-
交易任務系統，消費消息做訂單狀態、減庫存、銷量等字段更新
-
如果處理失敗，會插入補償表，通過階梯式的異步補償任務，保證最終一致性
7、如果業務邏輯複雜，內部涉及大量的接口調用，串行調用等待時間較長，如果各個節點間沒有依賴關係，可以考慮並行化處理。
8、儘可能使用緩存。既有本地緩存，也有分佈式緩存。至於緩存使用注意問題可以參考之前的寫的文章，《使用緩存必須注意的事項》
大促活動時，提前對緩存預熱，藉助緩存的高性能抗住大部分訪問壓力。
END
我們熱衷於收集&分享高併發、系統架構、微服務、消息中間件、 RPC框架、高性能緩存、搜索、分佈式數據框架、分佈式協同服務、分佈式配置中心、中臺架構、領域驅動設計、系統監控、系統穩定性等技術知識。
https://github.com/aalansehaiyang/technology-talk
活到老、學到老，用技術普惠世界
關注【微觀技術】
共創世界，探尋人生價值