-
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
325 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,325 @@ | ||
|
||
|
||
|
||
## P2P贷款项目 | ||
|
||
贷款分类: | ||
|
||
先息后本 (先还利息,最后还本金)12 个月 1-11个月都是还利息 12 归还本金 | ||
|
||
每月等额 (每个月还款的金额是一样) | ||
|
||
**简单业务:**最近做的是一个小额贷款 APP,支持3 - 36 期的借款,随借随还,按日计息。 | ||
|
||
就是一个小额贷款 支持3 - 36 期的借款,随借随还,按日计息。 | ||
|
||
**功能:** | ||
|
||
微服务模块 | ||
|
||
用户,授信,借款,风控,支付,催收,运营系统 , 短信微服务 | ||
|
||
能写的功能: | ||
|
||
风控 --- 调用第三方数据 获取额度 | ||
|
||
支付 ---> 还款 | ||
|
||
对账 ---> 目的:保证第三方和自己系统的数目没有差错。 | ||
|
||
催收 --- > 已经逾期的数据。 | ||
|
||
使用定时器,查询所有未还款的用户 查询前一天未还款的用户 把这些信息保存到催收表当中 | ||
|
||
where 还款时间 = 前一天 and 还款 还是未还款 | ||
|
||
发送短信提醒用户还款 | ||
|
||
1 2 4 5天之间打电话 | ||
|
||
一般情况下 逾期第一天,会短信提醒用户还款。 | ||
|
||
如果逾期5天,会电话回访,打电话叫你还款。 | ||
|
||
如果逾期30天,打电话给紧急联系人,打听你的情况。 -----> | ||
|
||
|
||
短信 ---> 发送各种类型的短信 | ||
|
||
催收 : | ||
|
||
逾期: | ||
|
||
定时器 : 每天凌晨1点查询 预期的用户 | ||
|
||
如逾期1-3 天 短信提醒用户还款 | ||
|
||
如果3天以上 --- 工作人员打电话催收。 | ||
|
||
如果逾期1个月 打电话给紧急联系人。 | ||
|
||
多沟通 多交流 遇到问题 需要快速交流 | ||
|
||
按功能业务就是按模块 | ||
|
||
**我负责的功能:** | ||
|
||
1、主要负责支付服务 | ||
|
||
2、负责授信服务:对接第三方的风控,获取用户的授信额度 | ||
|
||
运营系统,授信人工审核。对 完成身份认证 ocr 认证和人脸识别 | ||
|
||
1. 对账等功能的完成 | ||
|
||
|
||
**技术栈:** | ||
|
||
1.采用SpringBoot+SpringCloud作为微服务架构 | ||
|
||
2.服务注册与发现采用Eureka,对服务进行集中管理 | ||
|
||
3.网关采用Gateway,形成客户端请求唯一入口;服务调用使用Fegin,面向接口进行各服务之间的通信 | ||
|
||
4.统一使用SpringCloud Config作为配置中心,对各微服务的配置进行集中管理和调度 | ||
|
||
5.利用Feign集成Hystrix技术实现服务的熔断,在网关的接口调用阶段对故障服务实现服务降级,以达到。 | ||
|
||
6.高并发下的系统保护机制 | ||
|
||
7.Mybatis实现数据库与实体类的映射 | ||
|
||
redis 缓存 rabbitmq 消息队列 | ||
|
||
需要用户授权 人脸识别 还有需要用户的基本信息 | ||
|
||
提醒还款功能 | ||
|
||
定时器:查询还款计划表(根据当前系统时间+2天 = 还款的日期 and 还款状态为未还款) 逾期5天以内 | ||
|
||
执行短信微服务 发送短信 (你好,xxx , 如果已经还款,请忽略这条短信...) | ||
|
||
定时器:查询还款计划表(系统时间当前时间 -1天 >= 还款时间 and 未还款的状态 ) | ||
|
||
执行短信微服务 发送短信 (你好,xxx , 如果已经还款,请忽略这条短信...) | ||
|
||
催收 : 如果用户预期都进入催收系统 | ||
|
||
催收表: | ||
|
||
催收还款计划表: | ||
|
||
还款: 还款计划 | ||
|
||
4W 借款 | ||
|
||
1-12 :1.1 | ||
|
||
如果预期5天 系统展示的颜色标红 | ||
|
||
小额贷款的 | ||
|
||
我讲一下业务流程? | ||
|
||
### app业务流程 | ||
|
||
第三方法 会自动计算 | ||
|
||
但是我们后台可以改变的贷款额度的 | ||
|
||
\1. 用户登陆注册成为平台用户。 | ||
|
||
\2. 身份认证 | ||
|
||
2.1 上传身份证正反面照片,调用第三方接口(天眼数聚)验证身份证真实性 ( 一张正面照片和一张反面照片) | ||
|
||
2.2 进行人脸识别,调用(天眼数聚)的接口,验证身份证和当前操作是同一个用户。 | ||
|
||
\3. 基本信息录入。 | ||
|
||
\4. 工作信息录入。 | ||
|
||
\5. 紧急联系人信息录入。 | ||
|
||
\6. 用户授权 | ||
|
||
\7. 后台生成一笔授信请求记录。 查看人行的征信报告 | ||
|
||
\8. 人工审核授信记录,通过进入下一环节,拒绝用户重新提交。 | ||
|
||
\9. 人工审核通过后推送数据到 风控系统。 生成授信分数。 | ||
|
||
\10. 接收风控系统的异步回调,生成授信额度 (可以借款的总额度)。 | ||
|
||
\11. 用户申请借款,输入借款金额,借款期限,用途,后台生成一笔借款(流水)标的状态为人工审核中。 | ||
|
||
\12. 后台运营系统对借款标的进行审核,审核通过提醒用户签订电子合同(E签宝)。 状态:待签订合同 | ||
|
||
\13. 推送借款标的给资金方(P2P理财,合作金融公司) ,状态:放款中 | ||
|
||
\14. 资金方放款成功后,发送放款通知,更新状态为还款中,生成还款计划。 | ||
|
||
\15. 还款分为主动还款和系统代扣 | ||
|
||
是的 我们也是这样的 | ||
|
||
上个面试官都说过了 | ||
|
||
谢谢面试官 辛苦了 。 | ||
|
||
mq 用在哪些地方 | ||
|
||
风控异步回调信息放在mq中 , 业务系统监听mq消息,把消息保存到数据库中 | ||
|
||
支付,发送短信 。 | ||
|
||
redis 用在哪里 首页的缓存数据,广告和轮播图这些。 | ||
|
||
分布式锁。防止重复还款(防止重复支付) | ||
|
||
mq的延迟队列: 如果10-29号是还款日,当天会发一条消息给你,并且进入延迟,如果今天没有还款,隔24小时,(先查询是否还款)提醒已经逾期,尽快还款,如果已经还款,请忽略这条消息。 | ||
|
||
\16. 逾期数据被催收采集任务,获取逾期数据,导入到催收系统。 | ||
|
||
定时任务:每天凌晨1点,会查询逾期的记录,把逾期数据放到催收系统中。 可以按时间排序。 | ||
|
||
### P2P 支付流程 | ||
|
||
(1)商户后台系统根据用户选购的商品生成订单。 | ||
|
||
(2)用户确认支付后调用微信支付【[统一下单API](https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=9_1)】生成预支付交易; | ||
|
||
(3)微信支付系统收到请求后生成预支付交易单,并返回交易会话的code_url。 | ||
|
||
(4)商户后台系统根据返回的code_url支付链接。 | ||
|
||
(5)微信客送到微信支付系统。 | ||
|
||
(6)微信支付系统收到客户端请求,验证链接有效性后发起用户支付,要求用户授权。 | ||
|
||
(7)用户在微信客户端输入密码,确认支付后,微信客户端提交授权。 | ||
|
||
(8)微信支付系统根据用户授权完成支付交易。 | ||
|
||
(9)微信支付系统完成支付交易后给微信客户端返回交易结果,并将交易结果通过短信、微信消息提示用户。微信客户端展示支付交易结果页面。同步回调 | ||
|
||
(10)微信支付系统通过发送异步消息通知商户后台系统支付结果。商户后台系统需回复接收情况,通知微信后台系统不再发送该单的支付通知。 慢一点 | ||
|
||
(11)未收到支付通知的情况,商户后台系统调用【[查询订单API](https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=9_2)】 | ||
|
||
(12)商户确认订单已支付后给用户发货。 | ||
|
||
|
||
0.根据用户选择的支付方式,调用支付前置服务(支付宝前置,微信前置服务等)。 前置服务对接银行或者支付公司的接口。这个是用策略模式实现 | ||
|
||
1. 内部业务系统封装请求参数,按照文档生成签名调用支付接口。 | ||
|
||
2. 支付系统,验证请求参数,验证签名等 | ||
|
||
3. 获取到银行或者支付公司的返回的支付URL或者是预支付会话。 | ||
|
||
4. 根据url或者是会话标识 跳转到支付页面。 | ||
|
||
5. 用户在支付页面完成支付,银行或者支付公司发起同步回调和异步回调。(同步回调跳转支付完成后的页面,异步回调更新数据 流水号和 状态 更新到mysql 就是更新还款表的状态和 还款流水 )。 | ||
|
||
6. 支付系统接收到异步回调,验证请求,更新支付流水状态。响应银行或者支付公司,success(成功)。(响应success后不需要银行或者支付公司再次回调)就是更新还款表的状态 和 还款流水 | ||
|
||
7. 支付系统发送支付请求给业务系统,通知支付结果。 | ||
|
||
### 数据库设计 | ||
|
||
#### 数据库设计 | ||
|
||
##### **用户服务:** | ||
|
||
**用户表:**主键id,用户id,密码,眼,状态,注册时间,手机号 | ||
|
||
**登录日志表:**:主键id,用户id,时间,手机信息,(imei),地理位置信息, | ||
|
||
**用户基本信息表**:主键id,用户id,姓名,证件类型,身份证号码,身份证地址,学历,现居住地址,是否实名,邮箱 | ||
|
||
**工作信息表**:主键id,用户id,单位名称,电话,地址,职位,薪酬,入职时间 | ||
|
||
**联系人信息表:**主键id,用户id,联系人一,1关系,1电话,联系人二,2关系,2电话 | ||
|
||
**银行卡信息表(一对多)**:主键id,用户id,银行卡四要素,状态,时间。 | ||
|
||
**Ocr认证表:**主键id,用户id,类型(身份证ocr、人脸ocr),状态,时间 | ||
|
||
**图片表:**主键id,用户id,类型(人脸图片,身份证正面,身份证反面),地址,时间 | ||
|
||
##### 借款服务: | ||
|
||
借款流水表:主键id,用户id,手机号,姓名,借款额度,借款期数,借款用途,还款方式,申请时间,状态(申请中等待人审,通过等签合同,放款中,还款中,完成),利率,等等 | ||
|
||
人工审核表:主键id,用户id,审核人员,审核原因,时间... | ||
|
||
电子合同表:主键id,用户id,加快流水表,合同状态,合同路径,签订时间 | ||
|
||
资金方返回的结果表,主键id,用户id,借款流水,资金方返回的原始数据,状态,返回时间,返回id, | ||
|
||
(一对多) | ||
|
||
还款计划表:主键id,用户id,还款计划id,期数,还款本金,还款利息,应还本金,到期还款日 | ||
|
||
设计到 | ||
|
||
##### 授信服务 | ||
|
||
**授信记录表:**主键id,用户id,授信流水号,状态(申请,人工拒绝,通过风控审核中,风控拒绝,风控成功),创建时间,更新时间。 | ||
|
||
授信审核表:主键id,用户id,授信流水号,审核人员编号,审核状态,原因,审核时间 | ||
|
||
风控返回记录表:主键id,授信流水号,风控返回id,风控返回元素数据json,返回时间 | ||
|
||
授信额度表:主键id,授信流水号,用户id,授信额度,可用额度,状态,授信额度生成的时间,更新时间, | ||
|
||
##### 爬虫服务: | ||
|
||
**社保信息表:**主键id,用户id,原始社保JSON数据,任务id,获取时间,状态 | ||
|
||
**手机运营商数据表:**主键id,用户id,原始社保JSON数据,任务id,获取时间,状态社保JSON数据 | ||
|
||
**公积金信息表:**主键id,用户id,原始社保JSON数据,任务id,获取时间,状态 | ||
|
||
**信用卡账单信息表:**主键id,用户id,原始社保JSON数据,任务id,获取时间,状态 | ||
|
||
##### 还款服务 | ||
|
||
**还款计划和还款流水,一对多** | ||
|
||
还款流水表:主键id,还款流水号,还款计划id,状态,还款方式(主动,代扣),还款金额,还款时间。 | ||
|
||
还款详情表:主键id,用户id,还款计划id,还款流水号,还款金额,实际还款金额,实际还款日期,期数,罚息,逾期天数。 | ||
|
||
2022-7-21 | ||
|
||
催收: | ||
|
||
1. 在还款日前1-3天,短信通知你还款。 | ||
|
||
|
||
定时任务 每天查询当前时间+2天 的还款日期 ,并且未还款的用户 短信通知这些用户,及时还款。 | ||
|
||
springboot 自带的定时任务 | ||
|
||
xx-job 分布式任务管理器 | ||
|
||
|
||
项目亮点; | ||
|
||
在支付的时候使用了就是策略模式 | ||
|
||
主要解决else if 过多的问题 | ||
|
||
\1. 因为定期存款业务很多,比如说零存整取, 整存整取,if else 逻辑很臃肿。为了项目更好维护和迭代。使用策略模式 + 工厂(通过反射) + 枚(mei)举 避免 if 过多。 | ||
|
||
**实现:** 1. 提供算法策略接口,接口里面提供一个每个分层的方法。 | ||
|
||
\2. 策略接口策略接口有很多不同实现类。比如有一级分 整存整取 | ||
|
||
\3. 定义工厂类,根据用户选择类型,获取存款策略类的实现对象。 | ||
|
||
\4. 策略类在启动的时候把创建的对象放到工厂类中map里面。(concurrentHashMap) | ||
|
||
\5. 根据存款方式去工厂类获取对象 |