簡易版訂單系統

訂單和支付系列目錄

前言

• 從事訂單支付系統的設計研發已經接近倆年了,一直想好好把其中一些思考沉澱下來。一是回顧以前的設計,看看迭代過程當中的一些思路是否合理,若是給本身從頭再來的機會(不用考慮苦逼的兼容髒數據等等問題)可否設計得更好?二來本身一直想培養寫博客的習慣,卻從15年一直到如今都沒有養成,但願從如今開始能堅持下來一步一步寫下去(不管技術仍是感悟),此係列文章算是個開頭,但願這個開頭不太難

訂單系統的思考

訂單系統的定位

• 做爲底層支撐系統是一個承上啓下的位置,上游對接商品用戶等業務系統,下游對接支付系統。由業務系統發起下單,下單成功以後再交由支付系統去支付。訂單系統只提供底層支持,由商品業務系統控制流程。但當有多種業務系統時,代碼很是容易冗餘不容易維護,迭代成本每每也很高。

  

• 訂單做爲中心繫統,控制訂單流程,網關直接到訂單系統,訂單系統在下單以前,下單以後分別調用業務系統完成訂單風控,以及訂單通知,下單成功以後,後續支付流程完成交由支付系統來控制,訂單和支付各自職能劃分清楚.

  

訂單系統核心功能 (我的認爲)

1. 記錄交易快照(留下憑證既訂單記錄)
2. 訂單狀態流轉(完成交易閉環,支付,退款,取消等等)

訂單系統設計

訂單設計(極簡版本)

• 這是一個最基礎的訂單系統設計這裏大體講解每部分的做用

1. 統一風控主要作統一的下單前置校驗（例如前端參數以及金額相關校驗）
2. 統一金額處理能夠處理優惠券分配，服務費，積分分配等等金額統一相關的部分
3. 配置該業務訂單是否須要業務系統前置校驗,三方校驗，後置通知等等
4. 建立無效訂單能夠爲後續提供冪等處理(訂單號),以及減小失敗後置處理
5. 訂單後置處理如須要應該異步化徹底和下單流程分割開來
6. 業務系統部分例如前置凍結庫存，成功以後扣除庫存通知用戶等等

狀態設計

• 設計一個好的訂單系統,前提確定是要對狀態歸類,以及設計一套合適而且易於擴展迭代的訂單狀態,狀態機的部分咱們留到下篇文章單獨講解，此處咱們先簡要介紹幾種經常使用訂單狀態

1. 無效狀態
2. 初始狀態
3. 支付成功狀態
4. 交易完成狀態
5. 退款中狀態
6. 退款狀態
7. 異常關閉狀態

• 每種大業務類型的訂單除了以上列出的主要狀態外，確定還會有各自的一系列子狀態須要定義，通常各自的訂單子狀態不一致。此處定義枚舉建議間隔（例如0初始狀態,3支付中）方便後續擴展。

訂單表設計

• 極簡訂單表結構

字段名	類型	備註
id	bigint	自增主鍵id
order_id	varchar	訂單id內置部分訂單信息（惟一鍵）
parent_order_id	varchar	父訂單id
top_order_id	varchar	頂級訂單id
third_order_id	varchar	外部訂單號
order_price	bigint	單位分,訂單金額
order_status	int	訂單狀態
order_sub_status	int	訂單子狀態
biz_type	int	業務類型
sub_biz_type	int	業務子類型
version	bigint	版本號（樂觀鎖用到）
extend	text	存入業務相關信息
refund_price	bigint	退款金額

• 以上省略建立時間,更新時間,建立者id,姓名,更新者id,姓名等建表常規字段
• 訂單金額相關 確定不止訂單金額,退款金額倆部分。這裏只考慮最簡單的其它例如優惠金額,支付時間,結算時間等等省略
• 業務相關信息後續訂單系統分表會講到,這裏先直接一個extend代替,例如存入商品信息,收貨地址等等.

總結

• 一個微型訂單系統甚至只要一張訂單表+狀態機就可以搭建（訂單狀態機）
• 任何一個複雜的訂單系統也是由微型訂單系統擴展而來,搭建訂單系統的時候，前期功能能夠簡單，但架構必定要分明,方便後續擴展。一個成熟的訂單系統確定都是由業務的不斷演進不斷迭代才愈來愈優秀。
• 訂單系統的一大難點在於操做的原子性,屬於與用戶交易打交道的第一道關口,任何異常以及細節都須要仔細考慮[訂單異常狀況處理]（此篇文章後續會更新 ）