# 项目背景

为了更好地让读者理解服务架构，本书会带读者完成一个真实的系统，这个系统的选择会考察两个因素：

* 普遍性，尽量是ToC的，大家都有接触，以避免花太多篇幅介绍业务背景，当然培训机构用烂了的”XX商城“不在考虑之内
* 与笔者实际工作有关，这样才能在适合本书主旨的同时力求项目背景及核心需求的真实性

笔者服务过三家互金公司，从零开发过一套完整的车贷管理系统，对这块有一定的经验。 因而本书都会围绕“信贷管理系统“地建设展开。各位读者不妨将自己设定为此项目组的一员，在下文中带入自己的思考。由于篇幅有限，介绍上会突出重点，读者多为服务端开发，也为切合本书主旨，笔者会聚焦服务端并与微服务架构有关的内容。为更好阐述微服务架构，本书会此系统做一定裁剪及发散。

## 背景介绍

传统汽车金融贷款流程冗长，从消费者做出决策到最后提车，需要至少到店两次，耗时2-3天，这导致问题包含：

* 体验差：手续复杂耗时长，一次买车要签各种手续
* 成交率低：由于操作周期长，存在毁约风险，买车的成本虽然比较高，但它其实也是一个冲动消费，同一价位可选的车型众多、同一车型同城的经销商也不止一家，操作流程越长、等待时间越久，消费者越可能会“货比三家”
* 交易成本高：冗长的流程导致人工成本高启，一次交易需要涉及多个部门
* 受众有限：传统金融方案缺乏创新性，无法给顾客个性定制，建立在用户画像基础上提供差异化的金融方案更能吸引客户

基于以上几个痛点，某公司成立了一个新车信用贷款项目：车贷通（此名虚构，如有雷同纯属巧合），引入科技金融技术，以用户数据切入，形成个性化金融推荐方案，提供一套线上化、自助化的贷款全流程，实现顾客自助申请、机器审核为主人工为辅、自动放款、最慢1小时快速提车的极致用户体验。

## 业务流程描述

> ⚠ 由于真实项目业务过于复杂，为不占用太多篇幅，笔者对业务所需角色及流程做了一定简化。为避免歧义特此说明本书将金融专员角色合并到销售顾问角色中。

车贷通的业务模式是先与各4S店签署协议成为合作商家，4S店的销售顾问引导客户安装车贷通APP并完成个人信息填写，销售顾问选择客户想要购买的车型，车贷通会通过用户的信息及购买车型向顾客推荐购车金融方案，顾客选择一个方案并发起贷款申请，车贷通平台根据顾客信用向4S店支付贷款额。整个过程可控制在1个小时内完成。

整体流程可分为：贷款申请及贷后监控两大块，下图是贷款申请的精简流程：

![申请流程](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-apply-flow.png)

首先，顾客进店看车，销售顾问了解顾客意向后向其推荐车贷通APP，顾客下载车贷通-用户版并完成注册。首次使用时要求顾客先完善个人信息。

![](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-sketch1.png)

> 📖 用户的信用数据哪来的？ 信用贷款，尤其是车贷这种大额贷款授信时用户数据的完整性、准确性至关重要，以车贷通为例：
>
> * 通过身份证照片由第三方提供真实性校验，即这人是真实存在的
> * 通过活体比对（后文会有描述）确定人证合一，即确定是这个人申请的贷款
> * 通过银行卡、预留手机号完成四要素认证，进一步确认这个人的真实性
> * 通过身份证或手机号向央行、第三方公司（比如同盾、芝麻信用、聚信立等）购买征信报告
> * 从APP中采集必要的数据，这点很重要，比如：
> * * 车贷通启动时会上报GPS信息
> * * 注册/登录获取信息验证码（Android特有）时拿到短信读取权限，上传包含特定关键字的短信，比如信用卡、其它贷款平台的逾期催收短信
> * * 个人信息编辑身份证拍摄时获取文件访问权限，APP会扫描手机相册，采集照片的GPS信息（如果存在的话）
> *
>
> ```
> * 个人信息编辑紧急联系人选择时获取通讯录权限，上传特定号码，比如借贷黑名单、贷款公司电话
> ```
>
> ```
> 从APP中采集的数据比较敏感，从隐私保护上存在一定的争议，需要在协议中明确，只采集需要的数据，切实做好高级别的安全防护，确保只能用于当前的授信评分及贷后管理，所有数据只对模型可见，工作人员无法接触此类数据。 从长远看这种做法会越来越困难，一方面是人们对隐私保护的日渐重视，另一方面手机操作系统对权限的管控也越来越严格，每个新版本都在强化隐私安全保护，所以未来对用户的风险评定需要有新的思路，一些更合规的方案，这在互联网信贷行业尤其应该重视。
> ```

客户完成个人信息填写后，销售顾问在车贷通-门店版中发起贷款申请，包含车辆信息及贷款申请信息，正租/反租也称直租/回租，是两种租赁方式，对于车贷而言简单说正租车辆归贷款公司所有，用户需要交一定的保证金来租用车辆，反租车辆归用户个人所有，用户需要交首付款。

贷款申请通过“客户身份证”与顾客信息关联。由于要求查询用户信用，因此此处需要上传用户征信授权资料。

![](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-sketch2.png)

提交之后销售顾问可以在订单Tab中查看或操作自己所属的贷款订单。

接下来车贷通会根据销售顾问提交的申请、顾客填写的个人信息、APP采集的数据及三方征信报告匹配金融产品并给出授信结果。

通过风控审核完成后会通知顾客申请结果，顾客可以查看结果，如果对匹配的方案不满意可以选择系统给出的备选方案或完善信息后重新申请。

![](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-sketch3.png)

顾客确认方案后销售顾问操作生成贷款合同。

![](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-sketch4.png)

合同生成调用的是第三方电子签名服务，确保有法律效力，合同生成后顾客需要完成活体检测，通过后车贷通后台进行放款人工审核以最后确认申请是否通过。

由于转账会有时间滞后且银行非工作日的公对公转账有单笔金额限制，为缩减流程周期，车贷通以平台信用担保，放款确认后向销售顾问发送放款凭证，销售顾问收到此凭证即可视为贷款已到4S并可开始走提车流程。

顾客提车后申请流程完成，最后销售顾问需要通过APP上传必要的资料，一些核心资料要邮寄到车贷通，比如贷款合同、保单、购车发票、购置税发票、保险发票、机动车登记证书等。

贷后监控相对而言逻辑比较简单，如下图：

![](https://raw.githubusercontent.com/gudaoxuri/Microservices-Architecture/master/resources/images/project-post-loan-flow.png)

车贷通系统定时触发贷后巡检，巡检会根据顾客APP更新的数据（如果没有卸载的话）、还款记录、车辆GPS数据、三方征信报告更新数据等判断是否存在风险，进而做简单的短信/电话提醒或是交由三方公司做委外催收，用户的还款及系统的定时触发器会触发更新还款计划中的逾期罚息金额。

以上就是车贷通业务的简化描述，接下来我们来实现第一版本。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gudaoxuri.gitbook.io/microservices-architecture/xiang-mu-jie-shao/background.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.