Каталог серии Заказ и оплата
предисловие
- Я занимаюсь дизайном и разработкой системы оплаты заказов почти два года, и мне всегда хотелось уладить некоторые из этих мыслей. Во-первых, просмотрите предыдущий дизайн, чтобы увидеть, разумны ли некоторые идеи в процессе итерации.Если вы дадите себе возможность начать все сначала (не принимая во внимание проблему совместимых грязных данных и т. д.), сможете ли вы спроектировать его лучше ? Во-вторых, я думал, что у меня выработалась привычка вести блог, но я не развивал ее с 15 лет. Надеюсь, что с этого момента смогу придерживаться ее и писать шаг за шагом (независимо от технологии или восприятия). серия статей — это начало, и я надеюсь, что это начало не будет слишком сложным.
Думая о системе заказов
Позиционирование системы заказов
-
Как базовая система поддержки, она является связующим звеном между верхом и низом.Верхний поток подключен к бизнес-системам, таким как пользователи товаров, а нижний поток подключен к платежной системе. Бизнес-система инициирует заказ, и после успешного оформления заказ передается платежной системе для оплаты. Система заказов обеспечивает только базовую поддержку, а процесс контролируется товарной бизнес-системой. Однако при наличии нескольких бизнес-систем код очень легко сделать избыточным и сложным в обслуживании, а стоимость итерации часто высока.
-
Заказ - это центральная система, которая контролирует процесс заказа. Шлюз напрямую переходит в систему заказов. Система заказов вызывает бизнес-систему для завершения контроля рисков заказа и уведомления о заказе до и после размещения заказа. После размещения заказа. успешно, последующий процесс оплаты завершен и передан платежной системе.Для контроля соответствующие функции заказа и оплаты четко разделены.
Основные функции системы заказов (на мой взгляд)
- Запись моментальных снимков транзакций (оставление ваучеров и записей заказов)
- Поток статуса заказа (полная транзакция в замкнутом цикле, оплата, возврат, отмена и т. д.)
дизайн системы заказов
Заказать дизайн (минималистская версия)
- Это самый базовый дизайн системы заказов.Вот общее объяснение роли каждой части.
- Унифицированный контроль рисков в основном выполняет унифицированную проверку предварительного заказа (например, внешние параметры и проверку, связанную с суммой).
- Обработка единой суммы может обрабатывать распределение купонов, плату за обслуживание, распределение баллов и т. д. Сумма, относящаяся к единой сумме.
- Укажите, требуется ли для бизнес-заказа предварительная проверка бизнес-системы, трехсторонняя проверка, пост-уведомление и т. д.
- Создание недействительных ордеров может обеспечить идемпотентную обработку (номер ордера) для последующих и уменьшить количество сбоев постобработки.
- Постобработка заказа, при необходимости, должна быть полностью асинхронной и отдельной от процесса заказа.
- Часть бизнес-системы, такая как предварительная заморозка инвентаря, вычет инвентаря и уведомление пользователей после успеха и т. д.
государственный дизайн
- Чтобы спроектировать хорошую систему заказов, предпосылка должна состоять в том, чтобы классифицировать статус и разработать набор статусов заказов, который подходит и легко расширяется и повторяется.Государственный аппаратМы оставляем это в следующей статье, чтобы объяснить это отдельно, здесь мы кратко представим несколько распространенных статусов заказов.
- недопустимое состояние
- начальное состояние
- Статус успешного платежа
- статус завершения транзакции
- Статус возврата
- статус возврата
- Ненормальное состояние отключения
- В дополнение к основным состояниям, перечисленным выше, заказы каждого типа крупного бизнеса обязательно будут иметь свою собственную серию подсостояний, которые необходимо определить.Как правило, соответствующие подсостояния заказов несовместимы. Интервал предложения перечисления (например, 0 начальное состояние, 3 платеж в процессе) определяется здесь, чтобы облегчить последующее расширение.
оформление бланка заказа
- Минималистская структура таблицы заказов
| имя поля | тип | Примечание |
|---|---|---|
| id | bigint | автоматическое увеличение идентификатора первичного ключа |
| order_id | varchar | Идентификатор заказа, встроенная часть информации о заказе (уникальный ключ) |
| parent_order_id | varchar | Родительский заказ ID. |
| top_order_id | varchar | идентификатор верхнего заказа |
| 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 | Сумма возмещения |
- Вышеупомянутое опускает время создания, время обновления, идентификатор создателя, имя, идентификатор обновления, имя и другие обычные поля построения таблицы.
- Сумма заказа, безусловно, связана не только с суммой заказа, но и с суммой возврата. Здесь опущены только самые простые другие, такие как размер скидки, время платежа, время расчета и т. д.
- Отслеживание информации, связанной с бизнесомЗаказать системное решениеСледует отметить, что здесь непосредственно заменяется расширение, такое как внесение информации о продукте, адрес доставки и т. д.
Суммировать
- Систему микрозаказов можно построить даже с таблицей заказов + конечным автоматом (машина состояния заказа)
- Любая сложная система заказов также расширяется из системы микрозаказов.При построении системы заказов исходные функции могут быть простыми, но структура должна быть понятной, чтобы облегчить последующее расширение. Зрелая система заказов должна становиться все лучше и лучше только благодаря непрерывному развитию и итерации бизнеса.
- Одной из сложностей системы заказов является атомарность операции.Она относится к первому шлюзу, который имеет дело с транзакцией пользователя.Любые отклонения и детали необходимо тщательно рассматривать [нештатная ситуация заказа] (эта статья будет обновлена позже)