金融信贷业务-贷中整理

目录

金融信贷贷中-3条流向线

金融信贷贷中-交易模式

金融信贷贷中-技术挑战

---

       金融信贷业务贷前开通授信通过充分客群识别、客群资金通道路由的方式，为用户适配最佳资金通道、借款额度、借款利率；当用户获取到相应的额度、利率、资金通道后，就可以进行资金交易，进入贷中贷款、贷后还款环节；

贷中需要解决的核心问题有哪些：

• 是贷款交易过程中我们维护的资金流、信息流、状态流有哪些？
• 要维护这些业务能力首先理解我们基于什么样的交易模式构建贷款服务以及其中的考量是什么？
• 我们面临的技术挑战有很多（例如，资金数据的一致性问题），通过什么技术方案解决上述两方面的问题？

金融信贷贷中-3条流向线

资金流——金融平台账务会在用户获取授信额度后为用户创建账户（涉及账务专业业务领域），用户通过金融平台产品发起贷款，最终资金会从金融平台账户流出，流入用户个人借记卡账户，金融平台的资金源头是第三方资金机构；

信息流——金融平台不同业务系统会承载不同的业务语义信息，核心的业务信息节点包含用户借款请求单、打款请求单、借据订单、还款计划单，其中业务侧还会去关注一些贷款试算信息、优惠券信息、风险核查信息、外送资金方指标信息等；

状态流——针对标准贷款和预授权贷款两套模式（后续展开），用户的各账户资金流转过程也要流经不同的业务节点；

• 标准贷款模式主要经过贷款申请(用户金融平台/资金方账户额度扣减)，贷款成功后的打款申请（资金有商户账号流向个人账户），打款失败后的打款撤销（恢复账户额度）3个业务子节点；

• 预授权贷款模式主要经过预授权申请（用户金融平台/资金方账户部分额度冻结），业务进行人行授权/外呼确认(耗时)，授权确认成功后预授权确认（金融平台/资金方账户相应额度扣减），授权确认失败的预授权撤销（相应额度解冻），预授权确认成功后的打款申请（资金流向个人账户），打款失败后的打款撤销（恢复账户额度）；

金融信贷贷中-交易模式

• 交易模式主要涉及到标准贷款模式、预授权贷款模式，核心流程都是要维护用户的资金流向从金融平台账户/资金方（商户）账户—>到用户个人银行账户的流转过程，以及中间要经历平台/资金方账户额度从冻结到扣减，对用户个人银行账户的资金打款 这些流程都是不变的；
• 在用户发起贷款，金融平台资金账户从冻结、到扣减流转的过程中，对于一些风险识别为贷款中介/无人行授权资质的用户，需要额外对用户进行外呼确认/人行授权，这是一个相当耗时的过程；为了避免过程中用户的流失，所以引入的预授权的模式，通过预授权申请对用户额度进行冻结；待授权确认成功后再进行预授权确认扣减用户额度，预授权确认成功后发起打款，确认失败后会进行打款撤销；

金融信贷贷中-技术挑战

• 贷款过程每一个业务环节都要依赖上一个业务事件的触发，如何处理资金流转过程的异常情况（未到终态或者无法流转到下一环节），业务引入异步消息监听、补定时、事务等机制保障数据的最终一致；
• 涉及到借据数据、还款计划数据水位瓶颈时，无法避免要进行分库表，分库表要以保证同一业务逻辑本地事务支持为前提，尽量避免引入分布式事务管理的性能损耗；
• 复杂业务状态流转有必要引入状态机； 预授权贷款模式涉及6个子业务流程：预授权申请、外呼人行确认、预授权确认、预授权撤销、打款、打款撤销；不同的子业务触发事件会根据不同的贷款订单状态做不同的贷款动作，利用状态机模型可以使贷款业务流转过程更加清晰，易于理解和扩展；

首先看下，借款交易的核心技术流程方案：

 

• 贷款流程上分两个大子流程：贷款、打款，其中贷款负责资金方账户的额度+金融平台账务额度的冻结、扣减，打款负责资金真正流转到用户个人账户；贷款流程分为4个子流程：电子协议签章+优惠券（优惠券使用+优惠券撤销）+贷款发起(预授权申请+预授权确认+预授权撤销）、贷款成功短信通知，打款流程分为3个子流程：打款（打款成功+打款核销）、同步资金方还款计划、打款成功短信通知；
• 考虑涉及业务流程都需要满足最终一致性，但是有些子流程对响应时延要求高?比如贷款、优惠券；有些子流程响应时延要求不要求电子签章、贷款成功短信;时延要求高的我们引入分布式事务的思想，但是不引入分布式事务的实践方案；（原因：a、分布式事务需要维护TC、TM、以及业务活动管理器的组件高可用集群成本；b、业务操作不光涉及内部服务，还涉及很多外部的资金方服务TM|TC|业务活动管理器无法管理资金方的服务；c、引入分布式事务，我们代码中还有很多dubbo调整，时间长度不可控，会极大的增加数据库的负担；）对时延要求不高的业务我们使用异步化的方式，缩短贷款主业务流程的耗时；
• 一致性时延要求高：优惠券-saga长运行时间事务的冲正补偿思想，正向用券、逆向撤销券；贷款交易-TCC（try-confirm-cancel），对应业务的预授权申请、确认、撤销，另外一种补偿；除了有逆向补偿、还要有对初始、处理中的操作的正向补偿；但是都不引入业务活动管理器的高可用集群维护成本（打款交易也是如此），由于业务服务自行管理业务流转；
• 一致性时延要求不高：电签、短信通知服务等，调用相关服务收单，后异步处理，默认必须成功，无需补偿冲正；
• 不管什么操作都要考虑：幂等+分布式锁+可靠消息通知的通用处理

后续考虑不引入分布式事务组件的前提下，对现有业务操作的流转进行状态引擎统一管理，提升贷款业务流程效率，方案调研：

• 贷款活动业务涉及的补偿类操作，都是通过业务操作所在服务拆分不同的业务模块自行处理，如果有一个统一的组件可以管理业务操作的流转；业务代码接入可以更加快捷清晰；（状态机引擎串联长时间事务的流转）；
• 参考阿里seata（一站式分布式事务解决方案）的基于状态机引擎的 Saga 实现：https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/107273472

​​​​​​​​​​​​​​​​​​​​​

状态机简介

状态机简写为FSM(Finite State Machine),主要分为2大类：第一类，若输出只和状态有关而与输入无关，则称为Moore状态机；第二类，输出不仅和状态有关而且和输入有关系，则称为Mealy状态机。

状态机分为状态机实现和应用系统实现两个部分:

1. 状态机实现:打包成jar供应用系统使用
2. 应用系统实现:
   1. 应用系统自定义状态机状态规则
   2. 将状态机注册到spring中,即配置spring-statemachine.xml文件,文件注册了状态机bean
   3. 应用系统实现interface FlowContextFactory.java
   4. 应用系统实现interface FlowStoremanager.java