银行新核心基础架构规划及实施方案.docxVIP

银行新核心基础架构规划及实施方案 1银行核心系统去耦设计 1.1业务模块的逻辑拆分 业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。 今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离，更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。 接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对接各种业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为业务服务瓶颈，它的处理只影响银行后台会计事务，属于内部业务。 第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂，可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。多法人支持，在数据库底层设计中引入法人字段，做到数据隔离。 1.2应用模块的分布式部署 传统的核心系统，无论是联机应用还是批量应用基本的部署方式还是物理机的独立格局部署方式，从其他系统的业务请求到核心系统内部请求的处理基本都属于独立格局，这个流程涉及到的请求、调用、处理等事务基本都属于固定模式，没有任何动态分配算法来支撑。我们在核心系统去耦工程当中，非常重要的一个事情就是要解决这种独立部署的格局。首先就是要解决核心系统联机应用的负载均衡支持问题。有些核心系统的设计已经采取了分布式架构，利用一些分布式中间件以及缓存的中间件来实现联机业务请求的分布式部署。这是一种趋势，无论是用Tuxedo软件负载，还是利用F5硬件负载，都应该实现应用层面的负载均衡部署。当然支撑这种部署方式的前提是应用层面必须具备对业务处理逻辑的校验，无论是会话策略还是链接策略，都因该具备交易处理的逻辑校验功能，以支撑核心系统业务处理的分布式架构。 1.3基础架构的逻辑解耦 核心系统的基础架构主要是指支撑核心系统应用以及核心系统数据库的平台架构，既包括计算资源的集成又包括存储资源的集成。如果采用大型机、中型机、小型机的架构势必会导致核心系统本身的灵活性受限。如果采用通用X86分布式的架构又会担心其处理能受限导致系统整体的稳定性和高可用性受限。 因此在核心系统基础架构的选型过程中既要考虑到单个物理资源的处理能力受限问题，又要考虑到单个物理资源对整体核心系统群的扩展性和灵活性受限的问题。因此在当前环境下，应该结合二者之优势来设计整体核心系统整体。单个物理资源的选型我们要考虑到其足够的处理能力，横向的资源扩展我们要考虑到资源的横向组合性，足够适应虚拟化技术、资源池技术带给我们的资源整合优势。数据库的选型我们要充分注重其纵向的处理能力，应用服务器的选型我们要充分注重其横向的扩展能力。 2资源池化方法 2.1应用和资源的映射关系分析 说到应用和资源的映射关系，其实就是什么类型的应用需要什么类型的资源去支撑。比如说有些应用是计算秘密性应用，有些应用是内存密集性应用，还有一些应用是存储密集性应用。但是对于资源实体，也就是我们的服务器或者是存储设备来讲，是无法实现特定应用类型的资源配比，因此一定会造成某一方面或者某几方面的资源浪费而某一方面的资源紧缺。因此，在核心系统各种资源池化的整体思路框架之下，首先是要分析出核心系统各个业务模块，各个层面对资源的需求状况究竟是什么样的。例如，可能联机交易业务的处理更多的是内存资源的耗用，而批量业务的处理更多的是CPU资源的耗用。数据库内的数据处理更多的是IO和内存资源的耗用。只有前期对于核心系统各个模块儿的资源耗用特点有一个清晰的把我，那么才能支撑我们后期对资源池的划分和虚拟资源的设计。 2.2虚拟化方案的设计 多为虚拟化方案的设计，主要是指对虚拟化解决方案的选型以及