|
第【55】天。 摘要： 一个好的核心银行系统，对各商业银行的重要性不言而喻，通常情况下，银行核心业务系统是指银行客户信息、存贷款、会计核算等应用的集合，本文就主要介绍银行核心业务系统应用的架构。 经过多年银行信息化建设的历程，国内各商业银行基本完成了能够满足自身日常经营活动所需要的银行信息化体系建设。但是由于受到各自不同的历史因素的限制，各家行在构建核心银行系统时，都选择了最适合自向特点和发展需要的架构模式。就架构设计模式而言，既有面向SOA的架构，也有面向EAI的集成架构；就系统集成度而言，有大核心系统，也有小核心系统。 1.大核心与小核心 银行的核心系统建设，无论选择哪种架构设计模式，都应当与银行业务发展战略高度契合，结构简洁、清晰、运行灵活、高效，系统维护方便快捷、易于扩展。大核心和小核心系统的出现，是商业银行在不同信息化发展阶段，面对不同业务规模、IT投入资源，权衡不同的功能和非功能需求后做出的不同选择。 大核心系统强调系统集成、安全与高效，除提供银行存贷款结算、客户信息等基础产品和服务外，通常会把与之关联较为紧密的辅助业务功能和管理功能捆绑在一起实现。小核心系统也称为“瘦核心”系统，强调系统松耦合、组件化，通常是指剥离了大部分辅助和管理功能，保留银行存贷款、支付结算等银行基础产品和服务的核心交易处理系统。 大核心相对于小核心系统而言，“大”在应用系统、功能组件之间关联性相对较高，涉及业务功能和业务流程的范围较为广泛。就应用架构设计要素而言，主要是选择的关注对象和侧重点不同。所以，核心系统是大核心还是小核心并不关键，重要的是所选择的架构设计方法和模式，是否契合了各商业银行业务和技术发展的实际需要。 作为银行最重要的业务处理系统，与其他银行业务系统相比较，核心系统架构设计应重点突出稳定和高效。对于变化频繁的业务功能、流程、以及产品和服务，不适合在核心系统中实现，所以在架构设计上，银行核心系统与其他银行应用系统之间，应该是松耦合的架构关系，应该采取多层次、组件化的架构设计原则。 2.联机事务管理 银行核心系统在全天24小时都需要同时面对线上线下大量客户随机发起的交易服务申请，必须时刻保障客户交易及时完成。这意味着银行核心系统是典型的联机事务处理系统（OLTP），需要具备联机交易高并发处理能力，并保障联机交易的原子性、一致性、孤立性和持久性。联机事务处理系统，其基本特征是每一个联机交易服务申请在核心系统中都是以一个事务的方式实时运行，通过对特定银行业务数据的新增、查询、更新处理来完成客户的交易请求。 实现银行核心系统联机事务处理，通常采用两种模式实现。一种是使用业界成熟的中间件产品，或研发统一的联机事务处理框架，由该中间件产品系统协助核心银行完成业务交易处理，使银行核心系统在功能实现过程中无须关注这些与业务逻辑无关的，只与系统运行有关、具有共性的非功能需求。从而在整体上降低核心系统研发难度，提高系统功能的可维护性和扩展性。另一种模式则由核心系统自身实现联机事务处理，在实现业务流程处理的同时，通过编码实现对联机事务的管理。采用第二种模式，其研发和维护过程是复杂和昂贵的，同时也导致银行核心系统的可维护性和可扩展性相对较差。 银行交易的事务原子性是指交易服务申请执行要么完成，要么一点也不做。例如，银行转账处理，从A账号转100元到B账户，原子性操作要求对于账户A和账户B要么全部完成账户更新，要么全部都不更新。 事务的一致性是指交易执行时要保持银行信息系统数据库的内在一致性，即交易执行完毕后，执行结果的数据总是处于用户可预见状态，交易可重现可回滚，数据不被破坏。 事务孤立性是指交易的执行是相互独立的，并发交易之间互不干涉。 事务的持久性是指交易处理结果，将免于系统故障，即一旦交易已经提交，它的结果就被持久保存在存储介质中，并且在系统故障恢复后有方法可以找回。 银行核心系统作为典型的联机事务处理系统，其联机实时交易的处理过程需要支持多用户、多进程，并且支持高完整性的数据共享。根据不同商业银行核心系统实际物理部署情况，核心系统联机事务管理又可以分为本地事务处理和分布式事务处理两种模式。无论采用哪种模式，核心系统都需要具备OLTP系统的相应特性。但是，由于分布式事务处理需要协调完成多台物理机器上的多进程，需要实现联机事务处理会较为复杂，因为，在实现联机事务管理过程中必须考虑当系统发生故障时，故障点可能发生在任何进程中。 3.以客户为中心 国内银行业信息系统在银行信息化建设初期，大多以专业条线为维度构建起银行各专业信息系统，采用的是竖井式应用架构，如下图所示。  由于系统相互割裂，跨专业、跨机构之间信息共享存在壁垒，系统之间信息流转不能畅通无阻。割裂的系统架构，导致各专业系统因业务开办需要，在系统内部分别创建自己的客户信息管理模块，完成客户信息创建、修改、使用等业务处理。客户信息的分散存储和使用，导致银行对外难以实现统一的客户服务，常常造成不同专业条线的客户服务人员多次接触和联系同一客户，反复采集客户信息等。 以客户为中心，意味着需要打破专业和机构间的“壁垒”，通过企业级的客户信息整合，实现全行客户信息统一视图、统一评价，以及跨专业、跨机构的高效联动，进而能够不断推出新的产品，为客户提供全渠道一致性体验，提供更优质的金融服务，如下图所示。  （1）客户信息统一视图 建立客户信息统一视图首先需要构建企业级客户信息管理系统，确保同一客户在银行信息系统中持有逻辑上唯一的客户编码，并实现统一、全面、准确的客户信息视图管理和展现。其次，在此基础上构建侧重于数据统计分析的客户信息分析系统，以提高银行经营管理水平。当完成企业级客户信息系统建设时，银行才真正具备全渠道、全产品、全业务条线一致性服务能力，才真正具备差异化、个性化市场营销服务能力。 由于不同行业领域专业性强、客户需求多样、监管要求各异，与传统商业银行存在较大差别。因此，构建客户信息统一视图时，需要同步建立一套完善的访问权限分层控制机制，实现不同法人机构之间，以及同一机构不同专业领域之间客户信息的隐私保护。 （2）客户统一评价 建立以资产、负债、中间业务等指标为主体的综合评价体系。并依托客户统一评价，将客户在银行中的各类业务交易信息进行提炼与整合，形成可以反映客户全貌的客户统一视图。 客户统一评价按照客户信息“统一采集标准、统一采集路径、统一评价计量方法”构建，形成一个跨专业、跨渠道、跨产品、全流程，动态反映客户实际情况，层次清晰、互相配合的综合评价体系，如下图所示。  客户统一评价体系的建立，将使得客户在银行不同机构不同专业的评价标准得到统一，可以更加准确地获取客户对银行实际贡献情况，有利于建立以客户为中心的营销和销售体系，促进机构、部门间信息共享与联动营销，提升客户满意度，有利于各级营销人员通过统一评价结果挖掘客户价值、提高产品渗透率，提高营销成功率和收益率。 4.独立设计的会计核算系统 银行核算职能是指对银行经营活动的表述和价值数量上的确定，以货币为主要计量单位，对银行一定时期的经济活动进行真实、准确、完整和及时的记录、计算和报告，为管理经济活动提供所需的会计信息。核算系统的处理逻辑依托于会计准则，对于一个会计准则适用范围内的核算处理规则相同。而产品是银行为客户提供镥科比讨论的载体，产品系统的处理规则会因为不同的服务要求存在较大的差异，所以银行会计核算与银行产品服务，虽然存在关联性，但在业务架构中属于银行不同业务领域。 由于银行会计核算功能相对稳定，而产品服务需要面对日益激烈的市场竞争，产品创新步伐快，产品变化频繁，因此，会计核算与产品系统在架构上应尽可能松耦合。两者之间适合采用分层架构设计思想，将银行不同产品系统中，具有系统处理共性的会计核算功能剥离出来，在银行核心系统中建立一个相对独立、统一、集中、标准、共用的核算平台，作为银行对外服务的后台基础业务系统，支持灵活和多层次的会计核算服务。 5.分层设计的核心交易公共服务 介质是客户获取银行服务的媒介，它是客户访问标识的载体，任何客户要与银行打交道时，必须首先向银行提供他的访问标识，银行通过对访问标识及相关认证信息的鉴定，确定来者谁，能替他提供什么的服务。介质包括实物介质（卡、存折、存单等）和虚拟介质（虚拟卡、登陆ID等）。 协议包括产品协议和客户服务协议， 这里指的是产品协议。产品协议是产品的实例，明确其中一方自另一方取得产品使用权。一个产品可以对应零到多个产品协议，一个产品协议可以对应一个产品。 账户是用于监控货币及非货币数量变化的存储分类，代表经济业务发生后引起资金或非资金运动数量的变化。 介持、协议、账户三者分离，将降低应用系统耦合度，使业务逻辑更加清晰，核心系统采用分层设计，建立介质层、协议层和账户层分别抽取形成介质、协议、账户公共服务。在介质、协议未分离的情况下，介质与协议关系固定，限制某些与介协相关的产品创新业务功能的实现，分离后，介质与协议之间松耦合，可以根据业务创新需要，实现一对多、多对一和多对多灵活的介协关系。介质、协议分离后，在介质层可以建立介质权限统一视图管理，实现对银行介质服务权限和客户个性权限的统一管理模式。 说明： （1）文中的配图大多来自互联网上授权图片提供商，并已获得免费使用授权，如果文中内容或是图片侵犯到您的权益，请及时告诉我。 （2）由于时间有限，每天只利用业余时间来学习和总结相关内容，所以有些主题可能要两到三天才能描述完成，请你持续关注本公众号，还有文中难免会出现各种错误，恳请您的批评和指正。 |
|
|
