消费信贷系统架构设计项目说明指导书.docx

宇信易诚消费信贷管理系统架构设计说明书v0.1目 录1概述41.1文档目标41.2背景和建设目标41.3设计规范和约束41.4参考资料51.5述语52架构需求分析62.1消费贷关键业务场景分析62.1.1场景：申请62.1.2场景：电核62.1.3场景：审批72.1.4场景：面签82.1.5场景：还款计划和费率计算92.2消费贷业务特征92.3设计目标和标准93架构设计113.1系统业务架构113.1.1业务模式113.1.2业务步骤113.1.3功效划分123.2系统逻辑架构133.2.1功效层次划分133.2.2功效层次关系143.3系统技术架构153.3.1子系统划分153.3.2技术选型173.3.3技术架构分层173.3.4关键技术点194功效设计234.1功效模块划分234.2功效结构设计245非功效设计275.1性能设计275.2安全设计275.3容错设计281 概述1.1 文档目标架构设计说明书用于确定消费信贷系统整体架构，明确业务功效结构、技术方向、和设计标准，为后续阶段进行概要设计、具体设计、编码开发和测试提供方向性、标准性指导。消费信贷系统关键针对消费金融企业、银行消费信贷部门业务运行需求而设计，本说明书将从消费贷业务特征分析为切入点，从业务架构、逻辑架构、技术架构等多个维度，逐步分析采取何种技术架构能够在最大程度地满足现有业务需求同时，也能兼顾未来一段时间内业务发展改变。1.2 背景和建设目标 基于中国整体消费金融业务发展情况和银行关注消费金融程度，和国家加速发放消费金融牌照趋势，为了能够抢占消费系统服务市场份额，尤其研发新一代消费信贷管理系统。消费系统建设整体目标以下：1、建立优异、有效、多类型进单渠道，并建立和渠道沟通方法，以扩大和外部合作机构、消费者联络和服务质量；扩大用户群体和异地服务能力。2、为了支持消费贷款业务短、平、快、业务量大等情况，建立适合业务处理步骤。实现业务精细化管理、统计分析、监测、审批、控制电子化和自动化，提供存放、汇总、搜集、反应，为各层次经营管理者提供监控、决议、分析、预警等功效，为信贷业务创新、经营决议提供充足信息支持。3、高效影像审批步骤：经过消费信贷管理系统和影像系统整合，和经过系统提供在线通知、在线打印等自动化功效，实现业务审批模式突破，满足消费业务集中审批、无纸化办公要求。4、智能数据决议分析平台：经过多种报表展示和数据统计分析查询，为不一样层次人员提供对应数据，提升决议效率和决议效果。5、标准外围系统接口和数据规则：建立统一外围系统接口，包含人行征信/公安身份核查/总帐接口等；建立导入/导出数据和模板标准，便于和第三方进行数据文件交换。1.3 设计规范和约束l Web容器（Servlet）JSR154规范l 步骤引擎遵照WFMC规范l 规则引擎遵照JSR199规范l 内容服务器遵照JSR170、JSR283规范l 基于宇信企业EMP平台进行构建，在遵照EMP架构规范同时，在技术实现方法上接收EMP约束.l 步骤引擎参考WFMC标准进行设计，和非WFMC标准其它步骤平台对接实现上存在一定技术困难，需作为关注技术实现约束条件。1.4 参考资料消费金融企业试点管理措施1.5 述语l 个人消费贷款：金融机构向个人用户发放有指定消费用途人民币贷款业务，用途关键有个人购物、住房、汽车、通常助学贷款等消费性个人贷款。l CC：电话客服中心系统。l 电核：金融机构经过电话沟通方法核实借款人身份、贷款用途等基础情况。l 面签：贷款审批经过以后，约用户到场签署借款协议、缴纳费用，向用户说明贷款权利义务。l 合作方：指金融机构在营销贷款产品时合作伙伴，如合作商户、大卖场、4S店等等。l 功效模块：系统技术实现时，封装一类业务功效组织单元，一个功效模块下有一个或多个功效组件。l 功效组件：系统技术实现时封装业务功效和处理逻辑组织单元，每个单元在概念上和业务过程中业务实体基础一致，如用户组件。l 页面部件：系统技术实现，用于在系统界面中展现业务要素基础单元，如文本输入框。2 架构需求分析2.1 消费贷关键业务场景分析2.1.1 场景：申请 消费贷款申请，是信贷类系统经典场景之一，申请关键目标是为搜集用户贷款融资需求和用户基础信息，同时申请还需借助多种渠道来充足发挥其市场营销功效。在消费贷申请场景下，会有多个运作模式，比如由用户经理直接登录系统操作完成、由用户经过多种渠道操作完成、由合作商户经过多种渠道代理用户操作完成等等。消费贷申请用例图以下： 图2-1从上图中可知，消费贷申请过程中包含到角色有用户（申请人）、经销商（合作商户）和用户经理。用户能够从网站（银行本身或第三方）、终端设备提议贷款申请；经销商能够从终端设备、合作商户子系统（消费贷子系统）提议申请；用户经理能够从消费贷系统提议申请。对用户、经销商和用户经理均能够经过系统查询申请状态（其权限范围内）。用户经理和后台自动任务能够对申请资料合规性进行筛选。消费贷申请，是整个系统业务操作入口，其包含角色、渠道多，情况复杂变数多，同时在消费贷下不一样产品申请时所关注业务要素可能有较显著差异，系统需要充足考虑金融机构消费贷产品种类井喷时系统应对方法。因为包含不少渠道是由用户主动填写并提议，所以其数据量可能会很大，对应垃圾数据量也会很大，所以需要有些人工和系统自动相配合数据筛选功效，对大量申请数据进行甄别。因为业务申请量可能较大，在设计时需要考虑尽可能将录入工作从用户经理日常工作中剥离出来，减轻用户经理反复工作量。2.1.2 场景：电核消费贷款电核，用于对用户身份和申请信息真实核查，通常情况下，电核为金融机构内独立部门使用独立系统（如CC）进行，消费贷款系统仅配合其完成电核操作即可，而不再去实现和CC系统相关功效（如任务调度、座席管理等等）。消费贷用例图以下所表示：图2-2从上图中可知，消费贷电核过程中包含到角色有用户经理、电核人员和用户。用户经理从消费贷系统中将资料提交至电核系统，同时也能够查询电核反馈结果；电核人员在电核系统中和用户电话联络，并将电核情况统计至系统中。电核过程，对于消费贷系统而言是一个可选部分，不是全部消费贷产品全部需要这一步骤，而对于没有类似CC系统金融机构，但需要对用户作电核，则能够考虑直接作为系统业务步骤一部分来简化实现，即在消费贷中系统录入线下电核结果即可。因为电核步骤包含独立电核系统，所以在设计时需要充足考虑和电核系统间可能交互模式，确保在接入不一样电核系统时，对消费贷本身业务步骤实现没有影响。2.1.3 场景：审批消费贷申请审批，也是信贷类系统经典场景之一，审批关键目标是对用户贷款申请，按金融机构内规章制度进行逐层审批。不一样金融机构、不一样产品其审批步骤步骤、参与人员、和审批规则将会有显著区分。消费贷申请审批用例图下如：图2-3从上图可知，参与审批角色关键有用户经理和审批人员（如，其它用户经理、主管、风险专员等等），担当审批人员角色不一样机构、不一样产品、甚至同一产品内不一样申请（如，新件和复议件）全部会有不一样角色人员来完成审批工作，其完全取决和行内规章制度。但不管审批角色怎样改变，其需要完成动作基础一至，关键包含对申请同意、否决、打回或撤销等等。在设计时需考虑消费贷审批过程不确性，系统需要提供灵活配置功效来应对不确定审批需求。因为天天申请单量可能较大，需要在设计层面充足考虑怎样提升审批工作效率，比如批量审批操作、自动审批、关键消息提醒等等。同时，需要提供充足审批统计数据，为行内审批步骤优化再造提供数据分析支撑。2.1.4 场景：面签面签是信贷类系统经典场景之一，面签关键目标是在审批经过以后约用户到场签署借款协议、缴纳费用，向用户说明贷款权利义务等等。通常而言面签关键工作是在系统线下完成，线上关键协议打印、登记面签结果、确定协议已签即可。但对于消费贷而言，对时间要求高，面签过程可能会直接在场外完成，以提升贷款效率。消费贷面签用例图以下：图2-4从上图可知，面签过程参与角色关键有用户、用户经理、合作商户（如经销商），假如在场内签署协议，则用户和用户经理参与即可，假如在场外签署协议，则可能由用户、合作商户、和用户经理共同参与，也有可能在场外经过专用设备进行远程面签（如视屏面签），此时就不需要用户经理必需到场，仅需合作商户经过配合即可。因为消费贷面签过程大多全部是在场内线下进行，但伴随IT技术不停发展，面签功效会逐步放在场外上线进行，系统需要充足考虑在新面签模式下怎样能很好支持。2.1.5 场景：还款计划和费率计算因为消费贷大多数全部是采取按揭方法还款，对灵活还款计划计算必不可少。系统需要能支持多种方法还款计划计算，和对应费率计算。因为金融企业可能没有核实系统，所以系统中需要能提供部分账务核实功效；而对于有核实系统银行，则需要实现和其核实系统接口。为此系统需要充足考虑怎样支持有核实系统和无核实系统两种情况。2.2 消费贷业务特征消费贷款产品和其它贷款产品相比，其基础特征是小额、快速和灵活。在运作模式上关键特征是和特约商户合作推广业务。在目标用户群体在关键特征是针对年轻人、年轻家庭和由合作商户推荐用户。服务模式上，关键特征是IT自助型服务模式。消费贷快速这个特征最为突出，其中最快贷款产品要求能够直接在商户卖场中1小时之内完成，通常消费贷款产品，要求在13个工作日内完成。而机构内审批时间要求最快能在30内分钟完成。能够说没有什么贷款产品比消费贷对工作效率要求更高，这对于承载消费贷业务运行IT系统而言，怎样满足对高效率要求将是一个挑战。消费贷灵活关键表现在还款方法、利率和贷款品种上。因为消费针正确目标用户用款需求十分明确，相对和信用卡（等其贷款产品）而言，还款方法和利率定价针对性更强，对于用户而言享用金融服务方法（如更适合本身条件还款方法）也更为多样化，更灵活。因为消费领域十广泛，和商户合作方法很多，对应消费贷会衍生出很多产品，如针对耐用消费品贷款产品、针对电子消费品贷款产品、针对教育培训贷款产品、针对汽车衍生品贷款产品等等。对于IT系统而言，需仔细考虑怎样应对业务产品形态多样化。可能是因为年轻人更能接收超前消费观念原因，市面上已经有消费贷产品面向用户关键群体通常是年轻人，消费贷产品未来一定会考虑采取更有针对性自动营销渠道，比如直接在网上商城内营销、手机/PAD等终端设备上营销、微博营销等等。对于IT系统而言则需要能支持多个营销渠道起源，同时也能提供给用户更多享用金融服务渠道，如经过手机/PAD等IT自助服务。因为金融机构消费贷产品未来发展，在很大程度上取决于对合作商户不停发掘，对于IT系统而言，需要充足考虑怎样应对不停增加合作商和合作模式给系统功效带来负面影响。2.3 设计目标和标准消费贷系统作为一个独立、新兴贷款类业务操作系统关键围绕着以下三个关键目标进行设计和建设：1、 系统能提升消费贷业务运作效率；消费贷业务对时效性要求很高，在设计时需要优先考虑，系统能提供哪些模式，让工作效率得到最大程度提升。提升用户在系统中工作效率，首先是要有良好UI设计，在UI设计时考虑能达成不一样业务场景下突出不一样关键效果，尽可能实现消息驱动UI操作模式。要提升效率仅仅从UI层考虑是不够，更应该从优化业务操作步骤着手，深入考虑IT技术怎样帮助业务流转加速，比如，自动化数据筛选、自动化审批、任务智能分配、大任务拆分、基于数据分析步骤再造等等。除此UI和业务步骤优化之外，在系统设计时需考虑提供对应机制，保障在业务高峰期系统性能，尽可能确保不会出现因为系统响应速度原所以影响业务效率，比如，合理子系统划分、流量控制、支持系统横向扩展架构等等。2、 系统能规范业务步骤、屏蔽操作风险；消费贷系统作为业务操作管理类系统而言，能够监控和约束对机构内人员行为，屏蔽人为操作风险发生，是最原始初衷之一。系统设计时，不仅仅把贷款审批过程用工作流模式来实现，而是考虑采取其来实现操作层面根本功效，经过在系统中构建各业务场景间流转逻辑关系，来实现业务规范在系统中落地。同时，工作流模式还需要和风险识别和拦截机制结合起来，才能真正发挥规范业务步骤作用。 3、 系统能支撑消费业务不停发展；消费金融企业在中国处于起步阶段，未来变数还很大，其关键表现在新消费贷产品可能会大量出现，甚至会出现全新业务模式。现在所设计消费贷系统，必需要认真考虑怎样能适应未来较长一段时间内（3年）业务需求改变，最少要确保不影响业务发展，同时，尽可能能缩短未来新产品落地开发周期，不影响新产品投放时间。3 架构设计3.1 系统业务架构消费贷业务不一样于传统个人消费类贷款，其有着更灵活业务运行方法，下面将从业务模式、业务步骤、功效划分三个部分来分析消费贷业务架构。3.1.1 业务模式消费贷业务模式和传统个人消费类贷款、和个人信用卡相比，最大不一样就是营销渠道不一样，采取现场主动营销方法，即直接在用户消费场所营销，而不是被动地等着用户上门来贷款或刷卡消费。为此，消费贷运作需要合作方支持，业务模式见下图：图3-1在传统贷款方法下，用户贷款需求是直接面向金融机构，而消费贷是经过在合作方（如卖场、4S店、培训机构等等）内主动挖掘需求。在成交以后，金融机构直接将货款打给合作方；用户方分期向金融机构还款；金融机构在一定条件下，定时付给合作方一定佣金。在这种模式下金融机构赚取了利息和手续费、合作方扩大自己用户群并能赚取一定佣金、用户则提前买到了合作方产品或服务，实现了三方共赢。在这个模式下，对于金融机构而言，最关键是怎样找到适宜合作方，且能尽可能多地扩展新不一样领域合作方，同时提供合作方感爱好激励机制（如佣金等等）；对于用户则能提供更有针对性还款方法。3.1.2 业务步骤消费贷在业务步骤上和一般贷款在本质上没有太多区分，其目地全部是为了实现审贷分离。区分在于消费贷为提升效率，步骤中各节点专业性更强、分工更明确，即采取类似信贷工厂模式（注：消费贷并不是工厂模式）。业务步骤图以下所表示：图3-2消费贷业务步骤中，电核为可选节点，有机构或产品不需电核这一步骤，其它步骤均会必选步骤，面签为线下节点，以后可能会放至线上。申请节点，由用户经理或用户填写并提议；电核节点，由独立电核人员完成对用户核实；审批节点，由管理人员完成对申请审批；面签节点，由用户经理和用户一起完成同合签署；放款节点，由财务人员完成打款操作；还款节点，由系统自动完成从用户还款账户上扣款，或用户主动提议提前还款。伴随业务量增大，以后可能会出现无法满足对放款时限要求情况，到时将考虑将上述步骤中部分业务外包出去，比如申请和电核。同时，尽可能采取自动步骤部分替换其中人工操作。3.1.3 功效划分消费贷系统关键面向独立金融机构，通常其关键职能会划分到四个子部门：产品管理部门、风险管理部门、营销部门、财务部门。对应图3-2中，申请、面签交由营销部门中用户经理完成，审批由产品管理部门和风险管理部门负责，放款由财务部门完成。具体消费贷功效划分以下：图3-3消费信贷业务功效由五个部分组成，包含业务受理子模块、贷款业务步骤处理和管理子模块、帐务模块、报表子模块、业务监控子模块，其包含了完成消费主体业务所需全部功效。各子模块完成专题工作，如受理模块关键完成营销和渠道进单功效；业务步骤处理和管理模块关键完成金融机构内部对业务全部业务处理，包含电核、人工审批、放款、贷后管理、催收和保全；帐务模块关键完成贷款或卡业务多种帐务计算，包含还款计划生成、利息/贴息计算、罚息计算、复利计算、费用计算、佣金计算等；报表模块关键完成对全部业务分析、步骤分析、用户分析、风险分析等统计和展现；业务监控模块关键用于对业务实时业务量监控。3.2 系统逻辑架构消费贷款系统功效从逻辑上划分成六个层面业务操作层、业务管理层、业务工具层、决议分析层、账务核实层和技术支撑层。功效逻辑结构以下图所表示：图3-43.2.1 功效层次划分l 业务操作层在业务操作层中功效用于直接面向用户业务操作和展现，能够简单地认为其相当于系统面门，用作信贷基层人员对最终用户业务门面和操作入口。其中包含业务产品线、合作方两大部分。产品部分以业务产品为基础组织单位，其负担着一个产品在生命周期内全部对外功效。之所从在概念上和物理上将这一层分离出来，首先能将系统功效和现实中业务角色功效映射上，降低现实业务和虚拟系统之间在基础概念和组织结构上差异；其次也是因为在业务操作层面上，业务形态丰富、变数大，期望经过架构上分离，来确保系统能适应这种特征，不会因为新业务加入而影响已经有业务。能够说业务操作层就是整个信贷业务外延。l 业务管理层在业务管理层中功效用于对业务操作层支撑和管控，能够简单地认为其相当于中后台，用于中、基层管理人员对业务运作监控和管控。本层以业务生命周期过程中业务实体为基础组织单位，其承载着各业务步骤管理、配置、监控、和对应业务实体基础功效（和现有划分基础对应），并为业务操作层提供具体功效服务。因为采取业务实体为功效单组织单位，其相对操作层而言是稳定，这是因为业务实体作为业务生命周期中承载业务要素介质，其种类个数是一定是可穷举，其在不一样贷款业务间是相同、相同甚至是可共用，而且在不一样银行间之也是相同。而相对于业务操作层面，业务产品种类个数（尤其是对未来新产品）是不可预期，不一样业务产品间使用业务实体也不会相同，更关键每种产品运作模式全部会完全不一样，不一样银行间产品运作模式也有显著差异。能够说业务管理层就是整个信贷业务内涵。l 业务工具层在业务工具层中功效，用于为业务操作和业务管理正常运作提供必需专业工具箱，但其并不对业务运作形态、业务规则或步骤产生直接影响。同时，业务工具是完全能够和业务操作、管理相分离，甚至能够替换成第三方独立系统。之所以划分出这一层，关键原因是为银行内部对专业化技能要求越来越高，伴随银行本身发展，会形成越来越多专业职能岗位（或部门），或干脆将部分非关键业务操作外包给第三方。独立工具层，能够和银行机构组织职能一一对应上；同时，也有利于在关键业务和非关键业务之间划分出一条显著界线，从架构层面去减轻二者间耦合程度。l 决议分析层在决议分析层中功效，用于对业务运行过程中产生数据进行统计分析，比如，对业务办理效率分析、对贷款人群分布分析、逾期贷款占比分析等等。决议分析层中，关键经过日终批数据加工处理、报表工具来实现对数据分析和展现。因为数据分析不是现阶段消费贷系统关注关键，所以，独立划分出决议分析层，有利于保持关键功效稳定性。l 账务核实层在账务核实层中功效，用于为没相关键业务系统金融机构，提供一个Mini版关键业务系统，其只含贷款功效，不含存款功效（注：和银监管会相关策略吻合）。其能完成贷款发放、还款扣款、罚息减免、贴息处理、减值计提、贷款形态转移等基础账务核实功效。因为不是全部金融机构全部没有核实系统，所以将本层独立出来，保持其和它层次间独立性，有利用增强产品适应能力。l 技术支撑层技术支撑层，用于为消费贷系统提供基础开发平台和运行容器，是全部业务功效落地基石。其中包含EMP容器、步骤引擎、规则引擎、报表引擎和数据访问工具等等。本层将在后继章节进行具体介绍。3.2.2 功效层次关系 消费贷款系统中六层功效之间是一个逐层依靠关系，以下图所表示：图3-5消费贷系统本质上是一个业务操作系统，业务操作层自然便成为了整个系统关键门户，是全部业务入口。业务正常运行，离不开业务管理部门（风控部门）管控，和专业部门（比如，财务部门、产品部门、客服部门、IT部门等等）大力支持。所以，业务操作层依靠和业务管理层、业务工具层、账务核实层和技术支撑层。业务管理部门为了能愈加好对业务进行管控，也需要专业部门（如产品部门、财务部门、IT部门等等）主动配合。所以，业务管理层依靠和业务工具层、账务核实层和技术支撑层。金融机构财部门是一个相对独立部门，其完全依据财务规章制度运行，通常而言，其运行关键有IT部门支持即可；同时，因为不是全部金融机构全部需要消费贷系统提供核实功效，这就需要尽可能确保其独立性，所以，账务核实层，只需要依靠技术支撑层。决议分析关键是针对数据统计分析，所以，其仅仅依靠和技术支撑层，而对于其它功效层次，也均不直接依靠于决议分析层。3.3 系统技术架构3.3.1 子系统划分消费贷系统按功效职责划分成四个子系统消费贷款管理系统、消费贷款合作方系统、消费贷款核实系统、消费贷辅助系统，以下图所表示： 图3-6l 消费贷款管理子系统消费贷款管理子系统，关键面向金融机构内部用户经理和相关管理人员，负责完成消费贷款进件步骤和业务管理。其中包含了逻辑架构中业务操作层、业务管理层、业务工具层中绝大部分功效（注：不含操作层中合作方功效），比如，贷款申请、人工审批、协议管理、放款等等。消费贷款管理子系统是整个系统业务运行关键系统。l 消费贷款合作方子系统消费贷款合作方子系统，关键面向金融机构之外合作机构，如卖场、4S店、培训机构等等，其负责为合作方和金融机构之间建立渠道和门户。其关键功效是进件处理和审批状态查询。之所以将合作方独立成子系统，首先，是出于金融机构和合作方之间合作方法存在不确原因考虑，比如，现在是对卖厂、对4S店，但以后可能会对网店、对PAD、对外包企业等等，所以将合作方功效独立出关键业务系统，作为系统对外扩展网关，会有利于消费贷不停发展；其次，是出于安全方面考虑，因为需要直接面对互联网，所以必需将对外功效独立布署，屏蔽任务从互联网上直接访问至关键业务系统渠道。l 消费贷款核实子系统消费贷款核实子系统，关键面向金融机内部账务人员，负责完成全部和贷款相关账务处理，如贷款发放、还款扣款、罚息减免等等，其和逻辑架构中账务核实层相对应。独立核实子系统，有利于增强系统适应能力。l 消费贷款辅助子系统消费贷款辅助子系统，关键负责完成数据加工和分析、定时任务调度、报表生成和展示、历史数据查询等后台任务。之所以划分出辅助子系统，关键是出于对系统性能考虑，经过独立布署子系统来完成后台任务，避免后台任务对日间业务运行效率产生不良影响。l 子系统间依靠关系消费贷款四子系统之间依靠关系以下图所表示：图3-7合作方子系统运作必需依靠和管理子系统支持，合作方子系统负责对外渠道，其独立运行没有任何意义，需要经过管理子系统来完成对每笔进单业务处理。管理子系统运作，需要有核实系统配合，核实系统能够是消费贷系统内嵌核实子系统，也能够是机构内关键业务系统。管理子系统经过核实子系统完成全部贷款账务相关业务操作。辅助子系统运行，需要依靠管理子系统、核实子系统正常运行，辅助子系统用作消费贷系统后台处理单元，其独立运行没有任何意义，需求经过调用管理子系统和核实子系统中业务功效来实现本身功效。3.3.2 技术选型消费贷系统是基于JaveEEWEB应用，其后台技术框架采取企业EMP实现，前台业务展现框架基于Jquery+EasyUi实现，具体以下图所表示：图3-8消费贷系统基础支撑环境为JavaEE和在此之上WEB容器中间件（如WAS、Weblogic等等），对Java虚拟机版本要求为1.5或1.6，对WAS版本要求为6.1以上（含），对Weblogic版本要求为10g以上（含）。技术基础框架采取企业产品EMP2.2，步骤引擎选择企业产品eChain2.2，规则引擎shuffle1.0；业务处理逻辑实现，采取组件注入机制和POJO为业务数据结构方法；业务展现逻辑基于Jquery实现，页面部件基于EasyUI实现，并用Jsp Tag包装，前后台通讯有使用Ajax方法。业务逻辑处理没有选择EMP提供标准开发方法实现（逻辑流+KCOL），而是选择了组件+Pojo方法实现，由其是在数据结构上不再使用EMPKCOL，而是选择传统Pojo方法。这是因为，期望经过功效组件+Pojo方法来实现面向对象设计思绪，不再去走面向过程+快捷开发老路。这是因为消费贷系统是业务操作类系统，其中业务运行模式、信息结构全部是含有积累价值，所以能够用面向对象设计思绪，将业务模式转换成技术框架，将业务功效包装成一个个组件，将业务要素信息映射成数据对象，最终，达成提升系统可复用性和产品形态目地。3.3.3 技术架构分层消费贷系统技术架构上划分为四个层次业务展现层、服务提供层、业务组件层、持久层。技术架构层次划分以下图所表示：图3-9l 业务展现层业务展现层负责消费贷系统和用户之间交互接口，在这一层中业务逻辑处理统一由JS负责实现，不会出现其它形式业务逻辑处理（如，JAVA代码）。不管在逻辑处理时，还是加载后台数据时，还是向后台发送请求时，其数据结构统一使用JSON格式。l 服务提供层服务提供层负责将系统内功效组装成独立事务原子服务，并以此为单位响应来至展现层（或来至其它渠道，如SOCKET、WEBSERVICE）服务请求。这里提到服务，并不是指通常概念中服务，其关键是指系统内部暴露给其用户功效，当然，完全能够将其中一部分功效，经过多种渠道公布给其它系统使用，此时其才是真正意义上服务，这里只是借用并扩展了服务这个概念，将系统提供给用户功效也认为是一个服务，确切地说是细粒度原子服务。在服务提供层中，经过对组合对业务组件层中组件调用来实现服务功效，服务层中每个服务对应着一个业务操作，其名称全部应该是一个动词，表示一个业务过程业务操作（如，提议申请、协议签署等等）。同时，在本层中还负责将从展现层（或渠道）过来EMP KCOL格式业务数据转换成POJO格式数据。l 业务组件层业务组件层负责对业务功效进行划分、封装和实现，组件层为服务层提供功效实现层面支撑。其中以组件为单位对业务功效进行组织，每个组件有着明确业务含意，其在概念上和参与业务过程业务实体基础一致，每个组件名称全部是一个业务名词，表示一个业务过程中业务实体（如，用户、协议、耐用消费品贷款产品等等）。在本层中各个业务组件内，一律使用POJO为业务逻辑处理时数据结构。l 持久层持久层负责实现消费贷系统对数据库访问和操作。在持久层中一律使用POJO为数据逻辑处理时数据结构。l 各层间关系四个层次之间类关系以下图所表示：图3-10展示现层经过HTTP请求方法调用后台服务层提供服务，此时请求报文为标准HTTP报文格式，且报文中内容也是标准FORM格式（示例：Key1=Val1&Key2=Val2&），后台服务层返回至界面数据内容则为直接为JSON格式。后台服务经过EMPRequestServlet接收请求（此处省略了对EMP框架内部处理描述），接收后经过抽像类CMISOperation来调用对应具体服务实现功效OP；在OP中将KCOL经过特定方法转成Domain类（POJO格式），然后依据业务逻辑处理需要来调用具体组件类；在组件类中将不再使用KCOL格式数据来处理业务逻辑，在组件类中直接调用持久层CMISDao中公共类SqlClient，完成系统内最基础数据操作；在持久层中也将不再处理KCOL格式数据，而直接使用Domain格式数据来操作数据库。3.3.4 关键技术点3.3.4.1 数据库访问在数据库访问层面，我们总结了在项目开发过程中使用基础框架碰到问题，并考虑用户部分提议，对EMP中数据访问层进行了设计重构。 首先，存在问题我们归纳为下表：序号问题描述1不支持复杂自定义SQL实施, 二次开发人员只好另行编写数据访问层，最终造成系统数据访问接口不统一、混乱，不利于问题排查和以后维护。2不支持使用一般业务实体对象进行数据传输：EMP中TableModelDao只支持KeyedCollection和IndexedCollection这么动态存放结构数据传输，即使灵活，不过数据存取不明确，一旦有问题，不利于排查。3不支持批量实施SQL，造成项目开发人员在开发过程中编写了大量循环操作数据库代码，对系统性能影响较大。4依靠配置文件实现ORM映射关系，这么造成系统配置文件过多，使系统文件维护过于繁琐；另外，一个ORM配置文件对应一个表僵化映射关系，对多表关联查询SQL支持乏力；另外经过配置文件进行映射肯定要用到JAVA反射机制，这也是性能消耗地方。5开发人员在JAVA代码中编写大量SQL并依据前端传入参数拼写WHERE子句条件串，轻易留下SQL注入攻击漏洞，为排查和修复这些漏洞和应付甲方安全扫描需要花费不少工作量；另外，甲方期望SQL和JAVA代码严格分离。基于以上问题，新数据访问层提供了以下处理方案和API支持：l 动态ORM映射方案该方案是基于业务实体对象一个动态ORM映射方案，该方案关键在于业务实体对象内部结构，我们在业务实体对象内置了一个MAP用来存放业务实体对象属性值，而对外使用时，仍然经过业务实体对象get和set方法进行存取，这么既确保了上层调用时明确性，同时内置MAP结构为多表关联查询和动态映射提供了很好支持，保留了KeyedCollection结构灵活性。另外无需再考虑数据库表字段和业务实体对象属性名称不一致性， 这种映射关系动态灵活，方便开发人员维护，也避免了反射使用。具体业务实体对象结构可参考下列代码： 不足是以后业务实体对象需要实现CMISDomain接口中方法，不是纯粹POJO。l SQL可配置方案该方案强制要求把SQL从JAVA逻辑中剥离出来，类似iBatis在对应XML文件中进行配置，然后程序依据配置ID动态装载SQL,并用“？”替换配置SQL串中变量，最终交给JDBCPreparedStatement对象实施。具体SQL配置文件格式可参考以下文件：经过这种强制性方案，开发人员失去了编写带有SQL注入攻击漏洞代码机会，对这类问题进行了提前预防；同时SQL外置可配置，使业务实体对象在进行动态ORM映射时，不需要指明其对应物理表名和主键字段名等信息，这么两个方案结合在一起，对复杂多表关联查询和动态映射进行了很好支持，同时也支持了在系统逻辑层中经过业务实体对象进行数据传输这一需求。另外，对于SQL配置过程碰到部分特殊问题，我们也提供了很好处理措施：一是动态SQL问题，部分SQL条件是依据运行时期值动态决定是否要拼入整体SQL中，对于该问题处理措施是，把对应SQL条件逐一配置在配置文件中，并用对应条件ID标识区分，然后由开发人员在程序中依据用户端传入参数值决定要把哪些条件ID传到数据库访问层，数据访问层关键类依据这些条件ID动态去追加这SQL条件； 问题二对于IN子句支持，开发人员能够在IN子句括号中指定对应变量名，并指明该变量类型，其类型能够是数组、LIST集合对象和逗号间隔String，然后数据库访问层关键类会拆分和计算出IN值个数，并用对应个数”?”替换配置属性变量名。最终，没有直接使用iBatis原因是iBatisSQL配置方法和配置语句相对复杂，且对应辅助JAVA类过于冗长繁琐，和数据库访问层整体处理方案契合度不高。l 支持SQL批量实施前述两个方案结合在一起，处理了问题3认为四个问题，对于问题3中提到SQL批量实施，新数据库访问层CMISDAO中关键类com.yucheng.cmis.pub.dao.SqlClient提供了对应API支持，关键是采取JDBCPreparedStatement对象批处理功效来实现另外，考虑到兼容性，对于之前数据类型KeyedCollection和IndexedCollection，新CMISDAO仍然提供部分支持；对于之前TableModelDAO优点，新CMISDAO仍然继承和发扬，比如对单表面向对象方法存取访问接口仍然提供，只是内部实现方法有所改变。CMISDAO本身在小数据量时（千条之内），对系统性能无显著影响，能将Domain至数据库之间往返映射性能消耗降至最低，另外，因为JVM堆容量限制，提议在批量数据处理时要谨用。3.3.4.2 数据缓存CMISCache用于信贷系统运行时缓存常见业务数据、过程数据和配置数据，以缓解系统在面对复杂业务需求时对数据库压力。缓存机制在信贷系统中已经比较常见，比如，数据字典、组织机构信息等。实际上缓存还能够广泛用于对数据一致性要求不高，但对数据库性能消耗高，或用SQL难以实现复杂业务场景，比如即时消息提醒、数据即时统计、数据展现修饰和深加工等等。CMISCache现阶段关键处理对业务数据缓存使用规范统一问题，集群组员之间缓存同时问题，并提升缓存检索性能，加强使用安全性。未来考虑实现分布式+分级式缓存机制，平衡时间和空间之间矛盾，深入让缓存能提升系统性能，并考虑使用类似XPATH语法模式对缓存检索，让缓存机制能替换部分SQL实现功效，能为复杂业务实现提供更多支持。3.3.4.3 数据权限控制数据统计级权限为菜单级权限补充，用于更细粒度地控制用户对每条统计各类操作权限，不一样是在菜单级权限中动作完全由用户自行定义，而对于统计级权限则仅分为三类动作查询、修改、删除，其分别对应查询权限、修改权限、删除权限。查询权限，用于控制数据统计对目前操作者正确可见性，其作用于展示列表之时。当某数据无权被目前用户看见时，在该用户访问其所在列表时，系统将自动过滤掉无权限数据。注：系统现只在访问列表时进行查询权限，对于单笔数据查看权限，则仅仅使用界面菜单权限进行控制。修改权限，用于控制目前操作者对数据统计修改权，其作用于用户进入修改界面之时，和在提议修改请求之时。当某条数据统计无权被目前用户修改时，系统将在进入修改界面、提议修改请求两个时刻进行拦截。删除权限，用于控制目前操作者对数据统计删除权，其作用于用户提议删除之时。当某条数据统计无权被目前用户删除时，系统将在提议删除请求时进行拦截。 数据统计级权限所保护资源范围是在表模型中所配置表， 其控制依据取决于表中权限归属描述字段（用于描述被约束对象）中值和目前登录者相关信息（如工号、机构码等等）匹配程度，约束对象是信贷系统中用户。在信贷系统中有三类常见约束对象本人、本机构、本机构及下级机构，其和统计级权限一共有七种，以下图所表示：图3-12注：在步骤审批过程中对数据统计权限控制移交给步骤引擎负责,操作查看。在上图中描述了统计级权限控制层次划分，及针对每一张表有三类权限（查询、修改和删除），针对每一类权限又按约束对象细分为若干个具体权限控制点。因为在信贷系统中，被约束对象基础上是确定，而用于描述这些对象权限归属字段字段名基础一至，所以能够考虑针将常见权限控制点制作成标准统计级权限控制模板，用于覆盖绝大部份权限需求，对于少数特殊需求，能够参考现有权限控制模板进行扩展即可。现对每个权限类型下最有可能出现约束对象提供标准统计级权限控制模板，一共提供以下七个：（1） 由查询本人统计权限模板，控制仅能查询属于本人数据（2） 由查询本机构统计权限模板，控制仅能查询属于本机构