簡易版訂單系統
阿新 • • 發佈：2019-12-31
訂單和支付系列目錄
前言
- 從事訂單支付系統的設計研發已經接近倆年了,一直想好好把其中一些思考沉澱下來。一是回顧之前的設計,看看迭代過程中的一些思路是否合理,如果給自己從頭再來的機會(不用考慮苦逼的相容髒資料等等問題)能否設計得更好?二來自己一直想培養寫部落格的習慣,卻從15年一直到現在都沒有養成,希望從現在開始能堅持下來一步一步寫下去(無論技術還是感悟),此係列文章算是個開頭,希望這個開頭不太難
訂單系統的思考
訂單系統的定位
-
作為底層支撐系統是一個承上啟下的位置,上游對接商品使用者等業務系統,下游對接支付系統。由業務系統發起下單,下單成功之後再交由支付系統去支付。訂單系統只提供底層支援,由商品業務系統控制流程。但當有多種業務系統時,程式碼非常容易冗餘不容易維護,迭代成本往往也很高。
-
訂單作為中心繫統,控制訂單流程,閘道器直接到訂單系統,訂單系統在下單之前,下單之後分別呼叫業務系統完成訂單風控,以及訂單通知,下單成功之後,後續支付流程完成交由支付系統來控制,訂單和支付各自職能劃分清楚.
訂單系統核心功能 (個人認為)
- 記錄交易快照(留下憑證既訂單記錄)
- 訂單狀態流轉(完成交易閉環,支付,退款,取消等等)
訂單系統設計
訂單設計(極簡版本)
- 這是一個最基礎的訂單系統設計這裡大致講解每部分的作用
- 統一風控主要做統一的下單前置校驗（例如前端引數以及金額相關校驗）
- 統一金額處理可以處理優惠券分配，服務費，積分分配等等金額統一相關的部分
- 配置該業務訂單是否需要業務系統前置校驗,三方校驗，後置通知等等
- 建立無效訂單可以為後續提供冪等處理(訂單號),以及減少失敗後置處理
- 訂單後置處理如需要應該非同步化完全和下單流程分割開來
- 業務系統部分例如前置凍結庫存，成功之後扣除庫存通知使用者等等
狀態設計
- 設計一個好的訂單系統,前提肯定是要對狀態歸類,以及設計一套合適並且易於擴充套件迭代的訂單狀態,狀態機的部分我們留到下篇文章單獨講解，此處我們先簡要介紹幾種常用訂單狀態
- 無效狀態
- 初始狀態
- 支付成功狀態
- 交易完成狀態
- 退款中狀態
- 退款狀態
- 異常關閉狀態
- 每種大業務型別的訂單除了以上列出的主要狀態外，肯定還會有各自的一系列子狀態需要定義，一般各自的訂單子狀態不一致。此處定義列舉建議間隔（例如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代替,例如存入商品資訊,收貨地址等等.
總結
- 一個微型訂單系統甚至只要一張訂單表+狀態機就能夠搭建（訂單狀態機）
- 任何一個複雜的訂單系統也是由微型訂單系統擴充套件而來,搭建訂單系統的時候，前期功能可以簡單，但架構一定要分明,方便後續擴充套件。一個成熟的訂單系統肯定都是由業務的不斷演進不斷迭代才越來越優秀。
- 訂單系統的一大難點在於操作的原子性,屬於與使用者交易打交道的第一道關口,任何異常以及細節都需要仔細考慮[訂單異常情況處理]（此篇文章後續會更新 ）