一、主题分享
今天给大家分享了一下代收付系统重构的一些实践（最近正在基于原有的代收付系统进行改造，主要试点项目供应链金融，分享内容并没有充分描述细节，只围绕主流程，总体架构，以及设计的数据领域模型，并没有详细设计到底层的详细逻辑，支付结算，账户体系等）。
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:第一个通过任务，进行补偿查询，长时间无结果的通过对账报警，发送给运营人员，进行解决，确认结果以后，从新发起，第二个目前接入的渠道还不多，主要维度成功率，稳定性等
Q3:成功率是有专门的系统统计吗？
A1:成功率 只是内存数据库一个key的更新再加些策略 成功笔数/总笔数 没那么复杂
Q4:针对代付有没有头寸管理啊
A1:代付当然要有头寸管理啊,代付头寸对应支付公司代付同道路由.每家代付渠道的价格和可垫资头寸也在考虑范围内
Q5:你们分布式任务框架选型时都参考哪些？最后选的是？
A1:分布式框架 自己写的 zk+quartz
A2:任务框架选型是***网的elasticjob分布式框架，切换的时候掉单率低
Q6:这个代扣与代付，我理解不知道对不对，代扣是根据用户的绑卡信息扣还款到咱们的资金池，代付是指我们统一进行对资金方的还款么？
A1:代扣代付只是个资金方向，都是往账交易，代扣是跨行把资金归集到本地，代付是将本地资金汇出去，跟场景结合的话，你的理解是对的
本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
