智慧信贷

• 1: 业务架构
  • 1.1: 业务架构总览
  • 1.2: 授信模式
  • 1.3: 架构图集
    • 1.3.1: 业务架构总览图
    • 1.3.2: 授信模式体系
    • 1.3.3: 额度体系
    • 1.3.4: 客户管理体系
    • 1.3.5: 押品管理体系
    • 1.3.6: 产品管理体系
  • 1.4: 额度体系
  • 1.5: 客户管理体系
  • 1.6: 押品管理体系
  • 1.7: 产品管理体系
• 2: 应用架构
  • 2.1: 应用架构设计
• 3: 技术架构
  • 3.1: 技术架构设计
• 4: 集成架构
• 5: 部署架构
  • 5.1: 部署架构设计
• 6: 非功能需求

1 - 业务架构

智慧信贷项目的业务架构文档，覆盖业务建模、领域划分与五大体系设计。

• 业务架构总览：三类领域、11 领域 40 组件 68 能力 33 对象的架构基线
• 授信模式：五类授信模式的组织方式、授用信关系与额度管控差异
• 额度体系：额度分类组织、双维度管控、生命周期及双占多占机制
• 客户管理体系：统一客户主体、关系网络、管户责任与统一视图
• 押品管理体系：押品五层结构与从准入到解押退出的连续管理
• 产品管理体系：五级产品目录、组件化配置与四维状态运营管控
• 架构图集：五大体系的交互式架构图

1.1 - 业务架构总览

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》提炼。智慧信贷二期业务架构基线形成 11 个业务领域、40 个业务组件、68 项核心业务能力和 33 项核心业务对象，对公信贷和个人信贷作为两类主要端到端业务场景，专项业务和关联专业能力通过明确协作关系与核心业务架构衔接。

总体结构：三类领域

专业对象管理领域负责客户、产品、担保与押品、额度等跨阶段核心对象的持续管理；公共管理横向提供政策计划、外部信息、影像档案、知识、作业协同、台账报表和费用等公共服务。对公信贷和个人信贷不作为独立业务领域，而是分别形成端到端业务场景，贯穿六个生命周期领域，并在业务过程中调用专业对象、公共管理及关联专业能力。

11 领域与 40 组件

一个业务组件只具有一个主要业务领域归属，跨领域依赖通过业务协作表达，不复制相同责任：

组件是否独立成立取决于稳定责任、对象或事项、规则及生命周期边界，不取决于组织、系统或总览图展示颗粒度。

68 项核心业务能力

业务能力表达"银行持续需要会做什么"，全部唯一归属一个主责业务组件。代表性归属：授信额度管理承载额度结构、生命周期、统一视图、调账四项能力；限额管理承载集中度与国别限额；尽职调查作业管理承载现场/非现场调查、尽调资料、尽调报告；放款管理承载放款申请、贷款发放、受托支付。总览图或流程图中的多个步骤可归属于同一组件下的不同能力；同一场景中被调用的能力不因发生位置变化而改变主责组件。

33 项核心业务对象与端到端对象链

核心业务对象按稳定身份、主要信息、业务规则和生命周期确定唯一主责组件。并非每个组件都拥有独立核心对象——部分组件围绕业务事项或公共服务承担责任，其对象作为其他主对象的状态、属性或过程信息存在。主要对象：客户、客户群组、供应链、客户关联关系、目标客户清单、同业准入名单、产品、产品条件、担保协议、抵质押品目录、抵质押品、押品资产池、价值评估、权证、押品分配关系、授信额度、限额方案、营销方案、信贷调查资料、授信/贷款申请、授信方案、授信批复、贷款协议、放款协议、放款执行证据、还款计划、信贷经营政策与计划、客户征信授权、外部信用信息、征信业务关联、信贷费用。

对象关系描述端到端信贷业务的形成过程，但不改变唯一主责：

客户提出授信/贷款申请 → 尽调资料支撑授信方案形成 → 方案经审查决策形成授信批复 → 额度管理依据批复建立/调整授信额度 → 需要缓释时通过担保协议和押品分配关系建立价值使用关系 → 批复条件在签约阶段落实为贷款协议 → 满足用信条件后形成放款协议和放款执行证据 → 进入还款计划和后续履约管理

客户、产品、授信额度、抵质押品等专业对象在上述各阶段被持续复用，被其他领域使用不改变其主责组件。

端到端场景与协作

对公与个人信贷均贯穿业务准备、尽职调查、授信申请、审查审批、签约放款、贷后管理六个生命周期领域，差异体现在各阶段的活动组合上：业务准备阶段对公以线下受理与主动授信为主、个人以渠道进件为主；尽职调查阶段客户准入和尽调作业为本阶段主责，征信、评级等结果作为协作输入。场景在稳定责任结构之上组合组件和能力，表达实际端到端业务如何运行。

关联专业能力与系统边界

客户评级、风控引擎、资产保全、风险驾驶舱等关联专业能力由行内其他系统承接，通过明确协作关系与核心业务架构衔接（如尽调阶段引用评级结果、审查审批调用风控引擎、贷后与资产保全衔接）。贷后管理领域保留在业务架构基线内；上述范围决策属于系统实施边界，不改变业务架构的责任结构。

全景可视化见业务架构总览图；五大体系的详细设计见授信模式、额度体系、客户管理体系、押品管理体系、产品管理体系。

1.2 - 授信模式

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第六部分。授信模式表达不同客户类型和业务场景下，授信申请、方案形成、审查审批、批复、额度建立以及后续用信之间如何组合运行，不改变已确定的业务领域、业务组件及其主责关系。

总体结构

各类授信模式共享统一的信贷生命周期责任，按需调用客户、产品、额度、押品、公共管理及关联专业能力。模式之间的差异集中在四个维度：

• 以什么对象组织一次授信（客户 / 集团 / 单笔业务 / SPV）；
• 授信时形成到什么业务层级（授信方案 / 业务方案 / 单笔批复）；
• 授信与具体用信在何时衔接（授用信合一 / 授用信分离）；
• 需要接受哪些上层或关联额度约束（客户总量 / 集团总量 / 分组 / 预留额度）。

单一对公客户统一授信

以客户作为统一授信组织单元。一次授信可同时形成综合授信额度、专项授信额度和非授信额度中的一种或多种授信安排，在同一客户维度形成统一的授信方案和额度视图，改变按单一产品逐笔割裂管理的方式。

核心机制：

• 授信方案与业务方案分层：授信方案确定客户整体授信结构（类型、层级、金额、期限、条件）；需要提前明确具体业务的分项，在最末级额度下维护业务方案（项目、产品使用方式、担保安排等）。一个最末级额度可对应多个业务方案。
• 授用信合一：授信阶段能明确用信的场景，同时形成额度安排和业务方案；仅核定额度的业务，具体信息留待合同或用信环节落实。
• 单笔单批为补充：贴现、委托贷款等特定业务可单笔单批作业，但不形成独立于统一授信之外的客户额度体系——单笔信用安排仍进入客户统一额度视图，接受客户总额度等管控。

集团客户统一授信

以客户关系管理中维护的集团成员关系为基础，将集团整体风险识别、成员授信需求、集团总额度和成员额度使用纳入统一管理。集团可包含对公、同业及符合管理要求的个人客户，成员保留自身授信模式，在集团层接受统一约束。

组织方式：集团主办责任统一组织，成员形成各自的授信方案，主办、协办协同汇总为集团整体授信申请，形成"集团整体信用判断 → 集团总额度及管控结构 → 成员授信方案 → 成员具体业务办理"的分层模式。

管控机制：集团成员可按成员、经营机构或业务板块分组，分组额度限制特定成员集合对集团信用资源的使用；预留额度为新增成员或新增融资需求保留可调配空间。集团额度不足时通过集团授信变更、续作或预留额度领用调整，不允许绕开集团管控单独扩大成员授信。

同业客户授信

同一金融机构相关授信业务纳入统一客户信用管理，但与对公不同，采用授用信分离模式：授信阶段形成客户授信方案和额度安排，票据、贸易融资、金融市场等具体业务在后续专业交易场景中根据有效额度办理。

同业授信额度按专项业务和风险等级组织，适配不同专业业务的风险特征；授信审批确定客户信用风险边界，额度管理持续维护风险资源，交易场景按额度映射和风险等级规则调用。模式概括为：统一客户授信 + 专项风险额度 + 专业业务用信。

个人信贷作业模式

继续以单笔业务授信为主要作业模式：围绕具体融资申请开展准入、调查、申请、审查、审批、批复、合同签订和放款，每笔业务形成业务批复和单笔业务额度。个人不存在对公式的客户维度统一授信方案；预授信、线上转人工、模型审批属于获客和审批路径变化，不改变单笔授信的基本单元。

客户层仍形成统一额度和风险视图：单笔批复额度按客户汇总，结合个人客户总限额、信用限额和保证限额等风险边界控制新增业务，实现"业务逐笔审批、客户统一看险"。依赖合作项目、合作方或集群的业务，同时受项目额度、合作方额度或集群额度约束；个人经营贷涉及集团客户时纳入集团统一授信管控，形成"个人单笔业务额度 + 项目/合作方/集群额度 + 集团额度"的多层约束。

SPV 及专项授信

对 SPV 等特殊目的载体或特定投资对象，以具体 SPV 或投资对象为独立管理单元核定投资或业务额度。授信过程除识别 SPV 本身及底层资产外，还识别担保人、差额补足人、管理方、增信方等相关主体，并在后续投资或用信时关联其信用资源。SPV 授信仍经过申请、审查审批和批复等通用责任，但额度对象和用信方式按专项业务特点组织，不并入普通对公客户统一授信结构。

与核心业务架构的关系

授信模式是稳定业务架构在不同业务场景中的组合表达：不同模式不重新划分业务责任，而是在统一业务架构上，根据客户类型、授信组织方式和额度管理要求形成不同的端到端业务组合。

1.3 - 架构图集

本栏目收录《智慧信贷项目业务架构说明书》的交互式架构图，由 archify 生成。图内支持缩放拖拽、语义视图切换、关系追踪与 PNG/SVG 导出。

• 业务架构总览图：三类领域与生命周期主干的全景
• 授信模式体系：五类授信模式与统一责任链的映射
• 额度体系：授信金额与敞口双维度的额度树与占用控制
• 客户管理体系：统一视图与专业责任划分
• 押品管理体系：押品全生命周期五层结构
• 产品管理体系：五级产品目录与状态运营机制

需要在一个页面内对照浏览全部图集时，可打开 图集总览入口。

1.3.1 - 业务架构总览图

依据《智慧信贷项目业务架构说明书》第四部分绘制的业务架构全景：专业对象管理、信贷生命周期、横向公共管理三类领域共同构成智慧信贷业务架构，对公与个人信贷作为端到端场景贯穿六个生命周期阶段。

全屏打开 ↗

1.3.2 - 授信模式体系

授信模式体系回答"同一套责任链如何承载不同风险特征的业务"：五种授信模式在申请受理、方案设计、批复、额度管控与用信放款各环节各有差异，前端模式差异化、底层链路统一，最终落到最末级额度与业务方案的共用机制上。

全屏打开 ↗

1.3.3 - 额度体系

额度体系以授信金额与敞口双维度管控为核心：额度树向下延伸到最末级额度并挂接业务方案，向上承接集团客户总量、分组与预留额度管理，用信环节实施额度双占多占控制，对公授用信合一、同业授用信分离。

全屏打开 ↗

1.3.4 - 客户管理体系

客户管理体系以客户统一视图为核心：面向客户的身份、关联、评级、押品等信息集中展示，而各专业条线的管理责任分别落实，形成"集中展示、分别管理"的协同结构。

全屏打开 ↗

1.3.5 - 押品管理体系

押品管理体系按五层结构组织：准入规则、押品主体、价值与缓释、权利落实、持续监控。核心缓释公式为"有效担保价值 = 认定价值 × 适用抵质押率"，抵质押率按产品差异化取用。

全屏打开 ↗

1.3.6 - 产品管理体系

产品管理体系维护产品线→产品组→基础产品→可售产品→组合产品的五级目录，实行四维状态管理与停用/暂停/停牌三档运营机制，不良率超限时自动触发停牌。

全屏打开 ↗

1.4 - 额度体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第七部分。额度是授信决策向业务执行传递信用风险边界和业务资源约束的核心业务对象——授信审批回答"是否给予信用、给予什么条件"，额度管理则将批复结果转化为可持续查询、校验、占用、释放和调整的业务资源。

额度体系承担五项业务作用：将授信批复结构化为可持续管理的额度；在客户、集团、产品、项目及风险承担主体之间建立统一额度关系；为合同、放款及专业交易提供可用额度校验和占用依据；支持额度全生命周期管理；通过限额、分组和双占/多占机制将单笔业务风险纳入客户和组合层约束。

额度分类与对象结构

额度体系从"授信主体"和"风险管控对象"两个层次组织：

• 主体类额度：围绕具有独立客户身份并承担信用风险的主体形成，包括集团客户额度、对公客户额度、同业客户额度、个人客户额度，持续反映银行对某一客户或客户集团承担的总体信用风险。
• 专项主体及场景类额度：SPV 额度（独立风险承担特征的专项主体）、集群额度、项目/合作方等场景类额度，可与客户主体额度形成双占或多占关系。

各类额度均属授信额度对象体系下的业务子型或场景化安排，不因客户类型、业务场景或额度层级差异而新增独立核心业务对象。

额度层级遵循"上层汇总管控、下层承载具体业务"：上层形成客户或集团总体风险视图和总量控制，中间层区分综合授信、专项授信、非授信、业务专项、风险等级等信用用途，最末级额度直接对应具体产品、业务方案、项目或可实际占用的风险资源。层级表达风险资源的归集约束关系，不代表每层都需独立审批。

对公客户额度体系

以法人客户为统一管理主体，形成法人客户总额度，区分母行额度与并表机构额度（后者反映集团内相关机构对同一客户形成的信用资源，形成全口径授信视图）。

母行额度按业务性质划分三类：

• 综合授信额度：基于客户综合偿债能力的经营周转类信用安排，分项之间允许共享统筹，上层承担总量控制，业务落到最末级额度使用；
• 专项授信额度：用途专用、项目收益特征明显的信用安排，专项之间原则上独立；
• 非授信额度：委托贷款、合作方非授信、供应链非授信等管理性额度，部分通过审批形成，部分由实际业务反向汇总形成。

对公额度实行授信金额与敞口双维度管理：授信金额反映允许使用的业务规模，敞口金额反映实际承担的信用风险（因担保方式、保证金、第三方风险承担而差异），可用空间、占用、释放与集团汇总均需同时考虑两个维度。实际使用以最末级额度为承载单元，多个独立项目或业务安排通过业务方案区分。

同业客户额度体系

以金融机构客户为统一管理主体，由同业客户总额度、母行额度和并表机构额度形成统一风险视图。母行额度按票据、贸易融资、金融市场等专业业务形成专项额度，专项额度下按风险等级组织信用资源，产品根据风险等级及额度映射规则使用额度。模式概括为：客户统一授信、专项分类管理、风险等级控制、专业业务用信。

个人客户额度体系

不采用对公式客户统一授信方案，额度以单笔业务批复为基础形成；客户层汇总各笔有效业务额度形成总体信用视图（项目范围外的其他个人业务额度可作为全口径汇总信息进入视图）。客户层风险限额包括个人客户总限额、信用限额和保证限额，构成风险上界约束。个人经营贷及场景型业务可同时受集团、合作方、集群或项目额度约束。

集团客户额度体系

以集团客户为最高统一风险管理单元，形成集团总额度，汇集成员的对公、同业及适用的个人经营类信用资源。三层机制：

• 集团总量与成员额度：集团额度控制整体信用风险上限，成员额度反映自身授信安排，成员业务同时受两层约束——统一识别集团风险而不取消成员自身管理；
• 分组额度：按成员集合、经营机构或业务板块分组并设置授信金额与敞口控制，属于集团内部限额，不替代成员授信；
• 预留额度：为新增成员或新增融资需求预留信用空间，在集团风险边界无实质变化时可领用分配，减少频繁发起整体授信调整；领用和恢复在集团额度体系中持续记录。

额度生命周期管理

额度是具有持续生命周期的业务对象：额度形成 → 生效/启用 → 查询与校验 → 占用 → 调整/冻结 → 释放/恢复 → 到期/失效/结清。

• 形成：授信审批形成（依据批复建立/调整）或业务反向汇总形成（依据已发生业务事实形成管理额度并向上汇总），两类均进入统一额度视图；
• 生效与启用：“额度已批复"与"额度可实际使用"是不同状态，需落实放款前条件的额度须完成启用；
• 占用与释放：合同、放款或交易对最末级额度占用；上层额度不重复记录每笔占用，而是根据下层占用形成汇总视图；还款、结清后按是否循环及业务规则释放或恢复；
• 变更、续作与调整：承接新授信结果的同时保留存量业务关系，确保能解释已发生业务、剩余可用空间和后续约束；
• 冻结与解冻：重大风险事件、条件未落实或风险预警触发时冻结，不改变已形成的授信事实但限制新业务使用；
• 到期、失效与结清：失效后不允许新增使用，已发生业务按合同和贷后要求继续管理。

双占与多占管理

单笔业务可能同时占用多个对象或层级的额度：集团成员业务同时受成员额度和集团额度约束；供应链/合作方/集群业务同时占用融资客户自身额度和关联主体/项目额度；票据、贸易融资业务同时涉及交易客户和承兑人、开证行、担保人额度；SPV 业务同时占用 SPV 额度和担保人、差额补足人、增信方额度。

额度管理不仅记录"占用了多少”，还要记录"占用了哪个主体、哪一类额度以及占用关系为何成立"。双占多占将单笔业务风险传导到所有实际承担风险或负有管理责任的对象，是统一授信和穿透风险管理的重要机制；它属于额度对象体系内部的业务关系，不新增独立核心业务对象。

与限额管理的分工

授信额度解决具体客户、集团、SPV 及业务场景可用多少信用资源；限额管理从监管、组合和集中度视角设置上层边界，重点包括集中度、国别、关联方、行业、机构、产品等限额。单一客户或集团的信用资源上限原则上通过授信额度体系及授信政策管理，限额不重复形成主责。不同限额可在申请、合同、放款或交易阶段参与校验，形成强制控制或风险提示。

1.5 - 客户管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第八部分。客户管理为信贷经营、授信、额度、担保、贷后及专业风险管理提供统一客户基础，核心是持续识别"客户是谁、客户之间是什么关系、由谁负责、在什么业务场景中以什么身份参与"，并在信息和关系变化时保持业务责任与上下游连续。

总体结构

客户管理按四个层次组织：

各层共同以客户为基础主体：客户参加集团、集群、供应链或具体合作业务时，基础身份保持稳定，通过群组、关系、标签或业务角色表达场景差异。

客户主体体系

• 统一客户主体：覆盖个人、对公、同业客户及 SPV 等特殊目的主体。不同类型有不同的信息结构、准入规则和处理方式，但均以可持续识别的身份参与后续业务，避免不同场景重新形成割裂的客户身份。
• 客户群组：集团、集群及其他基于营销、统一授信或风险管理形成的稳定客户集合。群组拥有独立身份和成员关系，成员客户继续保持自身独立身份——群组解决"哪些客户作为整体识别管理、各客户在其中是什么成员关系"。
• 客户业务角色：同一客户在不同业务中承担不同角色（借款人、担保人、合作方、核心企业、上下游企业、个人用款企业、集团成员、SPV 增信主体等），角色描述特定业务关系中的身份，不改变基础客户主体。
• 跨法人协同：对金租、理财子等机构已建立的客户，形成跨法人客户协同视图并与行内身份建立识别关系，支撑集团并表和统一风险识别。

客户信息统一管理

客户建档过程：客户识别 → 重复性检查 → 身份核验 → 客户创建/引入 → 信息完善 → 持续维护。已存在的客户直接引用现有身份；外部或行内系统已有客户在身份匹配后引入。统一识别的目标是同一客户在不同信贷场景下持续、准确识别，而非按业务品种、渠道或办理阶段重建客户记录。

信息体系为"统一客户身份 + 客户类型差异化信息"：个人客户维护身份证件、税收居民、联系、工作教育、关联人及企业、资产负债等；对公客户维护证照、经营规模、财务、企业关联、实际控制人/高管/股东/对外投资等；同业及专项客户按业务特性保留专业属性。

重要客户信息保留变更前后内容、来源和时间，保证持续可追溯；信息变化来源于人员维护、行内系统同步、外部数据更新和经营状态变化。

客户关系与群组管理

• 关联关系：股权投资、实际控制、任职、家庭亲属、担保、上下游经营等具有持续业务含义的关系，进一步形成客户关系网络，支撑集团识别、公私联动、关联授信和风险穿透。
• 集团客户管理：以已识别的客户关系为基础，将存在控制或集团关联的客户组织为统一群组，过程为"集团识别与认定 → 集团成员建立 → 信息维护 → 关系排查 → 成员调整 → 变更和持续监测"。集团形成时明确整体身份、核心成员、成员范围、成员关系和管理责任；成员可新增、退出、调整或集团合并，变化同步传递给集团授信和额度体系。客户管理确认集团及成员关系，授信和额度管理基于已确认的集团关系开展统一授信和信用资源管控。
• 集群客户管理：管理因共同经营特征、客户来源、营销方式或风险方式形成的客户集合，维护集群身份、类型、成员、主办责任和业务属性，服务于批量营销、批量授信、产业商圈经营和场景化风险控制；成员按自身身份办理业务，同时接受集群授信或额度约束。
• 供应链关系管理：围绕核心企业及上下游形成业务关系网络，除"哪些客户属于一个集合"外，还表达成员之间的上下游关系和供应链位置，支撑供应链客群营销、批量授信和相关额度管理。

管户责任与权限

客户权限分三层：

1. 客户主办/管户责任——明确谁对该客户承担主要经营和持续管理责任，同一客户原则上形成明确的主办或管户责任；
2. 客户信息使用权限——信息维护权和查看权，控制非主办人员在授权范围内维护或查看客户信息；
3. 特定业务办理权限——如对公客户的低风险业务权，支持非主办客户经理在授权范围内办理相应业务。

权限本身具有申请、审批、生效、调整和失效的持续管理过程。个人客户主要包括主办、维护和查看权限，对公客户进一步包含低风险业务权。

客户及业务移交

经营责任变化时通过移交管理保持连续，形成三种移交：客户责任移交（调整管户责任及权限）、客户项下业务移交（经营责任不变，仅调整特定授信、合同或存量业务的主办责任）、客户及业务整体移交。整体移交需识别客户项下的在途申请、批复、合同放款、押品及担保关系、贷后事项等存量业务。

管控原则：主办责任清晰、在途业务状态可识别、原责任与新责任连续衔接、客户和业务调整结果一致、移交结果和历史过程可追溯。

分类、标签与名单

• 客户分类与标签：经营分类、企业规模、行业属性、战略客户/科技企业等经营标签、监管类和专项业务标签，作为持续业务属性参与经营和风险判断，不改变客户主体身份。
• 企业划型：具有明确监管规则的重要机制，过程为"获取划型基础信息 → 按规则计算企业规模 → 业务确认/审批 → 形成有效划型结果 → 定期或变化时重新认定"，规模分为大型、中型、小型、微型、个体工商户等，结果在授信申请等业务中作为分类基础。
• 名单管理：按营销、准入、预授信和风险管理目的形成特定客户集合，生命周期为"名单类型定义 → 客户纳入 → 审核/确认 → 生效使用 → 状态调整 → 失效/退出 → 历史留痕"。名单是客户集合的表达，客户加入或退出不改变基础身份。

客户统一视图

以客户为统一索引，关联展示三类信息：客户自身信息（基础、分类标签、关系群组归属、历史变化）、信贷业务信息（授信申请与方案、批复、额度及使用、合同放款、还款存续）、风险及专业信息（评级、风险分类、预警、担保关系、押品和缓释、外部信用）。

统一视图采用**“客户集中展示、专业责任分别管理”**：额度、押品、评级、预警等业务结果在视图中被统一引用，专业主责继续由相应业务领域承担。

客户生命周期

客户识别 → 建立/引入 → 信息完善 → 分类与关系建立 → 经营及授信使用 → 信息与关系调整 → 管户及业务责任变更 → 持续监测与历史留痕。生命周期中持续管理三类变化：客户自身变化（信息、经营、分类标签）、客户关系变化（集团成员、股权控制、供应链、集群成员）、经营责任变化（主办责任、权限、移交）。

客户管理作为跨生命周期的专业对象管理领域，与业务准备、尽职调查、授信申请、审查审批、额度管理、押品管理、签约放款、贷后管理、评级及公共管理等领域的协作，将各业务阶段统一连接到稳定客户身份、关系和经营责任基础上。

1.6 - 押品管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第九部分。押品管理围绕信贷业务中的抵质押风险缓释资产持续管理，贯穿授信前、授信审批、签约放款和贷后全过程，核心是持续回答"哪些资产可以作为押品、当前价值多少、能提供多少风险缓释、与哪些业务形成担保关系、权利是否落实、存续期风险是否变化、何时解除退出"。

范围说明：本体系重点展开抵质押品及其缓释使用；保证等非押品型担保安排及担保协议的形成、变更、终止，由担保管理责任统一承接。

总体结构：五层组织

各层以具体押品为核心对象：押品在不同授信、合同或债项中被引用形成不同担保使用关系，但自身身份、基础信息、价值记录和权证记录保持统一管理。

押品目录与管理规则

统一押品目录定义银行可接受的抵质押资产类型，形成分类层级和业务含义，承担统一分类口径、明确担保方式、建立信息模板、为估值/权证/缓释分配/风险监控提供分类依据、支撑新增类型维护等作用。目录描述"可接受什么类型"，具体资产进入押品信息管理。

不同押品类型在目录下参数化管理：是否唯一性识别及识别要素、适用抵押或质押方式、最高抵质押率、估值方式和模型、重估频率及批量重估方式、权证类型及是否入库、是否保险、缓释合格认定参数等。

产品差异化抵质押率：押品管理维护类型层面的统一最高抵质押率及通用风险参数；产品管理可按具体产品和业务场景配置差异化抵质押率。业务使用押品时优先适用有效产品配置，未配置时适用类型统一标准。由此形成"押品类型统一规则 + 产品差异化风险条件 → 押品实际担保能力"。

押品信息与统一识别

押品建立过程：押品类型选择 → 唯一性识别 → 押品建立/引用 → 信息完善 → 价值评估 → 业务使用 → 持续维护。

• 唯一性识别：需要唯一识别的押品类型由目录预配核心识别要素（如房地产按房屋所有权证号、交易合同号、不动产单元号），创建时在已有押品范围内校验——无重复则新建，有则优先引用；批量导入和外围系统推送同样执行。目标是一项真实押品对应一个可持续识别的押品身份，多笔业务共享同一押品对象。
• 信息结构：“统一基础信息 + 类型差异化专项信息”。基础信息含编号、类型、担保方式、权属人及共有人、占有租赁顺位、实物与权利状态、来源系统、管户及机构、保险等；房地产类进一步管理产权、地址、登记、查封异动等，金融质押品按存单、保证金、票据、理财等维护账户和权利信息。
• 多来源协同：交易银行、票据等外围系统形成的押品统一纳入身份和唯一性识别规则并保留来源；金融质押品资产池已提出方向，池化结构待后续细化。
• 管户与留痕：押品建立即形成管户责任，随业务关系变化（重新引用、客户移交）调整；重要信息修改保留内容、原因及历史记录。

押品价值管理

• 估值方式：内部评估、线上外部评估、线下外部评估、直接评估（存单、保证金、部分票据及本行理财可基于账户或产品实时/定期价值直接评估），适用方式由类型规则确定。
• 初始估值与持续重估：初始估值形成首次业务使用前的我行认定价值；重估按类型频率、业务需要或风险变化开展，方式包括单笔人工、人工批量、系统定期批量，形成"首次价值认定 + 周期性重估 + 风险触发重估"。
• 我行认定价值：各类估值结果最终形成我行认定价值作为业务使用基础，具有认定日期、评估有效期、价值状态和历史评估记录，新认定形成后原价值转为历史。
• 可担保能力：押品有效担保价值 = 我行认定价值 × 适用最高抵质押率（抵质押率优先取产品差异化配置）；已存在业务占用时扣除已占用价值，形成剩余可担保空间。
• 价值变化管控：重估价值与存量业务认定价值偏离超过阈值时预警并通知管户或风险人员，评估是否调整担保可用空间；价值变化由押品管理识别，后续动作由相应领域承接。

担保关系与风险缓释使用

基本关系链：客户/债务人 → 授信或业务合同 → 担保合同 → 押品。押品与债项可形成一对一、一对多、多对一或多对多关系；担保合同生效后保留押品与担保合同、主合同及借据的有效关系，结清或解除后转为失效。

• 押品引用：优先从已有押品引用，条件为身份有效、存在有效认定价值、仍有可使用担保价值、无影响有效性的限制状态、满足来源系统使用规则；未建押品的资产可在业务办理中创建后补全信息、估值和权利落实。
• 缓释价值分配：统一分配机制支持两个视角——以业务为基准（识别每笔业务的担保覆盖程度和足值情况）、以押品为基准（识别每项押品已承担的担保负荷和实际抵质押率），形成"押品价值 → 担保关系 → 债项分配 → 风险缓释结果"。
• 占用与释放：生效的主要担保关系参与价值占用；一般担保按关联业务状态判断释放；最高额担保按综合授信层或业务方案层的担保范围判断是否全部满足解除条件；辅助担保单独标识，不参与常规占用分配。

权证与抵质押登记管理

权证分实物、电子式、虚拟权证，是否入库由类型规则确定，与押品、权属人、担保合同建立关联并形成独立状态和出入库历史。

• 权证生命周期：权证建立/获取 → 抵质押登记 → 入库保管 → 在库管理 → 临时借出/换证 → 归还入库 → 正式出库，状态包括未入库、入库中、在库、借出、出库中、出库。
• 入库核验：权证与押品及担保关系匹配、无重复入库记录、需登记的已形成他项权证、保险等前置条件满足、无查封冻结状态。
• 出库、借阅与置换：正式结清出库需确认担保关系解除且业务结清；临时借出用于诉讼、审计、信息变更等，归还入库并留痕；支持预转现等权证置换。
• 线上抵质押登记：对已接入不动产登记能力的房地产押品，衔接"登记前权利及限制核查 → 行内申请与审批 → 客户/银行签章 → 外部登记申请 → 进度跟踪 → 取得登记结果 → 权证建立及入库"，支持一般/最高额抵押、预告登记、变更、注销、预转现等场景；不同地区渠道不同但在押品管理中统一归入权利登记和权证管理。
• 跨机构移交：权证保管机构变化时通过出库和重新入库完成保管责任迁移。

持续监控与风险管理

• 状态监控：实物状态、查封冻结扣押、权属和顺位变化、保险、登记状态、权证保管、关联业务及担保状态；房地产通过不动产登记渠道定期获取限制状态，金融质押品通过核心或专业系统更新账户资产状态。
• 价值波动监控：最新认定价值与存量业务原认定价值显著变化时按阈值形成风险信号，传递至风险预警专业能力统一处理。
• 集中度分析：按押品类型和机构等维度统计数量分布、价值分布、对应债项余额及占比变化，识别结构过度集中。
• 压力测试：按类型、分支机构或指定范围选取押品，设置单一或组合压力情景，关注担保足值率变化、抵质押未覆盖金额与覆盖率，为风险管理措施提供依据。

押品生命周期与处置协作

全生命周期：押品准入 → 身份建立 → 信息完善 → 初始估值 → 业务引用与担保建立 → 权利登记与权证落实 → 存续期监控与重估 → 缓释价值调整 → 解押/处置 → 退出或再次使用。解押后资产本身仍有效的，保留统一押品身份供后续业务再次引用。

进入风险资产处置阶段时，资产保全负责专业处置（拍卖、司法处置、变卖、抵债等），押品管理负责持续记录和维护处置后的押品状态及关系，接收处置结果更新状态和台账，为权证出库、担保解除和退出提供依据。

与其他领域的协同

押品管理作为跨生命周期的专业对象管理领域，与客户管理（权属人/担保人身份、移交时协同调整管户）、产品管理（差异化抵质押率及使用条件）、尽职调查、授信申请（担保安排与担保能力判断）、审查审批（覆盖情况信用判断）、合同签约（建立担保合同关系）、放款管理（放款前核验担保条件落实）、额度管理（押品影响可用信用资源但额度对象仍由额度管理负责）、贷后管理、风险预警、资产保全、公共管理及外部登记平台协作，形成贯穿授信前、授信执行和贷后存续期的抵质押风险缓释管理基础。

1.7 - 产品管理体系

下载矢量版 SVG

依据《智慧信贷项目业务架构说明书》第十部分。产品管理为信贷业务提供统一、稳定且可持续演进的产品基础，核心是持续回答"银行有哪些信贷产品、产品之间是什么层级关系、适用于哪些客户和业务场景、具体业务条件如何配置、产品如何发布和变更、什么时候允许继续开展业务、运营效果如何反馈到后续管理"。

两个术语区分：产品组件是产品配置中由若干产品要素形成的配置单元，与业务架构中表达稳定业务责任的"业务组件"不是同一概念；产品场景是产品差异化配置维度（主要用于个人信贷场景金融），与描述对公、个人及专项业务运行方式的"业务场景"不在同一层次。

总体结构：五层组织

各层围绕"产品"核心对象展开：产品条件承载准入、适用、定价及其他业务规则；组件、场景、流程、页面、模板等用于组织和应用这些条件，不改变产品的统一身份。

产品目录体系

统一产品目录组织信贷产品及其分类层级，目标是同一信贷产品具有稳定、唯一的产品身份，分类和层级变化通过统一目录管理，不因系统、渠道或业务阶段重新定义产品。

五级结构形成"基础产品沉淀共性 → 可售产品形成实际业务产品 → 组合产品组织多个可售产品形成综合服务方案"：

• 产品线：按稳定业务类别高阶归类（信贷、贸易融资等）；
• 产品组：按客户性质或业务特征细分（对公贷款、个人贷款等）；两级主要承担目录组织作用，不承载具体办理条件；
• 基础产品：沉淀相似服务功能和处理规则的产品模板，预置共性组件和要素、形成可复制条件基线，支撑可售产品快速建立，不直接面向客户销售；
• 可售产品：实际用于客户营销、申请和办理的形态，在基础产品共性规则上按客户细分、适用机构、区域、产品政策、场景、风险控制要求差异化配置；业务办理以当前有效的可售产品及其配置为规则输入；
• 组合产品：将多个可售产品组织为一揽子组合，管理组合身份、组成关系和有效状态，不改变被组合产品自身的身份和条件。

产品条件、要素与组件化

• 产品条件：描述产品适用于什么客户、遵循什么规则、如何形成交易条件，覆盖客户准入和适用、用途投向、金额期限、利率定价、费用、还款方式、担保及抵质押要求、业务控制项等，是"产品"与"产品条件"两个核心对象间的主要关系。
• 产品要素：结构化描述产品条件的基础单元，通过要素名称、类型、可选码值、数值范围、默认值、控制方式表达一项业务属性或控制规则，可被不同产品复用。
• 产品组件：归集具有紧密业务联系的一组产品要素，按业务使用阶段分为授信、合同、放款、贷后及通用组件，可被多产品复用，形成"产品要素 → 产品组件 → 产品配置"的配置链。
• 继承与差异化：产品新增可全新配置或复制已有配置；基础产品的共性组件和核心要素作为基线，可售产品在允许范围内调整参数并增加差异化组件要素，实现"共性规则继承 + 个性条件扩展"。

适用范围与场景化配置

• 适用客户：限定产品目标客户范围（个人、对公、同业、集团客户等），业务选择产品时参与匹配校验；
• 适用机构：配置允许经营的机构范围，上级适用可按规则覆盖下属机构；
• 区域限制：与适用机构共同形成"什么机构可以办理 + 什么地区可以开展"的经营边界；
• 产品场景：同一产品在不同业务场景需要不同条件时，基于产品通用配置复制形成场景配置并差异化调整，形成"产品通用配置 + 场景差异配置"两层模式；未形成差异化配置时继续使用通用配置；产品适用机构与场景适用机构冲突时，以产品适用机构为最终约束。场景不是新的产品层级——产品回答"卖什么和按什么规则办"，场景回答"特定业务环境下如何差异化适用"。

与业务执行资源的协同

产品配置还引用业务办理使用的公共资源：流程（产品管理维护"产品使用哪个流程"的关联，流程定义由流程管理负责）、页面（页面能力定义可复用页面，产品配置选择适用组合）、模板与影像（合同、业务、影像模板由公共能力维护，产品明确适用关系）、核算产品映射（信贷产品面向客户和业务规则，核算产品面向核心账务，二者保持独立定位，业务执行依据映射完成核算衔接）、个性化抵质押率（按"产品 + 场景 + 担保方式 + 押品类型"优先获取，未配置时使用押品类型统一标准，属于产品风险条件对押品通用规则的差异化约束）。

建立测试与发布

总体过程：产品登记/目录建立 → 产品配置 → 产品测试 → 提交审批 → 审批通过 → 产品版本生效 → 进入运营。

产品测试是配置进入正式发布前的质量门槛，包括三类：完整性检查（必须配置的组件要素是否遗漏）、逻辑一致性检查（存在勾稽关系的组件要素是否相互一致）、产品要素影响分析（识别要素调整可能影响的业务范围）。完整性和逻辑检查存在问题时不进入正式审批。

版本与变更管理

同一产品保持稳定身份，不同时间可有多个配置版本。版本用于固定某一时点的完整配置、区分当前有效与历史配置、支持变更追溯、版本差异比较以及基于历史版本重新形成新版本。

变更过程：“当前有效版本 → 发起变更 → 形成新版本 → 产品测试 → 审批 → 新版本生效 → 原版本转历史”，不改变产品身份和目录归属。恢复历史配置通过历史版本复制实现——以历史配置为基础生成新的产品版本而非恢复原编号，既恢复既有规则又保持演进历史连续。

四维状态与三档运营管控

产品管理区分四个相互独立的状态维度，避免将所有状态合并为一个产品状态：

业务运营层面设三档控制，强度递进：

• 停用：不允许发起新业务申请，在途业务可继续、符合后续条件的仍可放款——停止新增、保持存量连续；
• 暂停：不允许发起新业务，在途业务保留但不继续放款——同时控制新业务进入和在途业务形成新的风险暴露；
• 停牌：总行风险管理责任基于产品风险表现实施的独立风险管控，不允许新增，在途业务原则上不放款，特殊需要按特别申请规则处理；复牌后解除管控。

自动风险触发：产品不良率超过不良停牌阈值时自动触发产品停牌，形成"产品经营数据 → 风险指标 → 阈值判断 → 产品风险管控"的反馈链。产品管理执行产品层管控状态变化，底层信用风险识别和专业判断仍由风险管理能力协同承接。

生命周期与经营分析

产品全生命周期：产品登记 → 产品配置 → 产品测试 → 审批发布 → 运营使用 → 产品变更 → 新版本发布 → 运营控制/恢复 → 退出。退出后历史业务仍保留原产品身份和必要历史信息，用于存量业务管理及追溯。

产品分析从四个角度形成经营视图：业务表现（进件、授信人数与金额、余额、放款、审批通过率、放款记账率、逾期率、不良率等）、流程效率（各处理节点用时、瓶颈、产品与机构间效率差异）、版本分析（规则配置演进与经营表现结合）、经营与风险闭环（“经营数据 → 表现分析 → 问题识别 → 产品调整/运营控制 → 新版本或状态变化”）。分析结果通过正式产品变更和版本管理落地，不直接修改当前有效配置。

与其他领域及企业级产品体系的协同

产品管理作为跨生命周期的专业对象管理领域，与客户管理（客户类型分类参与适用性判断）、业务准备、尽职调查、授信申请、审查审批、额度管理（产品决定是否纳入统一授信及使用规则，额度结构仍由额度管理主责）、押品管理（差异化抵质押率，押品类型价值权证仍由押品管理主责）、合同签约、放款管理（停用/暂停/停牌影响业务执行）、贷后管理（状态变化不改变历史产品归属）、公共管理、风险管理专业能力及核心系统协作。

企业级协同上，全行产品谱系平台是企业级产品目录及产品生命周期主数据来源，智慧信贷产品中心承接统一产品身份和目录信息，并在此基础上维护信贷业务所需的产品条件和详细配置，形成"企业级产品目录/状态 → 智慧信贷产品身份 → 信贷产品条件与配置 → 授信及执行业务使用"的协同链，同时向其他业务模块和外围系统提供产品目录与配置信息服务。

2 - 应用架构

智慧信贷项目的应用架构文档。

• 应用架构设计：业务架构承接映射、五层应用结构、20 个微服务、依赖调用约束、数据库划分与定级治理

2.1 - 应用架构设计

下载矢量版 SVG

依据《新一代智慧信贷平台-技术架构设计》第一章（业务架构承接）与第二章（应用架构）提炼。技术架构设计严格以固化的业务架构基线为前置输入，向上对齐业务语义与责任边界，向下完成技术转化，实现业务组件服务化、业务能力功能化、业务对象数据化、业务场景流程化。

业务架构承接

技术架构以业务架构标准化的四大核心要素为主轴，各要素承接价值层层递进：

业务架构由此构建"领域分层、组件承载、能力落地、对象托底"的稳态结构，解决原有权责模糊、流程割裂、能力碎片化、数据口径不统一的问题；技术架构在此基线上完成精准映射，避免服务划分与业务责任错位。

应用架构总体结构：五层

应用架构自上而下分五层，核心是"敏态作业 + 稳态能力"的双层信贷架构——流程敏捷迭代、核心能力稳定复用：

• 渠道展示层：本次建设直接负责信贷门户（PC 端）与个人移动信贷（PAD 端）；行内小程序、手机银行、企业网银不参与前端建设，仅以接口方式提供服务。
• 接入层：系统对外统一入口，封装内部能力中心避免直接暴露。三大职能：安全管控（统一认证与鉴权）、联机交易调度（服务网关路由分发、负载均衡至后端微服务）、批量交易调度（批量调度平台完成任务编排、监控与负载均衡）。
• 作业层（敏态）：由信贷系统抽离的作业中心构成，覆盖贷前、贷中部分生命周期，统一管理与驱动流转阶段的状态迁移和业务形态转换。含对公授信作业中心、零售授信作业中心、授信执行中心和查询中心（为减少能力层互相调用而设的跨域聚合中心）。设计原则：跨多个中心的复合查询须上提作业层整合；仅涉及单个能力中心的交易直接调用，无需作业层编排。
• 能力层（稳态）：所有业务能力的聚合与抽象层，将公共核心能力（客户、押品、额度、授信批复、外部信用信息、影像档案等中心）封装标准化，向上提供统一调用服务。遵循高内聚低耦合；涉及多个能力中心的数据交互须经作业层调度协调，禁止能力层调用作业层。
• 支撑层：三类支撑——基础服务（系统管理、鉴权、门户、档案管理）、工具与平台（流程中心、规则引擎）、批量交互服务（批处理及与外围系统的批量数据交换）。

20 个微服务清单

服务划分原则

数据主责（按数据责任归属聚合分析）；稳态下沉（面客与内部审批分离、过程与结果分离、配置与运行分离，稳定功能沉淀为公共能力）；边界清晰（一个微服务只负责一块业务，功能不重叠）；去中心化（主线功能可拆分，不能只剥离周边工具类功能而残留中心节点）；基于性能（高性能压力模块独立，联机与批量分离、业务功能与统计分析分离）；规模可控（防止服务划分后形成新单体，公共领域层功能尤其防膨胀）。

服务依赖与调用约束

依赖原则：上层可依赖下层、下层不依赖上层；同层可单向依赖，不可交叉、循环依赖；原子服务不能依赖聚合服务；核心服务不直接依赖非核心服务，需通过防腐层访问；技术类服务不依赖业务功能服务。

调用约束（硬性）：一次同步交易的调用链上不可超过四个服务，异步调用（经队列）视为链条终断、链长重新计算；一次同步交易杜绝循环调用。以此防范长调用链与循环依赖带来的超时和雪崩风险，同时约束作业层编排复杂度。

服务划分过程

采用"流程分析 + 复用性分析"两段技术，自上而下拆解业务能力：

• 流程分析：对端到端流程的原始业务活动做拆解（按主业务对象、生命周期阶段、稳敏属性、执行模式拆分，不拆到技术步骤）与融合（同对象同目标强绑定活动、跨流程等价语义活动、对外表现为一个业务节点的多原子活动），输出标准化业务活动清单，并按"活动生命周期是否依附特定流程实例"初判归入业务处理域能力（敏态候选）或基础业务域能力（稳态候选）。
• 复用性分析：向上分析对原子活动做三重复用判定（全行适用、跨端到端流程、跨产品/产品系列，三者同时满足才为公共活动），区分公共业务活动（待下沉）与差异化活动（保留上层）；向下分析将公共活动拆解为单一原子服务、组合原子服务，并识别业务聚合服务候选。内部逻辑无差异但复用场景少仍判差异化不下沉——下沉以真实复用广度为准。
• 服务收敛：原子/原子组合服务归稳态能力层（按主业务对象归集），业务聚合服务归敏态作业层（按业务场景归并），原子与聚合服务不得混置同一微服务；批量、台账报表类按"基于性能"原则拆入批量微服务与查询中心；最后校验依赖约束并以对公授信全流程、放款流程反向走查。

数据库划分

三原则：业务域边界（每微服务对应独立限界上下文，业务主数据所有权唯一归属主责微服务）；就近高内聚（聚合根实体与从属子实体、明细流水统一置于主责服务库）；单一可信数据源（每份数据仅一份主库，下游只可维护只读副本且不可修改）。

落地为：三个作业库（对公授信作业库、零售授信作业库、授信执行库）、八个能力库（客户、产品、额度、押品、授信批复、外部信用信息、影像档案）及系统库、批量库；信贷网关与移动前置无库；查询中心、批量微服务为多数据源。

微服务定级

20 个业务与技术微服务按业务影响（高：影响外部客户与我行形象；中：影响行内业务人员；低：仅影响科技团队）与技术影响（高：故障导致大面积服务不可用；中：影响部分服务且恢复迫切；低：影响有限）两维评估，决策矩阵输出高/中/低三级。

高等级服务包括：信贷网关，对公/零售授信作业中心、授信执行中心，客户、产品、额度中心，流程中心、规则引擎，注册/配置中心与缓存服务。运维保障分级：高等级核心联机服务多副本跨可用区部署、数据库主从高可用、最高优先级告警；中等级双实例集群；低等级以故障隔离为首要目标。跨等级依赖管控：高等级服务禁止强同步依赖低等级服务，必须经防腐层调用，隔离低等级故障向核心链路传导。

微服务治理

治理以资损风险防控为首要目标，基于微服务运维管控平台执行与观测，覆盖服务生命周期、流量韧性、可观测性、安全、运维变更（配置）五大治理域。核心原则：

• 双层流量故障隔离：网关层治理经网关的 HTTP 流量（API 暴露管控、路由、限流熔断、IP 黑白名单、负载均衡），微服务服务侧治理全部入站流量（含行内 ESB 转发、网关转发、内部 RPC）；写交易接口两处均禁用重试，幂等、防重、事务校验等核心防护下沉业务代码实现。
• 可观测先行：日志采集与调用链埋点接入平台先于防护策略上线，重点关注 P99 长尾耗时，依观测数据迭代治理阈值；监控含服务/接口监控、链路跟踪、日志中心、服务拓扑。
• 配置可信可控：业务开关、限流阈值、参数统一配置中心托管，禁止硬编码；版本历史、灰度推送、一键回滚，敏感配置加密存储。
• 平台能力互补：运维管控平台承担注册实例运维、网关管控、服务侧流量治理、配置与全链路可观测；外部第三方调用鉴权由行内 ESB 统一承接；微服务内部 RPC 容错与业务校验由业务代码实现。

应用架构图

全屏打开 ↗

3 - 技术架构

智慧信贷项目的技术架构文档。

• 技术架构设计：前后端分离六层架构、开发平台四统一、流程/规则/调度/注册配置/管控/分布式事务平台组件

3.1 - 技术架构设计

依据《新一代智慧信贷平台-技术架构设计》第三章（技术架构）提炼。系统整体采用前后端分离架构，自上而下分为渠道层、展示层、网关层、服务层、持久层、支撑层六层。

总体分层

技术组件按四类开箱即用：安全类（授权权限、国密 SM2/SM4、AccessFilter、XSS 防御、数据脱敏、数据权限）、数据交互类（MybatisPlus、HikariCP）、服务通信（OpenFeign、RocketMQ、Redis 幂等、Loadbalancer）、运维工具（异常处理、Logback/Slf4j、文件上传下载、序列号、Session、Saga 分布式事务）。技术栈版本以行内安全规范为标准（详见原文组件版本表）。

开发平台：四个统一

• 统一的设计规范：用户体验、界面交互、组件设计、代码四类规范全流程标准化；
• 统一的开发模式：前后台分离、开发分离化/技能专业化/实施工艺化、全生命周期持续集成；
• 统一的开发工具：一体化开发平台、可视化拖拽与代码生成、多架构适配（单体/微服务）、自动化运维；
• 统一的技术平台：自主可控底座、统一技术栈标准、松耦合高复用架构、全渠道场景适配。

流程引擎 echain

宇信科技自主设计研发的一套基于数据库的工作流微服务组件，定位解决所有与工作流流程相关的线上活动，适用于信贷审批、自动审批类（半人工半自动/自动授信流程）、公文审批、人事财务等广泛场景。产品 2004 年诞生，历经四个大版本迭代：echain1.0（产品雏形）→ echain2.2（基于 WFMC 标准）→ echain3.X（无缝对接 YUSP 统一开发平台）→ echain V4.X（SpringCloud 分布式版本）。在智慧信贷中对应支撑层的流程中心微服务，承接"作业协同"业务能力（统一管理与驱动流转阶段的状态迁移，见应用架构）。

六大产品特色

• 可视化建模工具：Web 版流程图建模，托拽绘制、定义便捷；
• 图形化监控：可视化审批轨迹监控，直观监管流程办理全过程；
• 流程仿真：验证绘制完成的流程图能否成功运行、是否符合配置的路由规则，再上线；
• 智能路由：路由运行动态脚本控制流程走向，应对复杂审批场景；
• 丰富的审批动作：提交、打回、退回、转办、否决、作废、子流程、项目池、跳转、拿回等；
• 更强的扩展性：审批人员、提交条件、路由条件等均可自定义扩展。

功能模块与流程定义

四大功能模块：流程管理、流转引擎、我的工作台、流程监控。流程定义支持流程图增删查改、导入导出、复制，启停与流程图热部署，以及生成新版本的版本管理；流程图管理提供 Web 页面托拽绘图，属性栏支持配置多种审批动作与业务操作。

节点体系

• 必须节点：开始/结束——一个开始、多个结束；
• 人工节点：普通（支持审批后业务处理，可配置节点审批权限/审批按钮）；单选/条件单选（提交后续流程时必须从分支中选择一个，条件单选可在与后续节点连线上配置路由条件，结果为"真"的才能被选择）；多选/条件多选（可从后续多条连线中选择多个分支提交）；
• 自动节点：汇总（非人工节点，多选分支后必须进行汇总）；自动运行（引擎自动提交到后续节点，支持配置业务处理）。

高级属性配置

节点级丰富配置：处理人员（拥有审批权限的用户或对象）及计算方式、人员指定（提交到下一节点时的分配方式：人员列表选择、系统指定）、办理类型（节点内多用户的单人/多人办理模式）、待办通知方式、任务分配策略、节点标识、子流程配置、节点脚本；提交条件与启动条件（按配置判断，支持扩展）；业务处理（审批完成后由流转引擎调用，含业务通知接口与业务处理扩展接口）；智能路由（路由条件的 Java 脚本在线编辑，或经接口实现自定义规则校验——如扩展决策引擎）。

流转引擎：审批动作全集

• 基本动作：发起（构造流程参数发起流程数据）、提交（同意流转至下一节点）；
• 回退类：退回（前节点/发起节点/指定节点，可扩展、可连续退回）、打回（已办理节点，可连续打回并可自定义打回节点列表）、拿回（本人已办理且运行中的流程拿回本节点）、撤回（发起人从任何节点拿回初始节点）、否决（标识流程结束）、作废（被退回/打回后发起人作废流程）；
• 协同类：转办（转交他人办理）、协办（他人办理后流转回本人）、跳转（交由流程中其他节点，可扩展）、抄送、催办（特定方式催促办理人，可扩展）、挂起/唤醒（挂起后无法审批）；
• 子流程：流转到特定节点时发起子流程，支持手动/自动、同步/异步；
• 高级操作（管理员）：重置节点办理人、激活已办结流程（激活后回到发起节点）。

工作台与流程监控

我的工作台提供待办数据（当前审批人与节点、流程审批状态、多条件查询；详情含业务页面展示、丰富审批动作与审批历史路线查看）、项目池（关联岗位人员认领项目池任务后审批）、委托（将委托人业务委托给被委托人，可自定义业务范围与委托时间段）。流程监控从不同维度查询展示流程实例数据，帮助管理员分析统计流程运转情况，并提供超管操作（如废除实例）。

集成与扩展

部署依赖数据库，Redis、邮件服务器、MQ 为可选中间件。扩展开发采用流程属性扩展接口模式（如启动条件判断的 StudioBeforeStartInterface）：添加实现类继承指定属性的抽象类接口，定义扩展选项显示名称即可注入引擎。工作流相关表以 N_WF_ 为前缀（如 N_WF_FLOW 流程图记录表）。

规则引擎

将业务规则从程序代码剥离，业务人员可视化配置业务决策，运行时可修改。功能架构分两层：

• 上层核心规则层（规则全生命周期）：规则管理 10 项操作（新增、复制、修改、删除、查询、导入导出、启停、仿真——先仿真验证再启用，避免错误规则影响生产）；规则编辑（语法检查、6 种规则类型）；版本管理（新版本留痕、可追溯、可回滚，满足合规审计）。
• 下层基础资源层（三大支撑模块）：模型库（规则分组容器与权限隔离）、指标（“客户年龄"“逾期次数"等原子判断因子，统一定义避免口径不一）、数据集（数据源与 SQL 管理，SQL 可测算后上线）。

规则形态支持自由规则、评分卡、决策树。

调度平台 USE

宇信企业统一调度平台，支持断点续跑、失败重试、交易补偿，可与行内调度工具及 ETL 集成。逻辑上由管理端、调度引擎、执行节点三个组件构成；对信贷系统而言，执行节点就是信贷批量服务。系统架构自上而下分三层：

• 管控层（系统管理及监控平台）——面向运维/管理员的人机交互门户，五个功能模块：应用管理（数据源、日历、事件、作业流程、触发器、公共参数、执行集群、批量重跑方案等基础环境配置）；系统监控（任务监控、触发监控、作业清单、警示监控、资源监控、事件查看的全局运行看板）；警示管理（警示模板、警示对象、作业告警、资源告警的告警规则配置）；平台管理（应用系统注册、应用授权、作业类型维护，管控可调度任务的类型范围）；OCA 功能（机构、角色、用户、功能/数据授权、菜单、数据字典、日志审计的统一权限体系）。
• 调度引擎（核心调度层）——批量任务的中枢"大脑”，四个子模块：任务管理（任务初始化、后置处理、任务清理，负责调度实例创建、收尾与资源回收）；作业管理（作业前置校验、事件检查、调度分发、任务分片派发、后置处理与扩展）；执行节点管理（节点注册、上下线处理、启停指令下发、心跳探测）；底层支撑（主备切换、调度线程池、告警通知、资源管理，保障引擎自身高可用）。
• 执行节点（远端执行层）——内嵌在业务服务中，四个子模块：主控制器（与调度引擎的通信中枢：节点注册/下线申请、心跳上报、作业接收、状态控制、作业中断）；执行器（六种作业类型的实际运行载体：BEAN、SHELL、SQL、存储过程、SP、HTTP，可执行代码脚本、数据库、接口类批量任务）；状态汇报（作业运行结果与日志的回传通道）；健康检查（健康状态与 CPU、内存、存储、JVM 指标采集上报）。

调度操作层面提供调度首页（全局运行视图）与作业流管理（作业流定义、依赖编排与重跑）。

核心能力：定时/周期/事件触发多模式调度，可视化配置任务依赖（任务 A 完成触发任务 B）与优先级管理（高优先级抢占资源）；大批量任务分片拆分与并行执行（如百万级计息任务拆分多节点并行），日终批处理多机随机分配且不重复执行。容错与可靠性：断点续跑（异常中断后避免重复处理）、失败自动重试（全量或增量）、幂等与互斥（“运行中单任务不允许重复调用”、“约定时间段内禁止重复运行”）。集成与资源管控：与行内 Control-M 调度集成；数据抽取与 DataStage 集成，报文符合行内 ESB 标准；可视化作业并发数在线增减；时效约束为单个批量任务 ≤0.5 小时、总时长 ≤2 小时，超时自动告警。

全屏打开 ↗

注册/配置中心 Nacos

信贷门户微服务全部依赖 Nacos 做服务注册与配置统一管理。架构四层：客户端层（Provider 启动注册 IP/端口，Consumer 拉取实例列表寻址）、服务端核心（Naming Service 命名注册 + Config Service 配置中心）、一致性协议层（Distro AP 协议管服务实例——可用性优先；Raft CP 管配置数据——一致性优先）、持久化层（开发测试用内置 Derby，生产用 OceanBase-MySQL 租户）。

核心流程：服务注册（SDK 上报→心跳维持→异常剔除）、配置拉取与动态推送（控制台修改→长轮询实时推送各微服务，改配置不重启服务）。

管控平台

微服务全生命周期管控体系，从系统管理、服务部署、服务治理，到监控日志、配置中心、告警中心，形成覆盖服务从上线到运维的完整闭环（自动化发布结合 DevOps 平台实现），为微服务架构提供一站式、全链路的技术支撑与管控能力。

• 服务治理：外部请求先进 API 网关，治理管控向其推送服务注册发现、路由、限流熔断等策略完成流量入口统一管控；API 网关将请求转发至后端微服务后，治理管控再推送服务治理策略，实现运行阶段全链路治理。配置策略：运维管控台可视化配置 → 推送配置中心 → 实时同步微服务（主动监听最新配置），保障配置实时生效，运维台也可在线读取配置形成闭环。技术实现与 SpringCloud Gateway 结合的六个要点：网关作为统一流量入口（路由转发、负载均衡、协议转换）；通过 Nacos 实时监听路由/限流/熔断规则，配置变更动态刷新无需重启；接入注册中心按服务名动态路由，支持上下线自动感知；运维平台统一配置路由、限流、熔断、权限、超时等策略经配置中心推送执行；网关完成鉴权、流量控制、日志与链路追踪，统一处理跨域、重试、降级；请求闭环为"外部请求 → SpringCloud Gateway → 治理规则校验 → 动态路由转发 → 后端微服务 → 结果返回”。
• 部署发布：部署中心四项功能——主机管理（部署主机管理）、应用管理（微服务登记）、制品管理（zip/tar/tar.gz 制品上传）、应用部署（先选制品，再选部署应用与主机执行部署；前提是系统接入注册中心且主机安装 agent）。
• 监控告警：面向分布式系统的统一微服务监控平台，覆盖业务监控、应用层监控、中间件监控、链路监控、主机监控五大监控域，遵循行内监控体系规范实现全栈可观测。支持多技术栈应用、数据库、Redis、MQ 等基础组件一站式集中监控；针对接口服务持续采集访问量、响应延时、调用成功率等核心指标；内置异常检测能力，快速梳理异常关联范围，定位涉及的接口与主机，区分单机故障与集群共性问题；针对 Java 应用采集 GC、内存、线程等 JVM 指标。技术实现基于 Prometheus + AlertManager + Grafana：Prometheus 集群负责采集应用、主机、中间件、数据库等目标指标；Grafana 实现监控大盘与告警看板统一展示；Prometheus 的告警规则统一推送 AlertManager 集群，完成告警的去重、分组、路由与通知分发。

全屏打开 ↗

分布式事务 Saga

采用 Saga 模式并做三方面改进：去除协调中心 server 端（无需独立部署，事务状态存业务数据库）；框架以 SDK 嵌入（状态机引擎与事务管理下沉）；业务补偿由框架触发（无需硬编码）。核心组件：事务协调器 SDK（状态机引擎 + 补偿管理器）、事务状态存储（基于业务数据库）。

三条强制原则：业务幂等性（正向与补偿操作都必须幂等）、事务边界约束（Saga 不跨服务传播，只能在发起服务内编排，下游用本地事务保证一致性）、补偿可达性（补偿必须能执行成功，下游必须提供补偿接口）。失败处理：补偿失败自动重试（定时补偿器，3 次）；人工处理支持手工重试补偿与强制标记补偿结束。

技术架构图

全屏打开 ↗

4 - 集成架构

栏目建设中，将收录系统间接口清单、上下游依赖与集成数据流。

5 - 部署架构

智慧信贷项目的部署架构文档。

• 部署架构设计：同城双活方案、五类接入通道、中间件跨中心部署与高可用架构

5.1 - 部署架构设计

依据《新一代智慧信贷平台-技术架构设计》第四章（部署架构）提炼。整体采用同城双活方案：双中心两个虚拟机集群（业务集群 1/2），网络互通，通过负载控制向两个业务集群分发请求。

接入通道

中间件部署

• Nacos 跨中心部署：以 clusterName 区分（生产中心 A_ZONE / 灾备中心 B_ZONE），依赖 spring-cloud-starter-loadbalancer。正常情况各中心服务优先使用本中心 Nacos，两中心间同步复制；某一中心 Nacos 异常时服务访问另一中心。
• Redis 跨中心部署：虚拟机部署集群，一主三从五哨兵。跨中心的原因：登录 token 需全局共享（请求随机分发到两中心，若各自部署 Redis 会鉴权失败）；数据字典、风险拦截信息等缓存需保持两中心一致。
• RocketMQ 中心级部署：每个中心各部署一套集群，各中心独立生产和消费。
• 管控平台：整体部署一套，组件跨中心部署，统一管理两个集群，实现跨中心数据整合与监控。

高可用方案

两个中心为"生产中心"和"灾备中心"，每个中心部署完整的业务集群，任一中心完全不可用时另一中心可继续支持业务全流程执行。

注册中心双中心：Nacos 跨中心 3 节点集群（生产 3 + 灾备 2 布点）共用一套集群、共享数据库；服务启动注册并同步各节点，消费者本地缓存服务列表；默认中心内路由，中心内无服务才跨中心访问；通过域名就近解析。

全屏打开 ↗

缓存双中心：哨兵模式——生产中心 Master + Slave-1 + Sentinel 1/2/3，灾备中心 Sentinel 4/5 + Slave-2/3。容灾语义分三级：中心内 Master 宕机，Sentinel 自动故障转移（Slave-1 升主，业务短时波动）；生产中心整体宕机，剩余 2 哨兵无法自动选主，需人工执行 SENTINEL FAILOVER mymaster 将灾备 Slave 提升为主；生产中心恢复时先启 3 个哨兵节点、组网正常后再启 Redis（严禁先启 Redis 后启哨兵），数据同步完成后业务低峰期手动回切（replica-priority 控制）。

全屏打开 ↗

消息队列双中心：每中心 7 台服务器——3 NameServer（内嵌 Controller）+ Broker 2 主 2 从（2M2S），主从同步双写保障消息不丢，基于 Controller 模式（5.x Raft）自动故障切换；任一中心主节点宕机，消息不丢失、服务自动切换。双 Master 多队列负载均衡：队列数 ≥ 消费者实例数，生产者均衡发送、消费者平均分配队列。宇信分布式消息组件提供消息持久化、异步发送与补偿、消费幂等。

全屏打开 ↗

应用双中心：两中心部署完全一样的集群，注册到统一 Nacos（集群标志识别数据中心），每中心可独立完成信贷全流程；中心内就近路由负载均衡。每个应用至少 2 节点避免单点，压力大的服务（授信作业中心、授信执行中心）按压测适当加节点。服务间 Feign 调用 + loadbalancer 负载；网关经负载设备对外；行内系统经 ESB 边车负载转发两中心网关。

全屏打开 ↗

批量双中心：USE 调度两中心部署一套集群——管理端两中心集群部署（token 不共享，需会话保持或灾备侧设为备节点）；调度端主从模式（基于数据库选主，主派发任务，主故障从自动切换）；执行节点即批处理服务多实例负载均衡。分布：每中心 1 管理端 + 1 调度引擎 + 6 个批量服务。

全屏打开 ↗

运维管理双中心：信贷运维管控平台整体一套、组件跨中心。主中心（A 机房）：管控前后端、Grafana、Prometheus+Proxy、2 AlertManager；同城中心（B 机房）：管控前后端、Grafana、Prometheus+Proxy、1 AlertManager。Grafana 跨中心共享数据库配置加负载均衡，AlertManager 集群处理 Prometheus 告警。业务微服务集成链路跟踪 agent 与 FileBeat 日志收集对接行内平台；监控分工——行内监控告警平台负责主机/中间件/数据库，信贷管控平台负责业务微服务。

环境清单

环境清单维护于《智慧信贷二期应用开发实施项目架构设计说明书 V0.3.xlsx》，待应用架构与部署架构确定后同步修订。

部署架构图

官方部署架构总览（复刻版）：

下载矢量版 SVG

提炼版交互图（拓扑关系可缩放追踪）：

全屏打开 ↗

6 - 非功能需求

栏目建设中，将收录性能、安全、可用性与合规等质量属性要求。