一、主题分享
今天给大家分享了一下代收付系统重构的一些实践（最近正在基于原有的代收付系统进行改造，主要试点项目供应链金融，分享内容并没有充分描述细节，只围绕主流程，总体架构，以及设计的数据领域模型，并没有详细设计到底层的详细逻辑，支付结算，账户体系等）。
1、痛点分析
-
业务量: 随着业务量的增长，原有的架构未来必将面临更多的挑战，运营童鞋每天都会有每日代扣结果统计日报，能明显看出数据量的增加，以及双十一，双十二等促销节的流量高峰，采用elasticJob自带的流式处理，应对业务量的增长。
-
业务场景: 对于场景的不断增加，开始只有A行一种渠道，最终演化出来B，C，D等,资金方参与也在增加，而对于每一种场景都设计一套交互代码，落了一份数据表，最终导致，业务交叉，数据交叉，难以统一管理。
-
代扣节点: 代扣节点不统一，有的代扣，每天扣款点在12:00，18:00，有的10:00，14:00，18:00等，很难统一，而且对于特殊需求，用户包括运营，催收等人员也系统能够变动节点。
-
短信节点: 短息提醒，逾期提醒，成功失败提醒等，有着不同的规则，A业务有两种规则，B业务有自己规则，缺乏统一，而且也是很难去改动。
-
算费／换期: 由于不同的资金方采用的预期费率不一致，导致规则不统一，代码写死，很难针对不同场景去更改算费规则。
-
对账: 现有的数据落地不统一，字段不统一，很难和银行的的流水进行一一勾兑，财务人员对账工作量大，难度大。
-
系统架构: 系统架构分为两个系统，A系统需要循环和B系统交互，网关代扣代付系统嵌套在网关系统中，交叉严重，难以管理，任务很容易受其他项目发布，而不影响，导致批量数据异常。
-
界面管理: 目前缺乏统一界面管理，全部都是由其他业务方捞取，但对于内部人员，没有一套界面，很难去查看分析，优秀的界面应该包括统计分析（柱状图，饼状图等），代扣代付明细，流水明细，配置数据明细，以及对于数据的增删改查
-
数据结构: 对于多种场景，随意落数据库，随意扩展字段，最终造成数据难以筛选，难以管理，散落在不同的表中，对于公用，通用的进行抽取，归类
2、业务概述
为各类金融业务的还款业务赋能，解决线上化资金闭环。
应用场景
-
融资租赁月租还款
-
消费金融分期还款
-
供应链金融还款
主要业务流程
-
同步业务订单流程
-
还款计划生成流程
-
签约绑卡流程
-
代扣代付计划执行流程
-
逾期算费换期流程
-
资产转让流程
-
还款催收流程
3、技术架构
（1）架构原则
-
整体架构采用分布式架构方案
-
对上游系统统一采用MQ方式通知，解耦依赖
-
将代收付核心服务与代收付任务分应用部署，以达到服务高可用与任务稳定性
-
对外统一由API模块以DUBBO接 方式提供服务
-
系统内部对于算费执行任务以配置化架构思想，以达到灵活扩展目的
（2）功能说明
-
整体分为: 代收付核心服务、代收付计划任务、代收付API三部分
-
代收付核心服务提供给上层代收付计划任务与代收付API调用底层服务完成功能
-
代收付计划任务系统由代收付任务、逾期算费任务等任务逻辑
-
代收付API模块对贷后催收等业务系统提供还款计划查询，暂停，结清账单等支持
（3）要点说明
-
幂等性:在执行代收付任务或者业务调用结清时需要严格控制幂等性，防止重复扣款付款
-
分布式任务支持: 面对将来账单的增量，需要保证以分布式方式执行 ，按时完成执行
-
可配置性:逾期算费与任务可配置，以应对业务的变化，无需频繁系统发布
-
高可用性:多代收付渠道支持，能做到能主备切换，应对极端情况下渠道不可用时能支持业务
（4）主要技术依赖
-
消息中间件:解耦业务系统
-
分布式任务框架: 支持各类任务分布式调度，支持手动触发、重试等功能
-
DUBBO框架:使得应用分布式部署
二、Q&A
Q1:如果一张卡在一个通道扣不下来钱，你们会换到别的通道继续扣吗？
A1:目前还不会，我们每天会有两次扣款机会，后期会支持.
A2:每天扣两次就够了，别太多了啊. A3:恩 ,通道一般都有成功率限制 .代扣次数也有限制.分布式任务框架 +可配置型针对定时任务,可以做在一起,很方便.
Q2:1，如果支付渠道长时间不返回明确结果， 你们怎么解决呢？
2，支付路由规则从哪几个维度来抉择的呢？
A1:长时间不返回结果 可以通过延时队列加延时策略进行处理最后通过定时任务轮训加对账确定最终结果 支付路由 我们这边一般会根据具体的支付业务,成功率 以及商户指定的支付机构几个维度确定
A2:第一个通过任务，进行补偿查询，长时间无结果的通过对账报警，发送给运营人员，进行解决，确认结果以后，从新发起，第二个目前接入的渠道还不多，主要维度成功率，稳定性等
