信贷评分系统微服务架构面试任务：需求澄清与服务设计

一、需求澄清问题 #

1. 业务规则类 #

• 信贷评分的核心规则制定方是谁？是否支持后续动态调整规则（比如不同信贷产品线的评分权重差异）？
• 评分结果的等级划分标准是什么？（例如优秀/良好/一般/较差，对应不同的授信额度或申请通过率）
• 是否存在特殊用户群体的豁免规则？（比如银行优质客户、合作企业员工等）
• 申请被拒后，用户是否有申诉渠道？申诉流程如何与评分系统联动？

2. 数据源类 #

• 银行数据库可提供的用户信息具体包含哪些字段？（例如交易流水、存款余额、已有信贷记录等）是否需要对敏感数据做脱敏处理？
• 需对接的征信局有几家？不同征信局的接口协议、数据格式、调用频率限制是否一致？
• 用户申请表单的必填字段有哪些？是否支持补充上传佐证材料（比如收入证明）？这些材料是否需要纳入评分维度？

3. 用户交互类 #

• 申请提交后的结果通知时效要求是什么？（比如实时、T+1）是否支持多渠道通知优先级设置（比如短信优先，其次APP推送）？
• 用户是否可以查询历史申请记录及对应的评分详情？
• 表单填写过程中是否需要实时校验字段合法性（比如身份证格式、手机号有效性）？

4. 合规与安全类 #

• 是否需要满足金融行业的合规要求？（比如国内《个人信息保护法》、GDPR等）用户数据的存储、传输、使用有哪些强制规范？
• 征信数据的调用是否需要用户明确授权？授权记录如何留存备查？
• 评分结果的输出是否有防篡改要求？是否需要生成不可篡改的评分报告？

5. 性能与运维类 #

• 系统的峰值请求量预计是多少？是否需要支持水平扩展？
• 数据源调用失败时的降级策略是什么？（比如用历史数据临时替代，还是直接终止申请流程）
• 系统需要监控哪些核心指标？（比如申请处理成功率、评分计算耗时、通知送达率）

二、微服务设计方案 #

在你提出的4项基础服务之上，我们可以扩展出更完整的微服务体系，覆盖全流程的业务需求：

1. 申请管理服务 #

• 核心职责：负责用户申请全生命周期管理，包括表单提交、申请状态跟踪、历史申请记录存储与查询、申诉请求处理。
• 联动逻辑：接收用户提交的表单数据，触发数据校验服务，将合规的申请数据同步至数据源获取服务，最终同步评分结果并更新申请状态。

2. 数据校验服务 #

• 核心职责：对用户提交的表单数据进行合法性校验（格式、字段完整性），同时校验用户授权状态（确保征信查询已获得用户同意）。
• 联动逻辑：校验不通过则直接返回用户错误提示，校验通过则将数据传递至后续数据源获取服务。

3. 银行用户信息获取服务（原基础服务优化） #

• 核心职责：封装银行内部数据库的查询接口，对敏感数据进行脱敏处理，按照评分系统需求提取标准化的用户银行数据。
• 联动逻辑：接收申请管理服务的请求，返回处理后的用户银行数据至评分计算服务。

4. 征信信息聚合服务（原征信局信息获取服务扩展） #

• 核心职责：对接多家征信局的接口，统一数据格式，处理接口调用失败的重试、降级逻辑，聚合多源征信数据。
• 联动逻辑：将聚合后的标准化征信数据传递至评分计算服务。

5. 规则引擎服务 #

• 核心职责：存储并管理信贷评分规则，支持规则的动态配置与版本管理，根据输入的用户数据执行规则计算。
• 联动逻辑：接收评分计算服务的请求，输出各维度得分、扣分项等规则计算结果。

6. 评分计算服务（原基础服务优化） #

• 核心职责：整合银行用户数据、征信数据及规则引擎的计算结果，生成最终的信贷评分及等级。
• 联动逻辑：将最终评分结果同步至申请管理服务，并触发通知发送服务。

7. 多渠道通知服务（原通知发送服务扩展） #

• 核心职责：支持短信、APP推送、邮件等多渠道通知，根据配置的优先级选择通知渠道，跟踪通知送达状态。
• 联动逻辑：接收评分计算服务的通知请求，完成通知发送并反馈送达结果至申请管理服务。

8. 用户中心服务 #

• 核心职责：管理用户的基础信息、授权记录、申诉记录，提供用户身份验证功能。
• 联动逻辑：为申请管理服务、数据校验服务提供用户身份校验及授权信息查询支持。

9. 系统监控与日志服务 #

• 核心职责：监控各微服务的运行状态、请求耗时、错误率，收集并存储全链路日志，支持问题排查与审计。
• 联动逻辑：对接所有微服务，实时采集监控数据，生成运维报表。

内容的提问来源于stack exchange，提问作者Ivan