涉及到的服务：
shiyi-pingan:平安代理服务
shiyi-account:账户服务
shiyi-cash:出入金服务
shiyi-admin-web:后台管理服务
shiyi-scheduler:定时任务服务
提现非请求渠道阶段时的流程图和时序图
流程图
提现非请求渠道阶段时的流程图
说明：用户在app提交提现申请后，会为用户新增一个状态为“初始化”的提现订单，并且异步调用账户服务，扣除用户余额，当用户余额扣除成功后，将订单状态更新为“待审核”状态，否则更新为“提现失败”状态；管理员在后台管理系统上对用户的提现申请进行审核，审核不通过时，更新订单状态为“审核不通过”，并将钱退回给用户。审核通过则直接更新提现订单状态为“审核通过”状态，后续将会让审核通过的订单请求平安银行进行真正的提现。
时序图
提现非请求渠道阶段时的时序图
说明：前端请求出入金服务进行提现申请，出入金服务立即同步返回结果给到前端，并且创建订单，异步调用账户服务扣除用户余额，账户服务会把扣除用户余额的结果异步返回给出入金服务，出入金服务根据结果更新提现订单状态。后台管理服务调用出入金服务审核提现订单，审核通过则更新订单状态，否则异步调用账户服务为用户加钱。
提现请求渠道阶段时的时序图
提现请求渠道阶段时的时序图
说明：定时任务服务，定时的向出入金服务发送向银行请求1318接口的指令，出入金服务获取当前系统处于“审核通过”的订单，并将这些订单异步请求平安代理服务，此时将订单状态修改成“系统处理中”，让平安代理服务请求平安银行实现真正的提现，平安银行同步返回结果给平安代理服务，平安代理服务收到返回结果后，将请求结果异步通知出入金服务，出入金服务收到通知后，无论结果是成功还是失败，都将提现订单状态修改成“渠道处理中”状态；
定时任务服务，定时向出入金服务发送向银行请求1325接口的指令，出入金服务获取当前系统处于“渠道处理中”状态的提现订单，并调用平安代理服务接口请求银行的1325接口，查询处于“渠道处理中”状态的订单是否在银行端那边已提现成功，若银行端返回结果是“提现成功”的结果，则将订单状态修改成“提现成功”状态，否则将订单修改成“提现失败”状态，并异步请求账户服务，为用户加钱；
平安银行主动发起提现请求，向平安代理服务发起1312接口请求，出入金服务监听1312请求接口，监听到有请求过来，则创建“审核不通过”状态的提现订单。定时任务服务，定时的向出入金服务发送向银行请求1317接口的指令，出入金服务获取由银行端发起的出金请求所创建的提现订单，通过调用1317接口，通知银行那边该订单在交易网这边审核不通过，无需对其进行出金。
提现接口说明
1318接口：交易网向银行端发起出金请求接口；
1325接口：查询某个时间段内或者查询指定订单号的提现订单在银行那边的状态，即提现成功还是失败；
1312接口：银行端向交易网端发起出金请求（这里直接创建“审核不通过”的提现订单，是因为银行端发起的出金，不进行处理，一律视为审核不通过，不对用户进行提现）；
1317接口：出金确认请求接口，即告诉银行那边，是否对某个订单进行出金。
提现订单状态变化说明
提现订单状态图
路线1：用户app提交提现申请后，创建状态为“初始化”的提现订单，并且扣除用户余额，若扣失败，则将状态更新为“提现失败”状态，反之，将改成“待审核”状态；后台审核该订单，审核不过，则将状态改为“审核不通过”状态，反之，改成“审核通过”状态；审核通过后，定时任务会定时的获取审核通过状态的订单，请求平安代理服务的1318接口，这时将订单状态改成“系统处理中”状态，平安代理服务真正的调用1318接口请求银行，返回结果后，将订单状态修改成“渠道处理中”状态；定时任务服务会定时的获取渠道处理中的订单，并且调用1325接口查询订单是否出金成功，若1325接口返回成功，则将状态改成“提现成功”状态，反之改成“提现失败”状态。
路线2：银行端发起出金，交易网监听1312接口，监听到银行端发起的出金请求，则创建“审核不通过”状态的订单，不扣除用户余额。
问答环节
问题1：为什么会有“系统处理中”和“渠道处理中”这两个状态，这两状态可以合为一个状态吗？
答：系统架构是微服务架构，分了很多个服务，从【图:提现请求渠道阶段时的时序图】可看出，定时任务服务向出入金服务发起请求1318接口的指令，出入金服务异步通过平安代理服务间接请求银行的1318接口，然后平安代理服务会将银行给过来的结果异步通知到出入金服务，这时，出入金服务就将状态改成“渠道处理中”的状态。那么，为什么要分成“系统处理中”和“渠道处理中”这两状态呢，为何不直接将状态改成“渠道处理中”，这样不是更省事吗？ 答案当然是非也。
我们来设想一个场景：定时任务在请求1318接口时，出入金服务将状态改成“渠道处理中”状态后，这时，定时调用1325接口的任务也开始运行了，刚刚好拿到了这笔订单，这时请求1325查询该订单出金结果，发现该订单没有发送到给渠道那边，那么我们就会将该订单的状态改成“提现失败”，并加回之前扣的钱给用户。但是，由于是MQ异步发送请求1318接口消息给平安代理服务，这时，平安代理服务才刚刚消费到这个订单，这时去请求银行将这笔订单出金，那么这样系统的用户余额跟银行那边的用户余额就不一致了，因为银行那边出金了，会扣除用户余额，而我们这边却将这笔订单置为“提现失败处理”，并且加了用户的钱。所以，这两状态是不能合并成一个状态的。
问题2：结合【图:提现非请求渠道阶段时的流程图】和【图:提现非请求渠道阶段时的时序图】，用户提交提现申请后，出入金服务创建“初始化状态”订单，然后异步发送消息给账户服务扣除用户余额，扣除成功后账户服务再将结果发送消息通知出入金服务，出入金服务再将该订单状态改成“待审核”状态。在这个过程中，账户服务扣除用户余额成功后，挂掉了，不能将结果通知到出入金服务，那么，这个订单将会一直是“初始化”状态，这样的订单要怎么处理呢？
答：处理方式有两种。1.人工发现后处理；2.在签退后，发起出入金对账后，会将这笔订单置为异常订单（短款差异<交易网有，银行没有>）。这时就要进行调账处理，将用户的钱加回去，并将订单状态修改成“提现失败”状态。
网友评论