交易体系-交易、支付、物流、退款退货


说起来,这篇博客已经写了有六七个月了,不过因为涉及到了不少细节内容,不便于分享出来,最近整理了一下,将部分细节内容去掉,分享出来,希望对大家有所帮助。

一 题外话

一个目的开同学水平不一,习惯、的架构有所不同,再叠加上几年各种的需求,想让一个系能持保持干是很的一件事。估有很多开同学经常很想将自己接收过来的项目重构一下,让它看的“顺眼”一些。

如果系架构和设计候能全面解耦,可以极大的降低系的耦合,最大可能的保持系逻辑清晰,后续的扩展也会更加容易。实际上如果做好了解耦,即便是一个,也只局限于一个系统中,不会其他生影响,后期想化、重构也比容易很多。

这篇博客主要就是讨论如何将商品、交易、支付等作为底层公共服务来设计,以便于灵活、快速的支持上层业务发展的需要。

 

二 内容概要

1  主要内容

清晰各个系界在何,如何划分系

清晰什么是交易,交易的核心要素

清晰支付系的核心功能。

清晰物流的核心功能,拆包、并包方案

清晰交易、支付、物流、退款系的架构与设计,以及系统边界。

如何解耦各个系统,以及解耦带来的好处。

设计与“大中台、小前端 ”思想。

讨论几个案例。

 

里我很想达一种点:编码不是需求的堆叠。它更像是先制造一个个的木(功能模不管我是想搭茅屋还是建城堡,都是组装这些积木(功能模块)实现的目标。

 

2  说明

解耦基本上都是依MQ实现的,我使用的是RocketMQ,他可以保证dbMQ消息一致。注意最新的RocketMQ开源版本4.1.0目前的事务性消息不完整,以后有机会详细聊一下这个问题。

下的交易、物流、退、支付流程均是我根据之前工作总结出来的,为了便于理解,我这里以大家最为熟悉的淘宝、京东交易流程示例来讨论。这里讨论的设计方案的想法很多借鉴了阿里的电商模型,不过我并没有在阿里呆过,所以也不能100%确定他们现有的模型是否发生较大的变化,如果哪位小伙伴发现了,欢迎支持。

MQ相关的内容可以参考一下博客:

RocketMQ实践:https://yq.aliyun.com/articles/278085

RocketMQ原理:https://yq.aliyun.com/articles/278086

Kafka VS RocketMQ VS RabbitMQ:https://yq.aliyun.com/articles/278087

 

三 交易

1  

交易是buyer在某一时间以某一价格购买了seller的一个或多个商品(或者一种sku,所以于交易而言buyer、seller、item/sku、quantity、price、date是其核心要素。创建订单的过程其实就是buyer、seller签订契约的过程,契约签订完成后,不应该随意变更,除非通过另一种契约终止或者修改此契约。

 

2  角色与名

buyer:买家;购买商品的人

seller:卖家;销售商品的人。

Item:商品

Promotion:,例如店铺满减、折扣、品直降等等。

Coupon:优惠券

Sku:Stock Keeping Unit存量位),简单唯一描述存量的最小元就是sku。示例:一个iphone时挂出以下信息:白色、银色两种颜色,128g,64g两种容量;那么白色+128g就是一个sku。如果另外一加了一个属性:信、移通,那么白色+128g+电信就是一个sku。

Point:不同平台的称呼基本上都不同,一叫做分。积分分两种,一种是系统随意发放,没有抵价物,大部分系中基本上都是使用种;另外一种是和金挂,即每个分都和出去多少分就需要提前划多少出来。后面种做法常的方式是有一个分池,每向池子中放一笔分池就加一定量的分;户发放一笔,分池中减少相分。

需要注意的是在两种方式在最后算、对账时会有很大的差。此内容超出本文的范,不做讨论

 

 

3  交易、支付、物流模型

1)   模型

以下是交易、支付、物流模型。交易系的核心数据是biz_order了与付、物流系解耦,分别创建了pay_orderlog_order别对接支付系、物流系统。

交易体系-交易、支付、物流、退款退货_第1张图片

说明:

支付订单(pay_order)应该和交易订单(biz_order)放在一个事建,记录此笔交易的详细资金明

物流订单(log_order)应该和交易订单(biz_order)放在一个事建,记录此笔交易的物商品物流情况。

支付(pay_order)、物流订单(log_order)的状态变更会影响交易订单(biz_order)中状化。

 

2)   解耦的努力

支付系搞了一个支付订单(payment_order),交易也系搞了一个支付订单(pay_order) ,物流系搞了一个物流订单(logistics_order),交易系又搞了一个物流订单(log_order) 。为什么要这样做?这样做能给我们带了什么好处?

a)    biz_order与pay_order

Pay_order数据是否应该合并到biz_order中,或者分两表有什么好处?这问题等后面表的主要构与字段的候在描述。

 

b)    支付订单

支付系payment_order:主要外,负责封装第三方支付渠道,负责支付程中状

交易系中的pay_order

对外主要对接交易系统的payment_order,通过pay_order创建payment_order,而payment_order的状态变化将影响pay_order的状态变化,他一一对应

对内pay_order对接biz_order,通过biz_order购买商品、惠等信息决定每个订单实际信息,而Pay_order的状态变化将影响biz_order中状化。

c)    物流订单

物流logistics_order:主要外,负责封装第三方物流信息,负责物流状以及拆包、并包逻辑。

交易系中的log_order

对外主要对接物流log_order,通过log_order创建logistics_order,而logistics_order的状态变化将影响log_order的状态变化,他一一对应

对内log_order对接biz_order,而log_order的状态变化将影响biz_order中物流化。

架构的核心思想是关注自己的核心业务尽可能内聚,和外部系的耦合尽可能低。

 

4  创建、完成订单

1)   示例

以下三张图是淘宝、京猪的订单认页面,我接下来就根据它们讨论交易系设计。之所以选择、淘宝是因是大家最熟悉的两个商平台,之所以选择飞猪的路线体商品有所不同,交易流程会有差,并且复度更高;另外一点就是做一段时间的旅游交易,稍微熟悉一些。

交易体系-交易、支付、物流、退款退货_第2张图片     交易体系-交易、支付、物流、退款退货_第3张图片     交易体系-交易、支付、物流、退款退货_第4张图片

 

2)   入参校
a)    公共校

itemId需合法、数量需合法

如果是体商品,地址是否

如果需要票,票信息是否合法。

等等

b)    个性化校

如上示例,如果是旅游路线这种商品,需要包括一些套餐、出游人群、出日期信息,因为这些都是必的,所以均需验证。如果是酒店、机票订单,校的信息也不同。

c)    特殊理或默认处

对于上面的几种交易而言,都有明确的家,所以sellerId是确定的;另外一些情况下,一个平台可能收集各种商品,自己拿来,即整个平台都家就是平台自己,此需要置一个默家。

如果平台关注购买渠道(pc、mobile、h5等)信息,也需要校

 

3)   数据校
a)    公共校

过buyerId、sellerId查询buyer、sellerId信息,判断buyer、seller是否有效合法。

过addressId查询地址信息,判断address是否有效合法。

过itemId、itemSkuId查询商品、商品sku信息,判断商品是否有效合法;数量是否足;商品的家信息是否和sellerId一致。

b)    定制化校

如果使用邀请码兑换查询相关是否有效合法。

如果使用分、金币进行抵扣,查询验证积分、金是否足

如果使用包抵扣,查询红包是否合法、可用。

如果参加惠活检查优惠活的信息,确保惠信息合法、可用。

如果使用惠券,查询优惠券信息,判断是否合法、可用;另外须确保优惠券的领取者和buyer一致,大部分可能如此,但如果是似于微信、支付宝共享惠券的另当别论,但不管如何均需确保用可以使用此惠券。

类似于飞猪的路线类商品,需要校套餐和日期等多个条件下的数量是足。本上来说这也是一个item/sku数量的校,只是于路线类商品而言,套餐、人群、出团日期这三个要素构成了一个sku。

 

从上面的校验过程,交易过程中需要与很多服务打交道,而且对这些服务产生提前验证可以减少失败率,减少无效操作,特是减少异常补偿流程。

 

4)   组装订单
a)    因素

数据装是一个比程,以下是组装订单、计算金额时需要考的因素

Item/sku

购买时,如果商品不区分sku,那我们购买的就是一个item;如果商品区分sku,那么我将不能直接购买item,而是sku。

一次购买多种item/sku需要考虑订单合并成主子订单。例如从车过来的订单,可能是不同家的商品,此需要先根据sellerId对商品进行分组。

的促有:店铺满减、店铺满折、减、品直降、品折扣;而且很多惠活会混合在一起使用,并且包含一个使用

优惠券

惠券有:店铺满减、店折扣、减、品直降、品折扣,不但需要可以混合使用,有可能需要和促一起使用。当然如果促惠券需要跨店,那就更加的复了。

积分

使用分抵扣

 

b)    要点

tem/sku问题

如果购买时,传入了skuid,就需要根据item、skuorder,否可以指根据itemorder

每一个order中只应该包含一个商品(不这样做会续带来无限的麻但是如果在一个店铺购买了多种商品,但是需要一次付款,那么就需要建一个主订单记录订单的主要信息,建多个子订单别记录购买的物品。

惠券的使用问题

先使用Promotion还是应该先使用coupun?先使用店铺优惠(券),应该先使用惠(券)

Promotion/coupun的使用序其是一个业务问题,由公司的运策略决定;其中的差是:如果惠券需要用户领取,用户获惠券是有成本的,如果希望用都走一步,或者希望通过优惠券拉来用,那么使用惠券是比适合的;否使用促动就可以了。另外,要根据公司结算要求来决定使用,注意拥有相同的惠和惠券,不同的使用序,和可能最实际额是不同的

铺/单品优惠的不同使用序会影响最终的金额。一般来说大都先使用单品的,然后使用店铺的,因为这样对与店铺而言更加可控

 

c)    组装

首先将所有的item/sku根据sellerId分组。然后检查在此卖家下购买的商品种类,如果只有一种,那么创建一个订单,直接记录购买的商品信息;如果超过一种,那么创建多个子订单,一个主订单。

根据业务需要,决定先使用promotion还是先使用coupun;先使用店铺优还是先使用单品优惠;将最终计算出的优惠金额存入订单中,以明确每个订单使用每一抵扣了多少钱。一般会根据每个子订单的总金额按照比例均摊总的优惠金,此需要注意可能出不能整除时,时需要修正金额。如果不按照每个子订单金额的比例分摊优惠金额,被人恶意退货、退款时,可能会出现严重的问题。

 

5)   创建订单

将主订单、子订单放在同一个事务中,insert到db中,同时发mq消息需要mq消息,所以orderId需要提前生成。具体流程图见后面部分。

接着减库存。

如果使用了积分,接着冻结积分。

如果使用了优惠券,接着消费掉这些优惠券

在事务中修改主子的状态为success,并且发送MQ消息。到此时订单创建完成。

说明:进行扣减库存、冻结积分、消费码、使用优惠券等操作的时候一定要带上orderId,用于在Rpc调用的时候做幂等。消费的顺序不一定需要和流程图中保持一致,具体根据业务情况来决定。

说明:如果在校验环节没有查用户积分是否足够,这里建议优先冻结积分,以免出现大量冻结库存的情况。

 

6)   

仅仅展示了主要字段,用以参考。

a)    业务订单表(biz_order)

Id

id

 

category_id

类目id

一般不同的目交易流程或者后的履流程会有所不同。

item_type

商品

商品型跟着目走,代中根据此字段决定走不同的流程。

item_id

商品id

item_sku_id

商品sku id

item_price

价格

item_title

商品名称

quantity

数量

total_amount

总金额

actual_amount

实际金额

is_main_order

是否订单

主子订单时使用

parent_id

订单id

订单时对应的父订单id

buyer_id

买家

seller_id

卖家

order_date

单时间

out_id

外部id

out_type一起,可用作幂等

out_type

外部

out_id一起,可用作幂等

status

展示的状实时biz_order、pay_order、logistics_order表数据汇总后的果,而read远多于write操作,性能、实现度考,很有必要在biz_order中存储这三个字段

pay_status

付款状

logistics_status

物流状

在父子订单景中,如果是父订单item信息可以不空,否则item信息不空。

 

b)    支付订单表(pay_order)

id

id

biz_order_id

业务订单id

如果不考一个订单多次付款,也可以放到biz_order

total_amount

总金额

point_amount

积分抵扣金额

discount_amount

折扣金

adjust_amount

商家改价金

actual_amount

实际付款金额

总金额减去所有优惠、调整后的金额

status

例如:未付款、已付款、已退款等等

pay_date

付款日期

out_pay_no

外部付款流水号

支付系中支付流水号

字段我可以比较简单的看出,biz_order负责处理业务订单逻辑;pay_order负责处理支付相关的逻辑。

在这里需要强调的是,pay_order中仅仅存放了与金额相关的信息,他们都是属于交易的一部分数据,只是基于现实开发中设计上解耦的需要,才将他们拆开的,所以他们有不少字段是相同的。具体原因如下:

c)    biz_order和pay_order分开的优劣

l  

biz_order负责业务,pay_order负责惠,业务数据可以做到更加内聚。

当增加新的营销玩法的时候,金额计算过程将产生较大的变化,但其他数据基本可以不用修改,分开可以做到与biz_order相关的逻辑基本不用修改;

对接新业务的时候,一般来说个性化业务的数据会略有不同,但与计算金额的逻辑基本上不会有什么变动,分开可以做到pay_order也基不用修改。

当交易系统对接的上层业务越多,式、促销玩法种类越多,分开的优势会越明业务越复杂,功能越烦杂时,越是忌讳模型的混用。

l   缺点:

编码杂度会增加。

 

7)   流程图
a)    创建订单简易流程

交易体系-交易、支付、物流、退款退货_第5张图片

b)    创建订单完整流程

交易体系-交易、支付、物流、退款退货_第6张图片

以上只是列了使用分、惠券的示例,实际上根据公司的运需要,可能远远比次复,不过处理方式基本以上,不再累述。

说明一下:如果在数据校验环节不校验当前用户积分是否足够,那么最好先扣减积分再减库存。

 

c)    完成/滚订单流程

交易体系-交易、支付、物流、退款退货_第7张图片

为了方便讨论,我将订单完成/回滚流程放到了同一个图中。

 

说明:是否需要回滚以上的商品库存分、惠券内容,需要根据业务决定。例如很多商网站都不会原使用惠券。

创建订单流程可知,我首先插入了一个init订单,此时seller、buyer的任何数据都没有化;接着我们执行减存、冻结积分、使用惠券、使用等流程,因为这些都是rpc调用,我们无法通过事务保证数据的一致性,所以就有了这个流程,从上可以看出,通此流程,seller、buyer的数据是可以保持一致的。

 

8)   流程分析
a)    创建订单

当收到init的消息的候,建立一个超滚订单的任务(例如3内如果订单未成功滚订单)。

订单创建过程遇到问题,则订单的状态将会被改成success,并success的消息。

收不到success的消息,任务订单创建失,就可以在时间执订单。(注意回滚以前先检查订单状态)。

当收到success的消息,将之前建的超滚订单的任取消掉。

到目前止可以保证订单、商品、分、惠券等的数据保持一致。

 

说明:以上流不建使用TCC的方式来实现分布式事物,因涉及方越多时TCC败的可能性越大,逻辑耦合性也越高。这里说的耦合性指:创订单其实只需要完成创订单的主流程,订单失败回滚的流程不属订单核心流程,应该算作是补偿的辅助流程。

 

 

b)    完成订单

收到订单success的MQ消息以后,需要删除之前的订单回滚任务。

如果订单不需要付款,那么直接用已付款接口将订单为paied;如果订单需要付款,那么创建订单超时关闭任务(例如15未付款闭订单

如果指定时间buyer未付款,通之前建立的超闭订单务执行关闭订单逻辑,此的操作和订单操作基本一,所以流程中我将合并了。

一般而言很多业务都会关心订单完成事件,例如通知中心,所以在流程中画了几个收到success消息的流程入口。

 

c)    卖问题

此流程先减存,然后再让订单创建完成,所以可以保不会出卖问题。如果允许商品超,那么可以将减一步已到付款成功以后。

为了防止被人恶意刷单,很多平台都采用此方式。

另外,如果与外部系统对接,减库存是一个很慢的操作,例如在飞猪上购买飞机票,此时可以下完成订单,然后用上层业务系统再调用机票系统出票,如果出票失订单取消掉,钱退回去即可。

 

d)    分布式系数据最一致性

从上面的流程中可以看出,在保证数据最终一致性上是如下处理的:按照业务需求行正向流程,并且在未按照预期执行的时建异常补偿流程。上面的流程带来的另外一个好处是:业务可以做大最大程度的解耦

MQ可以排除掉因、系统负载高等原因而致的失,所以只要代没有问题,重多次rpc调用会被最终执行掉

顺便提一句,有不少通过分段提交的方式来处理分布式事务,保证数据一致性。分段提交的原理是提前预执行sql,尽量减少提交操作失可能性,此种方式的性能失很害,理与相关的实时场景以外,一般高并发场景大都是只保数据的最一致性。

 

9)   解耦与扩展

讨论了订单创建过程,那么接下来我们讨论一下交易相关功能的解耦问题。

不知道大家是否注意到,上述流程其可以将耗时长的操作和耗短的操作分开了,从性能上而言,订单不会受到似于通知这类操作拖累。

任何系都可以订阅订单转过中的MQ消息,所以交易系可以只关注核心部分的容,其他的(交易系而言的)边缘操作可以完全从交易系中剥离出去,这样交易系内聚,极大的降低了和外部系的耦合。例如流程中关于建立滚订单取消订单的任都完全可以剥离到任,交易这边只提供回滚/取消订单的接口供任两个任务时调用即可。

 

 

5  买家付款

1)   流程

交易体系-交易、支付、物流、退款退货_第8张图片

如上简化流程图图所示,买家付款时主要包括以下内容:

进入支付系统的收银台页面选择支付渠道。

调用支付系统接口,根据付款渠道,生成付款订单payment_order),生成付款url

支付。

支付果回调。

支付系订单payment_order)状付款成功、MQ消息,并记录重要信息。

根据支付系MQ消息,修改订单biz_order、支付订单pay_order态。

2)   流程分析

从流程上可以看到,支付交易系核心要做的事情是生成付款url,最后根据付款果修改订单。修改状态时有两种选择

先修改pay_order的状MQ消息,然后根据MQ消息修改biz_order的状

修改pay_order、biz_order的状

pay_order是biz_order信息的延伸,非常建一起修改状,并在biz_order表中加上pay_status字段这样可以保任何候二者的数据都是一致的。这种一致性将会极大方便我们的业务处理流程。

 

 

6  卖家发货

1)    流程

交易体系-交易、支付、物流、退款退货_第9张图片

如上流程简图琐事,卖家发货时需要做一下事情:

卖家将公司、快递单号填写到物流订单(logistics_order)中,修改状MQ消息

修改订单(biz_order)、物流订单log_order的状态为待收

2)   流程分析

强烈建议biz_order、log_order的状放在同一个事物中更新,以保持一致性

如果希望简化物流相关的流程,在没有拆包、并包的情况下可以将log_order、logistics_order合并,这样处理流程可以化很多。

 

7  买家收货

1)   流程

交易体系-交易、支付、物流、退款退货_第10张图片

 

2)   流程分析

强烈建议biz_order、log_order的状放在同一个事物中更新,以保持一致性。

注意:logistics_order的状态应该根据物流公司的物流状来流,用操作不应该logistics_order的状,当然添加一个标记还是可以的。

 

8  评价

1)   分析

评价对于交易系统而言不是核心功能,而是一种属于商家、商品口碑,所以价以后,不应该直接修改biz_order的状,当然可以加一个标记字段。如果价以后修改状,那么至少在以下景中需要仔,以免留下坑:

后除了有一个等待期以外,存在退、退款的景,这些场景中是否允许评价?

多次,状如何修改?

2)   商品 VS 商家

直接问这问题不大, 为这和运策略有关,如果是平台自的,那自然是商品价;如果不是平台自,那么价可能是商品、也可能是商家,甚至别评价。

3)   评价核心

评价的核心是对商家、用户打分建立信用评级和用户购买提供参考。这部分不在此次讨论范围之内。

 

 

å  物流

一般而言,物商品交易程中订单有这几个状态,未付款、已付款(待发货)、已发货(待收货)、已收货、待评价、退货中(退款中)、已取消、交易关闭等。家付款成功,到买家收货;从退货开始到订单取消的过程中,都有物流的身影。接下来就主要讨论一下物流问题

 

1  流程

交易体系-交易、支付、物流、退款退货_第11张图片

这是一个简化的物流流程图简单描述了家、家、物流对订单的影响。

2  拆包与并包

物流最烦问题在与拆包和并包例如商品在不同仓库中的候,需要拆分成不同的物流;同一个仓库的商品可以合并到一个物流发货

1)    拆包

、考拉的做法是:单时判断商品是否在同一个仓库,如果在同一个仓库,那么建一个主订单;如果不在同一个仓库,那么分别为不同的仓库创主订单。

如果一个订单的商品比多,无法放在同一个包裹中,此也需要将一个物流拆成多个物流单。例如用户购买2个空,一个包裹放不下,此可能就会分成两个包裹分别发货

2)   并包

例如在天猫超市购买了一堆生活用品,可能天猫超市将所有的包裹打包成一个,一起发货

3)   解决方案

交易体系-交易、支付、物流、退款退货_第12张图片

图为实体的模型。

说明:

业务订单存在主子订单的情况,此一个主订单biz_order对应多个子订单biz_order)。

每个业务订单(biz_order)都有一个物流订单log_order

交易系中每个物流订单log_order)和物流系中每个物流订单(logistics_order)相对应。

并包和拆包属于物流系的核心逻辑应该放在物流系中。

拆包将原来一个logistics_order拆分成一个主单(logistics_order)多个子单(logistics_order)。可以这样处理:原来的logistics_order订单,并且新建多个子订单(logistics_order);也可以将原来的logistics_order做特殊标记,然后重新建一个主订单多个子订单。个人建使用第一种方案。

并包时为这logistics_order创建一个主订单,并将他们自己标记为这个主订单的子订单。

 

3  核心功能

物流的核心功能应该至少包括以下内容:拆包、并包、物流信息管理、对接第三方物流信息、物流明细管理。另外关于仓储和物流部分内容没接触,就讨论了。

 

五 支付

1  

支付系的第一个功能应该是封装第三方支付渠道暴露一个收台,用可以随意选择一种方式行支付。下是大众点的收台截图:

交易体系-交易、支付、物流、退款退货_第13张图片

接下来考简单的收面后面潜藏的各种业务逻辑,以及涉及的核心问题

1)   什么创建支付订单?如果已存在,是修改是新建?

这里说的支付订单是payment_order,用于和第三方支付接,和交易章的支付订单(pay_order)是不同的,注意不要混淆。

合适的机是用支付的可以检查一下之前是否已经创过过支付订单,如果未创建,那么可以创建一个;如果已经创,并且用了支付渠道,那么需要除重建或者修改原有的订单

a)    修改原有订单VS 新建支付订单

这两种的差别在于:一般都使用逻辑删除,所以新建支付订单生一些无用的数据,相比之下建在原来订单上修改。

b)    异常

如果开始A渠道支付并且付款,但是支付系统迟迟未收到A渠道的异步回通知;此另外一种支付渠道B支付并付款.未一笔订单支付了两次,所以必然存在问题,那么这种场景如何处理?理方式如下:

适合的一种理方式:以第一次收到回消息准,更新支付订单的支付渠道、状等信息;后面收到付款回通知时,一种方式是记录异常数据,人工理次数据并退款,另外一种处理方式是第二次收到消息以后,将此数据入MQ,收到MQ后自动原路退款(此的退款和用的退款流程是不同的,需要特注意)为这中异常景的生几率比小,建人工处理。

 

2)   封装第三方支付,提供一的收务。

种支付渠道支付所需要的信息都不同,理流程也存在差,所以支付系要将外的理流程做一封装,即做到于内部系而言,所有的支付渠道都是透明的,只关心和支付系的数据交

支付系的核心至少包括以下内容生成支付接、入第三方支付面、登或者识别维码、支付、返回当前用展示支付果,第三方通知支付果。这些功能中,入第三方支付面到付款部分的操作属于第三方渠道的事情,我无法干,其他部分是需要封装理的。

 

 

2  支付结果通知

支付存在金的流是一个很慢的,所以大部分情况下的第三方支付渠道会选择两种方式理:1收到支付求后立即返回,理完支付的所有操作以后,异步通知支付;2、提供支付等待面,支付成功以后再跳回介入方的网站。

在网上物的,输入完支付密以后,要么等待第三方支付渠道处理完成,然后进入我们的付款结果页,要么是立即返回到用的付款面。入付款以后,让用户选择已完成支付支付遇到问题。不管是哪种方式,在等待付款面中,都一个定时查询订单状态,如果收到支付渠道的成功果通知,即显示支付成功,修改付款订单、交易订单;如果一直没有收到支付果通知,可能会一直等待,也可能入失败页面。

 

3  流程

交易体系-交易、支付、物流、退款退货_第14张图片

支付订单的每一个状态变化都送了MQ消息,这样做的目的是实现业务解耦,让系统更加专注于自己的核心业务。例如:如果业务关注个事件,去订阅topic就可以了,如果不需要理此事件,直接忽略,交易系不用此而做额外的工作。

 

六 退与退款

1  流程图

交易体系-交易、支付、物流、退款退货_第15张图片

注意:因存在退款退,所以和商家算的候一定要留足时间订单处于退款退,不能和商家算此交易。

2  退货、退款流程

1)   提交退、退款申

验:入参校验;数据校;是否允退?提交的金是否大于最大可退金

根据订单数据、提交的退、退款申建退退款记录。

保存记录MQ

注意:为每一个biz_order创建一个Refund记录。

2)   卖家审核

卖家审核买家提交的退、退款申里可能需要核、打回退款申、平台介入等多个步

这一步骤主要目的是:买卖双方就退退款一事达成一致。经过卖家确认或平台确认的退、退款单应该不能随意被修改。

3)   货物退回

程和上面发货流程比较类似,所以不再述。

4)   卖家确认

程上面买家货流程较类似,所以不再述。

5)   退款

程和通第三方付款的流程比较类似,所以就不在述了。

 

3  

Trade赖RefundRefund赖Trade统?

退款退货时,可能有比杂的流程退款入口放在refund中,保持trade的干净,个角度上考虑让Refund赖Trade是合理的。所以上面的流程是根据refund赖trade画的。

另外简单四考一下,退退款都是基于订单的操作,如果让trade赖refund,目前看起来应该问题也不大。

 

七 

首先考一个景;假商家在平台上售商品,平台收取10%的佣金,那么当购买一个100元的商品并付款的具体流转过程是怎的?付款全部付商家,肯定是不行的,致平台无法收取10%的佣金,因为钱到商家账户后,平台无将商家的钱转移出来;付款如果将全部付平台,然后由平台和商家算,那其就是平台的收入,这样可能致平台多交税。大部分情况下,付款就需要将直接分到各方账户

 

八 

在本主要讨论一下服化的核心思想

1  交易场景

现实中,可能遇到以下几种不同的景。

1)  线上购买实物商品家通物流将商品送到家手中

例如淘宝、京上的购买商品,通物流收到去就好完成了交易的全程。

2)   线上购买线下消

大部分景中,其们购买的是一个子券,然后兑换物(影票);甚至不用兑换,直接线验证券的有效性(例如大众点、美售的服)。

其中兑换影票、线验证券的有效性(如果有效将享受线下服)其就是服程。

3)   线上购买服务,线上消费

例如:用费100购买了一个15钟专问诊,此整个流程的全部程均在线上完成。

4)   共性分析

购买一个服务和购买一个实物商品,交易过程并没有什么不同,不用的点在于是否走物流、是否有后续履约过程。

营销上看,不管是物商品是服商品,运同学可以通过营销惠券、分等包装服,来取更多的化;从支付、算、对账过程来看,两者也没有什么不同

为了更好的支持后续业务灵活多变的需求,比较好的处理方式是将交易、支付、算、对账、物流等流程抽象成一个准化服,根据不同的交易类型,决定后续的其他逻辑。

需要明的是:有些服也需要物流。例如基因检测务。购买基因检测以后,家先将基因检测盒通物流送到家手中,家收到基因检测盒以后讲带DNA的唾液等物放在盒子中寄回,基因检测公司收到盒子以后分析DNA,然后将发给

 

2  模型

交易体系-交易、支付、物流、退款退货_第16张图片

注意;此模型是了方便理解所以才没有一步抽象,而且可以抽取出来的准化服务业远远不止中列出的几种

从上中可以到出,通营销活动、交易、支付、算、对账物流等流程准化,可以极大的减少开成本,也是系解耦来的最大的好之一。

 

3  大中台、小前端

阿里很久以前就提出了大中台、小前端的组织架构思路,对应的技架构其本讨论的内容是一致的。

业务的特点是灵活且多变的,是当了推广业务会要求技上提供各种各的玩法支持。如果每个业务都各自开,将需要耗巨大的成本和时间重拖慢业务的脚步。从另外一方面来看,交易、支付、算、物流、分等模标准化服务,不会为卖实物商品和买虚拟服务就有所差别。

大中台、小前端思想的核心是:沉淀准、一、公共,做为对外暴露的服业务通过自由组合这些底层服务,对用户提供各种各样的玩法。

准、一、通用的服(即公共业务)抽象并沉淀到底,就是所的中台服。非公业务即小前端,通过组装中台提供的服来提供个性化服为业务提供灵活多的支持。要实现大中台、小前端的架构,需要先做好公共服的沉淀,而要做好服的沉淀,需要先做好服的解耦。

之前在平安的候,公司花了一年多的时间搭建、沉淀各种基,后来运同学开始通过营销来做拉新、提升日活等活动时于开同学而言就变得松,当初不管做什么活,基本上都可以保在一个月内上线(其发时间基本上就在5-7个工作日左右即可)

 

九 案例分析

买单

目前支付宝、大众点、美上都提供买单功能,我个人是没有做,但是我可以讨论一下实现方案。买单页面如下所示

交易体系-交易、支付、物流、退款退货_第17张图片

1)   订单确认页

看到这个图的时候,大家是否觉得和订单确认页面比较相似,但是少了订单认页面来核心的一内容:商品信息。

如果是我来设计这个功能,我会选择对给所有商家创建一个默认的商品,例如叫做:买单商品。上面的看作:以100元的价格购买一个买单商品订单确认页,只是商品信息藏起来了,这样就可以复用促销、优惠券、交易、支付、结算、对账等系统,而基本不用做任何修改。

为什么选择为每个商家建一个买单商品,而不是共用一个,或者订单时将商品空着首先交易的核心就是买家在某一个时间以某个价格购买卖家n个商品其中商品是核心要素,并且商品是依家存在的,所以需要每个建一个买单商品

当然个商品的价格是浮的,所以在db中会看到同一个商品的价格不同。

另外还有一点不同,从代码层面看,因商品价格不固定,需要从上层传递下来,一点和上面的方案是有差的(上面的方案中,商品价格从商品中取的)

2)   不参与惠金

和普通的订单认页的另外一个差多了一个不参与惠的金这里可以看作是一个特殊的优惠。惠有:直降、折扣、减、折等,他都是在原有订单上直接算的;而个特殊的惠的定可以看作是:需要在订单总金额的基上排除一部分金以后再计算优惠的特殊惠。

 

 

2  随机立减

使用支付宝、微信付款的候,想必大家都遇到随机立减的景了。首先明,这应该是付款渠道方的一种惠方式,非支付平台不适合做惠方案。以下是一种设计方案

付款接付款,微信、支付宝受到支付求以后,判断是否要随机立减,如果需要,那么生成一个随机立减的金,于是得到待支付金额=总金额-随机立减金。接着生成两条付款明,一个明从支付宝/微信账户中扣 另一个明从用的(支付宝/微信账户中扣钱。

 

3  购物红包

提前明一下:里想讨论包是在淘宝、天猫上使用的购物红包,而不是微信红包,支付宝红包。

购物红包在订单确认阶段使用,其本是抵扣

支付宝、微信包是转账,从一个账户转移到另外一个账户,可以提

1)   示例

天猫包列表,如下所示

交易体系-交易、支付、物流、退款退货_第18张图片

如下所示,在天猫的订单认页面中,用认订单时,可以选择使用包抵扣。

交易体系-交易、支付、物流、退款退货_第19张图片

 

2)   特点
a)    购物类红包有以下特点

一般有效期。

红包的金额一般不固定。

没有使用限制,即一般不要求满x元可用。

目前到平台上一个购物红包都属只能使用一次,例如100元的包,如果此次额为50元,那么剩余部分也不能使用。(不确定是否所有的包都是如此)从一点上看,和惠券有点似。

有一个金池子,每一分包,就从金池子中扣掉一分钱。

b)    灵活

购物红包是平台刺激用户消费的一个很好的方式,它不会局限于订单,比惠券灵活很多。需注意,后期对账、清算、算可能和惠券会有差问题暂讨论

c)    资金池

目前据我了解到的情况是这样的:双十一活,商家发红包需要提前在平台缴纳金,将准金作一个池子,每发一个红包,从池子中扣减一部分金额。淘宝、天猫平台的包是否有个池子我就不确定了,不过应该是有的。

业务特点来看,很有必要有一个金池。若没有金池子,那么包就成了一条流水记录了,无法限制总的发放量,这对于营销活动是一件很危险的事情。

 

3)   交易流程

将使用包的类比于积分抵扣过程,在交易中增加“红包抵扣”这一环节,就可以复用之前的整个流程

至于订单取消、退款的候是否需要退还红包,个需要看业务的需要,如果需要,那么在MQ消息中将对应红原即可。一般都不会原已使用的包。

 

4  定金+尾款

双十一的候,我们经常看到天猫上有一种促方式:提前下定金、双十一当天付尾款。如此一来可以预热,二来可以整个活的成交都累到双十一当天,方便他冲量。

接下来思考一下实现方案。相比于之前讨论的交易流程,这里唯一在于本来是一次付款,在改成两次付款。可以考以下实现方案。

创建订单过程:我会考商品身上的特殊标签,在biz_order表中冗余起来,同时创建两条pay_order记录,一个是定金的,一个是尾款的。

付定金程:通定金的pay_order在支付系中生成payment_order,接着走付款流程。

付尾款尾款的pay_order在支付系中生成payment_order,接着走付款流程,唯一需要注意的是,可能会有付款时间限制,例如必是双十一当天可付。

 

十 其他说明

1   弱化的概念

需要注意的是:交易部分中,有一个核心的概念类目、商品类型,不过为了描述流程更加简单清晰,我刻意弱化了个概念。注意:商品型由商品目决定,而交易流程中的差异化部分都是通此商品型来的。

 

 

你可能感兴趣的:(前端,系统架构,大数据,ViewUI)