征信信息管理系统架构方案

征信信息管理系统系统架构方案
目录
目录 (i)
第1章前言 (1)
1.1. 项目背景 (1)
1.2. 项目目标 (1)
1.3. 性能压力 (1)
1.4. 可扩展性 (2)
1.5. 通用性 (2)
1.6. 开放性 (2)
1.7. 安全性 (2)
1.8. 经济性原则 (2)
第2章逻辑框架 (3)
2.1. 逻辑框架图 (3)
2.2. 数据源分析 (4)
2.2.1. 预警数据库 (5)
2.2.2. 500强数据库 (5)
2.2.3. 重点企业数据库 (5)
2.2.4. 上市公司数据库 (5)
2.2.5. 人行信贷登记咨询系统 (5)
2.2.6. 个人信用联合征信系统 (6)
2.2.7. 人行个人征信系统（PCRS） (6)
2.2.8. 工商局开创信息网 (6)
2.2.9. 房地产交易中心 (7)
2.2.10. 总行CIIS系统 (7)
2.3. 功能框架 (8)
第3章体系结构 (10)
3.1. 技术架构 (10)
3.2. 系统层次 (11)
3.3. 逻辑流程 (12)
3.4. 核心模块与系统流程 (14)
3.4.1. 模块说明 (15)
3.4.2. 系统流程 (16)
3.5. WEB数据处理框架 (17)
第4章关键需求分析 (20)
4.1. 法人关联查询 (20)
4.1.1. 多数据源综合展现 (20)
4.1.2. 关联查询（多层查询） (21)
4.2. 批量查询 (22)
4.2.1. 批量执行器 (22)
4.2.2. 个人批量查询 (22)
4.3. 批量数据下载 (23)
4.3.1. 任务调度 (23)
4.3.2. 断点续传 (23)
4.3.3. 手工控制 (24)
4.4. 历史信息查询 (24)
4.5. 日志管理 (24)
4.5.1. 日志记录 (24)
4.5.2. 日志分析 (25)
4.6. 权限管理 (25)
第5章基于XML的WEB信息抽取 (28)
5.1. Web信息抽取技术概述 (28)
5.2. 相关标准 (28)
5.2.1. XML (28)
5.2.2. XHTML (31)
5.2.3. DOM (31)
5.2.4. XPath (32)
5.2.5. XSLT (33)
5.3.设计思路 (33)
5.4. 总体框架 (34)
第6章关键技术分析 (37)
6.1. 组件技术 (37)
6.2. 日志记录 (37)
6.3. TIDY (38)
6.4. XML2DB (38)
6.5. Anchor-HOP模式 (39)
6.5.1. 信息定位的优化方法 (39)
6.5.2. 基于树路径的定位 (39)
6.5.3. 基于文本的定位方式 (40)
6.5.4. Anchor-HOP模式 (41)
第7章部署 (43)
7.1. 网络部署图 (43)
7.2. 分布式部署图 (44)
7.3. 系统环境 (44)
7.3.1. 硬件环境 (44)
7.3.2. 软件环境 (44)
第1章前言
1.1. 项目背景
随着经济的发展，创建一个诚实守信的社会氛围越来越受到政府、企业、个人的重视，人行、市政府、总行都陆续推出和完善相应的征信系统。

这些新生系统游离在原来的客户集成查询系统外，各行部在为企业办理信贷业务的时需要多系统查询，增加了客户经理操作的复杂性，容易造成查询不及时而增加信贷资产的风险。

因此进一步加强借款人信息的集中管理显得十分必要。

同时工商局、房地产中心等外部信息查询还需要手工分别进行操作，未实现各类信息的自动、联动查询，无法进行有效的监控和管理；从这些系统中查询的信息还无法实现有效地储存，重复利用极低，制约了我们对客户的分析工作。

1.2. 项目目标
征信管理系统是以客户征信信息上报管理查询为主，兼顾其他外部信息管理查询的工作平台，对在此平台上工作的相关业务人员提供强大的查询、管理、数据校验、决策支持。

该信息平台同时也是银行在适应以“客户为中心”的业务转型形势下的支持系统。

提高查询工作的效率，改变目前各类征信系统和外部信息分散查询的方式，实现由客户经理直接通过平台集中查询，分行进行管理监控的信息查询体系。

1.3. 性能压力
保证系统的通过应用服务组件的分布式发布和主机系统的集群能力，提供系统的高服务性能和大压力运行承受能力。

对于性能压力的最大承受能力要进行均衡和压力分配运算，保证硬件资源到高可用性，包括CPU运算能力、内存需求、系统的IO压力，网络通信能力等。

建设后的系统分布和群集能力要能满足10000数量级的门户应用访问和500
用户并发级的应用访问。

1.4. 可扩展性
系统的可扩展能力，包括硬件设备物理整合能力、系统接口的通讯方式、数据通讯格式、流程的相互借鉴、多应用的整合和发布等等。

1.5. 通用性
系统的功能设计要能满足工作流应用系统的一般业务需求，并形成核心功能接口，满足工作流系统、集成系统、二次开发等通用性需求。

1.6. 开放性
在系统的独立性基础上，必须保证系统的开放性，使本系统与其他应用系统可以有机地结合。

本系统与业务系统是相对独立的两个系统，本系统既可以独立运行，也能辅助业务系统而存在的，为了达到这个目标，我们通过提供灵活的接口，将工作流的相关处理功能结合到业务系统中，又不影响两套系统的独立性。

1.7. 安全性
系统的安全性主要考虑两个方面。

一是系统操作、运行的安全性；二是系统数据的安全性。

本系统兼顾开放与安全相结合，并遵循安全性第一的设计原则，在网络化环境下，数据的管理和应用、信息的传输和处理，各层次间均设置严格的安全措施。

1.8. 经济性原则
系统的建设是一项复杂的、长期不断发展的系统工程，因此在规划建设过程中，必须遵循长远规划、逐步建设的指导方针。

同时，在技术实现上，应采用灵
活的、能不断适应业务发展的框架，确保投资的最大收益
第2
章
逻辑框架
2.1.
逻辑框架图
... 征信数据管理系统由“本地数据库服务器”、“WEB 应用服务器”组成。

前者
主要服务数据的采集、整理、存储等功能，后者主要实现数据的展现、维护等功能。

1、行内用户（包括支行客户经理和分行各层管理人员）通过分行局域网以浏览器方式访问本系统，服务器接受响应后，通过内部网络分别到预警数据库、500强数据库、重点企业数据库和上市公司数据库查询；同时由本系统数据库服
务器连接外部服务器，按照事先约定接口（拨号或专线）查询并采集人行信贷登记系统信息、联合征信信息、总行CIIS、人行个人征信信息、工商局开创信息网、房地产交易中心等信息。

2、本系统与行内信息数据库（包括上市公司数据库、预警数据库、500强数据库、重点企业数据库）连接，向数据库发送查询请求，各数据库返回标准格式的查询报告，由本系统汇总为统一格式，呈现用户，提供浏览、邮箱转发和打印功能；
3、本系统同外部信息（人行信贷登记咨询系统服务器、个人联合征信系统服务器等）相连，发送查询条件，并分别按照人行信贷登记咨询系统和个人联合征信系统的查询操作，完成客户信息查询，同时保存查询页面和查询数据；将查询获取的信息整理为标准格式的信息查询报告；
4、在获取外部信息服务器中信息后，在本系统的数据库中存储为人行贷款卡数据库、个人信用信息数据库等数据库，以供日后系统性的分析；同时定期从上述外部服务器中批量下载相关数据，存储并可以报表的格式展现。

2.2. 数据源分析
征信管理系统可以从本地数据库和外部网站获取数据。

目前本地数据包括： 预警数据库；
500强数据库；
重点企业数据库；
上市公司数据库；
外部网站包括：
人行信贷登记咨询系统；
个人信用联合征信系统；
人行个人征信系统；
工商局开创信息网；
房地产交易中心
总行CIIS系统；
2.2.1. 预警数据库
数据库系统为ORACLE。

分为个人客户预警信息和法人客户预警信息两类。

2.2.2. 500强数据库
数据库系统为ORACLE。

2.2.
3. 重点企业数据库
数据库系统为ORACLE。

2.2.4. 上市公司数据库
数据库系统为ORACLE。

查询财务信息报告时候，可以直接使用数据库中的数据；而查询行业信息报告时，直接调用上市公司WEB服务器上的HTML文件。

按上市行业分类标准：“d:\ncicc\doc\上市+年份（如上市1998）\cust”目录下存放所有企业的、按上市分类的、给定年份的财务比率分析的文件（以股票代码为文件名：如600000.htm）。

2.2.5. 人行信贷登记咨询系统
本系统是人民银行的服务器，不允许外部直接访问数据库，通过HTML页面提供用户查询。

网站主页http://9.xx.xx.xx/。

登录，并通过客户卡号密码校验之后进入主界面。

按照预定义的路径，一次访问如下页面获取相应的信息：
1.贷款卡状态查询http://9.xx.xx.xx/public/dkkgt.htm；
2.借款人负债查询http://9.xx.xx.xx/pbcb/BORROWERDEBT.htm；
3.担保查询http://9.xx.xx.xx/pbcb/OtherDebt.htm；
4.借款人大事查询http:// 9.xx.xx.xx /pbcb/BorrowerImp.htm；
5.借款人概况查询http://9.xx.xx.xx /pbcb/BorrowerBrief.htm；
然后退出系统。

2.2.6. 个人信用联合征信系统
本系统是上海资信公司的服务器，不允许外部直接访问数据库，通过HTML 页面提供用户查询，同时提供批量查询功能，反馈每个查询客户的HTML文件格式的报告。

网站主页：https://136.xx.xx.xx:8444/。

使用HTTPS协议。

主页登录之后，提交查询条件到https:// 136.xx.xx.xx:8444/cgi-bin/orglgn_main.cgi，得到个人信用报告页面。

2.2.7. 人行个人征信系统（PCRS）
本系统是人民银行总行的服务器，通过工总行的代理进行访问，目前不能直接访问数据库，通过HTML页面提供用户查询，目前不提供批量查询功能。

网站主页：http://9. xx.xx.xx:7001/creditunion/。

需要通过代理服务器访问。

系统需要自动记录用户在PCRS网站登录的用户名和密码，以后自动匹配使用。

2.2.8. 工商局开创信息网
本系统是面向INTERNET的服务器，通过分行的代理进行访问，目前不能直接访问数据库，通过HTML页面提供用户查询，不提供批量查询功能。

网站主页：。

需要通过代理服务器访问。

使用系统配置好的统一的用户名和口令访问，需要记录所用户在该网站的访问情况。

2.2.9. 房地产交易中心
本系统通过专线进行访问，目前不能直接访问数据库，通过HTML页面提供用户查询，不提供批量查询功能。

网站主页：http://172. xx.xx.xx /Login.jsp。

需要通过代理服务器访问。

使用系统配置好的统一的用户名和口令访问，需要记录所有用户在该网站的访问情况。

2.2.10. 总行CIIS系统
本系统是总行的服务器，通过内部网进行访问，目前不能直接访问数据库，通过HTML页面提供用户查询，提供个人与法人的批量查询功能。

网站主页：http://84.xx.xx.xx/ciis/。

系统需要自动记录用户在CIIS系统登录的用户名和密码，以后可以自动匹配。

2.3. 功能框架
征信管理系统为用户提供丰富的功能。

我们把这些功能分成两大部分：
数据维护类：针对系统的参数提供增删改的基本功能，配合权限控制，基本上可以直接针对数据库进行操作，这类功能包括：
⏹用户管理；
⏹参数表维护；
⏹法人校验表维护；
⏹任务管理等。

查询类：这类功能是最频繁使用，并且在性能上，要求变化上都有着和数据维护类不同的要求，征信管理系统提供一整套完整的软件模型支持
这些功能的实现，该模型是基于组件的异步处理模型，可以提供简单的
查询报告，交互式的查询报告等，具体的功能包含：
⏹个人客户查询；
⏹法人客户查询：含交互式和非交互式两种；
⏹预警；
⏹批量查询；
⏹数据导出；
⏹日志报告；
⏹分析报告；
⏹法人历史查询等。

在模型内部，还支持调度、日志等基本功能。

第3章体系结构
征信管理系统采用多层体系结构，符合J2EE规范。

3.1. 技术架构
从技术架构上，征信管理系统采用如下的技术基础，按照其依赖关系：
1.数据源（Data Source）：对关系数据库采用标准的连接池，SQL Map等
标准的方式进行管理，对Internet数据源则采用自行开发的模块，两者
统一规划管理；
2.J2EE：征信管理系统部署在符合J2EE规范的应用服务器上，并且本身
符合J2EE规范；
3.XML：征信管理系统广泛的采用XML技术，包括系统配置，数据和展
现的配置，页面数据解析规则等，核心的处理部分更采用标准的XSLT
技术；
4.组件框架（Component Framework）：征信管理系统采用面向组件设计和
实现，系统应用一个标准的组件框架（容器）来组织系统所有的组件，
保证组件符合低耦合、高内聚的要求，可以针对组件本身进行升级改造
而把对系统其他部分的影响降到最低，这也是MVC模式中M（Model）
的最佳实现方式；
5.页面流控制（Page Flow Control）：按照MVC的要求，对用户操作的页
面流进行集中控制。

3.2. 系统层次
征信管理系统是一个多层结构系统，突出软件模型的设计。

系统分为数据层，模型层，页面控制层，和浏览器层。

每一层对向上提供本层的访问原语，屏蔽本层的实现细节。

由于浏览器层，页面控制层和数据层，都有相应的标准甚至实现，因此，我们的重点放在建立一个符合征信业务要求的业务模型，该模型的特点如下：
1.使用组件框架建立模型的基础框架，模型由组件组成；
2.采用消息机制实现异步操作，同步操作实际上有异步操作模拟；
3.采用队列、线程池控制系统的性能和并发量；
在模型层中的核心流程，则是反映系统内部最核心的操作的处理过程。

这在下一节详细介绍。

3.3. 逻辑流程
逻辑流程从逻辑上描述征信管理系统的核心流程。

征信管理系统的核心流程是根据用户的需要从特定的网站系统或者数据库检索数据，并进行综合处理，最后把结果展现给用户。

这里主要描述从外部网站系统获取数据并展现的流程。

1.检索数据：数据按照要求的数据源并发的进行处理，数据源可以根据系
统管理员进行设定，原则上，只要能保证一个独立事务的过程就可以作
为一个数据源，比如不同的网站或者数据库都可以作为一个独立的数据
源；
2.获取页面：根据要求从外部网站获取页面；
3.处理页面：使用XSLT技术从页面中获取所需要的信息，构造成为能被
系统识别的XML文件；
4.链接处理：某些页面中包含一些链接需要进一步处理，把链接目标的数
据也获取过来，连接被定义在页面处理完成之后生成的XML文件中，
如果有多个连接，则并发的进行处理；链接有两类，使用超链接地址识
别：
a)普通链接：并没有在系统中专门定义的链接，系统只是简单的获取
链接目标的数据；
b)特定链接：如同法人被担保人一类的链接，系统中需要专门进行处
理，并可以判断相关的信息有效期等操作；在这种情况，源页面中
可能并没有存在实际的超链接，而是由处理规则自动产生一个虚拟
的链接查找特定的关联信息；
5.查询数据：所有数据从外部网站获取并处理之后，都存储在本地数据库
中，然后利用SQL或者数据库相关的操作直接从数据库中获取数据并进行展现相关的处理。

实际上，在一个查询的过程中，可能同时存在从外部网站和内部业务数据库
同时获取数据的情况，由于不同的事务可以独立并发的进行处理，因此，获取数据的过程可以互不影响，独立进行，所有的事务都完成之后，统一构造展现结果，无需区分数据来源。

3.4. 核心模块与系统流程
征信管理系统的核心部分从不同的数据源获取数据，按照用户的要求展现结果。

其中数据可以是直接从关系数据库中获取的数据，也可以是从internet上获取的页面经过处理之后的数据；在系统中，把这两种不同的数据源统一进行处理。

对于大多数的展现（查询、报表、分析）功能，可以遵循下面的规则处理：
部分简单的功能，一次操作展现结果之后就结束了，但有些复杂的功能需要交互的展现，如法人关联客户的查询等，需要查询、选择、在查询。

整个系统采用消息/异步机制为基础的设计，最大限度的保证处理效率和系统稳定性。

对于用户可见的功能，系统会模拟同步的方式，在系统允许的时间内把结果返回给用户；但如果操作的时间过长，该请求会被转为异步方式，用户不能马上得到结果。

3.4.1. 模块说明
功能接口：系统模型对外接口，用户提交的请求由该模块接受处理，构造为系统内部的数据结构，调度和批量处理等模块，按照特定的逻辑向该模块发出请求。

请求处理器：对请求进行分析、记录，在异步基础上实现同步功能，进行并发控制，过滤重复请求，减少无谓的资源浪费，匹配异步结果等。

请求队列：是一个FIFO队列，保存请求对象，连接请求处理器和处理线程。

处理线程：实际上是一个线程池容器，包含个数可配置的工作线程，这些线程侦听请求队列，如果发现有请求对象，则开始工作处理请求，否则被会被挂起；处理线程的工作分两大块：一是从数据源获取数据，二是根据用户的定义渲染最
终展现的结果。

获取数据：从数据源获取指定数据的框架，在这里主要考虑把关系数据库和来自WEB的页面都作为展现结果的数据源；一般来说，关系数据库的数据可以简单的通过SQL语句表示，而来自WEB的页面数据，则需要一些特定的方式获取页面并进行解析以获得相应的信息。

Web数据源：把WEB数据封装成为系统数据源之一，用户定义展现来自WEB的数据的时候，可以直接使用系统提供的原语。

Web数据处理：需用从Internet网站上获取页面，并进行一系列的处理，处理的细节，参见下面的WEB数据处理框架和关键技术分析。

渲染结果：按照用户的定义把数据渲染成为HTML、Excel或者文本的结果。

结果处理器：对需要展现的结果进行处理，最直接的，把结果返回客户端，对于一些特殊的操作，可能会把结果保存在磁盘上，或者通过邮件、FTP发送到指定的目标。

调度：根据用户设置，定时或者周期性的执行动作。

批量处理：根据用户提交的批量文件，分解成为一系列独立的请求，向功能接口提交请求。

3.4.2. 系统流程
1、用户在操作界面上输入（选择）参数，并提交；
2、功能接口接受用户请求，并进行处理，形成请求对象；
3、进入请求处理器，先判断有没有相同的工作正在被执行，如果正在执行，
当前请求直接被挂起，等到相同的工作被处理完，一起返回给客户端；
反之，登记需要执行的动作，并且发请求对象放入请求队列；
4、处理线程被唤醒，根据请求对象，加载用户配置，进行请求处理；
5、根据数据源的要求获取数据，如果是关系数据库的数据源，直接使用
JDBC进行数据库访问，如果是WEB数据源，则按照下面的步骤进行：
a)根据要求访问网站，对于不同的网站有不同的访问和登录的要求，
获得指定的页面；
b)对页面进行优化处理，使页面内容符合XML规范，并使用相应的
规则对页面进行处理，获取其中的信息；
c)把信息存入系统数据库中；
d)从数据库中获取数据；
6、结合展现样式的定义渲染最终的展现结果；
7、对于某些操作来说，可以在展现结果上进行操作，并且再次提交请求，
重复1的动作。

3.5. WEB数据处理框架
WEB数据处理框架提供了一个可扩展的框架，满足系统从WEB上获取并且解析数据，以及其他应用模块对WEB数据的操作等要求。

在这个框架中，有两个重要的需要扩展的部分：
规则映射（Rules Mapping ）：不同的页面有着不同的信息和信息的组织
方式，因此每个页面都需要一个专门的规则来告诉系统怎样获取这些数
据，这些规则使用标准的XSL ，需要建立一个可扩展的框架，在新增页
面的时候，可以方便的增加相应的规则，并且可以直接使用；而原有页
面上的格式调整，有限度的数据变化，都可以局限在规则的修改，而不
需要影响系统本身；
网站处理器（Website Processor ）：不同的网站有着不同的访问要求，包
括：
⏹ 网站地址，端口；
⏹ 访问协议，HTTP 或者HTTPS 等；
⏹ 登录规则：不同的网站需要不同的登录方式，有些使用固定的用户
名/密码，有些使用映射表找到相应的用户名/密码，有些则需要用户
输入验证码；
访问规则：可以是直接访问一个特定的页面，也可以是按照一个既定的路径依次访问，甚至是根据页面的内容进行关联的访问；
不同的要求都有着不同的实现方式，系统提供一个可扩展的框架把这些不同的实现方式组织在一起。

另外，WEB数据处理框架中，还有四个重要的模块：
1.TIDY：对HTML页面进行优化，使之变成符合XML规范的XHTML；
2.XSLT：系统采用的规则由XSL文件表示，因此，可以采用标准的XSLT
过程把页面变成可以被程序所理解的仅包含所需要数据的XML文件；
3.XML2DB：把XML文件的内容直接映射到关系数据库中；
4.特殊模块（Special Module）：针对一些特殊的网站访问方式专门实现的
模块，可以说是对WEB数据访问的一种控制方式，有两种：
a)路由访问（Route Query）：按照既定的路径依次访问所有的页面，
并且把页面内容记录下来；
b)追溯访问（Trace Query）：根据页面中的特定内容和指定的地址进行
交互性的或者批量的追溯访问，一直到没有相关信息位置（超链接）。

第4章关键需求分析
这章对征信管理系统中的关键需求进行分析，并不涵盖系统的所有需求，只对系统中最关键的部分进行初步分析。

包括：
法人关联查询；
批量查询；
批量数据下载；
日志管理；
权限管理等部分。

4.1. 法人关联查询
法人关联查询需要从人行信贷咨询系统、法人客户预警信息库、上司公司数据库、500强数据库、重点企业数据库、总行CIIS等系统获取相应的信息，构造一个综合分析报告。

其中，要对借款人和担保人进行查询，并对他们的关联企业（被担保人或其他关联企业）信息进行追溯查询，并一直追溯至最终的被担保企业与我行无负债业务为止。

在进行人行信贷咨询系统查询时，事先由用户选择查询的方式：
查询到第几层，即追溯到底或追溯查询的层次数，缺省为“追溯到底”；
是否每层查询前进行人工干预，即从第二层开始，用户在每层查询前选择需要查询的企业，缺省为“人工干预”。

上述两种情况的最终结果，都是展示一个法人客户的综合分析报告。

4.1.1. 多数据源综合展现
征信管理系统平台支持同时从多个数据源获取数据，并综合在一个报告中展
现。

每个数据源都包含独立的事务过程，可以进行预处理（抓取页面、存储过程等操作），获取数据等操作，形成系统内部的数据模型
在系统中，可以对数据模型内部进行二次加工，最终生成所需要的报告。

不同的数据源是同时并发的执行，最大限度地提高系统性能。

4.1.2. 关联查询（多层查询）
法人关联查询中，需要对企业的关联企业（借款人或被担保人）进行追溯查询，一直到关联企业与我行无负债业务为止。

关联客户作为源页面中的一个标识，可以在页面处理规则中增加标识的识别代码，形成目标信息的查询地址和参数，自动（或根据需要）获取关联信息，并在系统内部形成一个关联图。

4.2. 批量查询
用户可以提交一个批量查询文本，系统根据文本的定义在后台自动完成所需要的所有信息查询，并把生成的结果以邮件方式发送，或者暂存在服务器中，用户可以根据需要从服务器下载。

4.2.1. 批量执行器
系统内置的批量文本解析执行包，根据可以配置不同的实例以满足法人和个人批量查询的文本的要求。

批量执行器逐行读取批量定义文件，并校验按行校验内容，如发现不正确的请求信息，则给出提示，用户可忽略或修正错误重新提交；经确认之后的文本，交由后台线程逐行执行，向系统发出请求，所得到的结果，根据用户的要求，或发送邮件，或保存在服务器硬盘上。

批量执行器是一个框架，可以客户化新的批量查询的实例，目前系统提供个人的批量查询。

4.2.2. 个人批量查询
批量查询文本格式：
姓名|证件号|证件类型|查询原因|
姓名|证件号|证件类型|查询原因|。