银行新核心基础架构方案设计技术手册——规划篇&实施篇
本文是社区专家编写的《银行新核心基础架构方案设计技术手册》中的“规划篇”和“实施篇”部分。该手册适合银行从事IT建设的架构师、工程师以及主导核心系统基础架构及应用系统建设或者改造项目的项目经理等人群，可以帮助大家对项目或者技术选型及定位有一些相对比较清晰的认识，从而指导其相关的技术工作。前文“分析篇”请点击《银行新核心基础架构方案设计技术手册——分析篇》。
1、银行核心系统去耦设计
1.1 业务模块的逻辑拆分
业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。
今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离，更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。
接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对接各种业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为业务服务瓶颈，它的处理只影响银行后台会计事务，属于内部业务。
第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂，可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。多法人支持，在数据库底层设计中引入法人字段，做到数据隔离。
1.2 应用模块的分布式部署
传统的核心系统，无论是联机应用还是批量应用基本的部署方式还是物理机的独立格局部署方式，从其他系统的业务请求到核心系统内部请求的处理基本都属于独立格局，这个流程涉及到的请求、调用、处理等事务基本都属于固定模式，没有任何动态分配算法来支撑。我们在核心系统去耦工程当中，非常重要的一个事情就是要解决这种独立部署的格局。首先就是要解决核心系统联机应用的负载均衡支持问题。有些核心系统的设计已经采取了分布式架构，利用一些分布式中间件以及缓存的中间件来实现联机业务请求的分布式部署。这是一种趋势，无论是用Tuxedo软件负载，还是利用F5硬件负载，都应该实现应用层面的负载均衡部署。当然支撑这种部署方式的前提是应用层面必须具备对业务处理逻辑的校验，无论是会话策略还是链接策略，都因该具备交易处理的逻辑校验功能，以支撑核心系统业务处理的分布式架构。
1.3 基础架构的逻辑解耦
核心系统的基础架构主要是指支撑核心系统应用以及核心系统数据库的平台架构，既包括计算资源的集成又包括存储资源的集成。如果采用大型机、中型机、小型机的架构势必会导致核心系统本身的灵活性受限。如果采用通用X86分布式的架构又会担心其处理能受限导致系统整体的稳定性和高可用性受限。
因此在核心系统基础架构的选型过程中既要考虑到单个物理资源的处理能力受限问题，又要考虑到单个物理资源对整体核心系统群的扩展性和灵活性受限的问题。因此在当前环境下，应该结合二者之优势来设计整体核心系统整体。单个物理资源的选型我们要考虑到其足够的处理能力，横向的资源扩展我们要考虑到资源的横向组合性，足够适应虚拟化技术、资源池技术带给我们的资源整合优势。数据库的选型我们要充分注重其纵向的处理能力，应用服务器的选型我们要充分注重其横向的扩展能力。
2、资源池化方法
2.1 应用和资源的映射关系分析
说到应用和资源的映射关系，其实就是什么类型的应用需要什么类型的资源去支撑。比如说有些应用是计算秘密性应用，有些应用是内存密集性应用，还有一些应用是存储密集性应用。但是对于资源实体，也就是我们的服务器或者是存储设备来讲，是无法实现特定应用类型的资源配比，因此一定会造成某一方面或者某几方面的资源浪费而某一方面的资源紧缺。因此，在核心系统各种资源池化的整体思路框架之下，首先是要分析出核心系统各个业务模块，各个层面对资源的需求状况究竟是什么样的。例如，可能联机交易业务的处理更多的是内存资源的耗用，而批量业务的处理更多的是CPU资源的耗用。数据库内的数据处理更多的是IO和内存资源的耗用。只有前期对于核心系统各个模块儿的资源耗用特点有一个清晰的把我，那么才能支撑我们后期对资源池的划分和虚拟资源的设计。
2.2 虚拟化方案的设计
多为虚拟化方案的设计，主要是指对虚拟化解决方案的选型以及具体虚拟化设计方案的规划。对于虚拟化解决方案的选型主要依赖于我们所选硬件的兼容性要求，例如X86服务器的虚拟化解决方案相对宽松，而Power架构服务器的虚拟化解决方案相对比较狭隘。所以今天的客户更多是选择了基于X86架构的服务器资源。
当我们选定了支撑我们虚拟化方案的硬件资源之后，那么就是对具体虚拟化设计方案的规划。主要涉及以下几个方面的详细规划设计：
一、各个资源池的设计
无论是什么样的资源池化技术，一个共通的功能特性就是可以实现CPU、内存、网络、存储等资源的共享技术。用哪些物理资源去组织成为那些可用的资源池就是我们这一个步骤需要考虑的问题。对于应用服务器资源来讲，彼此产生冲突的是CPU和内存资源，需要建立统一的CPU和内存资源池。对于数据库服务器来讲，除了内存资源的冲突之外，更多的是存储资源的冲突，因此需要建立统一的存储资源池。
二、虚拟服务器对资源的分配策略
由于不同的应用对不同资源的获取和访问具有不同的属性特点以及不同的重要程度之分，因此我们在对不同虚拟服务器的资源分配上需要建立不同的动态分配以及优先级策略分配模型。比如，在数据库服务器和应用服务器的资源竞争策略当中，那么数据库服务器的内存优先级一定高于其他服务器；在联机应用服务器和批量应用服务器的资源竞争当中，一定会有时间段的区分，设计争夺策略的时候需要充分考虑到时间段的分布；数据库服务器和其他服务器存储资源的使用和竞争过程当中，一定会有IOPS和高可用的区分，在具体的分配策略当中我们需要充分考虑到这一点的区别。
三、资源的动态优化策略
所谓资源的动态优化策略是指在不同的时间区分以及不同的业务场合下，资源的分配是否可以根据实际情况进行变化以及如何变化，再有就是资源产生冲突的场合下，可用资源应该如何分配。成熟的资源池虚拟化技术可以通过资源的优先级、资源的分配粒度、资源的共享以及回收策略来实现资源在不同时间和空间下的平滑迁移。但是前期条件是我们需要根据应用的不同特点来设计合理的资源动态调配策略，其主要涉及以下几个方面：
1、虚拟资源和物理资源的分配粒度，保障物理资源得到足够细粒度的分配。
2、虚拟资源的动态分配优先级，根据业务优先级来保障资源的分配优先级。
3、虚拟资源的预留及限制规则，根据预留规则，限制规则来保障在极端场合下对重要业务的保障。
3、基础架构扩展性方法
3.1 前提条件
核心系统的基础架构是否可以实现灵活的扩展性决定于应用系统本身的模块儿化设计是否合理，主要表现为以下几个方面：
1）联机交易是否可以实现跨机处理，也就是联机业务不同业务逻辑是否可以根据交易当中的某些属性实现物理层面的跨机处理，逻辑层面的业务统一性。
2）缓存数据在整个交易过程的一致性保持，通过缓存中间件、消息中间件等机制实现交易临时数据的一致性保持。联机处理业务当中，每一笔交易实际经理的交易逻辑过程可能会比较多，但是如何在分布式处理过程当中区别某一个交易就需要某些会话属性的临时数据在交易过程中的持久性。
3）尽可能的数据分离，对于传统的核心系统来讲，业务上没有太多的区分导致底层数据库当中的数据区分度不是非常合理，尤其在并发较高的场合下，底层数据的热点竞争非常激烈。
如果我们要实现基础架构的灵活扩展性，那么从业务上需要将底层数据尽量重新设计实现良好的分离性。
3.2 应用层的扩展性设计
应用层的扩展性设计主要取决于以下几个个方面：
首先、从整体架构设计上需要有负载分发层来实现业务请求的分布式分发，无论是用F5硬件还是用Tuxedo等实现的软件层面的负载均衡，总之在核心系统应用层之前需要一个负载均衡层来实现整体架构的灵活扩展性。只有负载均衡层作为业务请求的接口才能实现应用服务器的灵活增加或者减少。
其次、将业务交易状态进行分布式缓存。对于存粹的互联网应用来讲，多数是无需保持其业务状态的，但是对于金融行业的交易业务来讲，大部分是需要保持及交易状态信息的，也就是说在整个复杂的交易流程当中，其交易状态是需要保存下来的。如果要实现整体架构的扩展性，那么就必须有相应的状态数据缓存层来支撑其他部件的灵活扩展性。
再有、应用节点的选择要实现虚拟化。用虚拟化之后的规模效应以及其灵活快速交付性来实现应用层的足够扩展性。这个其实并不难理解，如果还是延续传统的物理格局方式，那么即使有前端的负载均衡层以及分布式缓存或者队列，也很难实现架构的灵活扩展性，瓶颈在于其交付和部署的耗时。
3.3 数据层的扩展性设计
对于核心系统的数据层来讲，主要是指数据库。对于传统的胖核心的架构来讲，其数据库多属于重量级数据库，借贷数据归属于同一个数据整体。它对数据库实例的要求更多的是偏向于服务器纵向处理能力的依赖，横向的扩展性基本上不具备，横向的高可用可能更多的是HA的模式，高可用能力非常有限。
1.如果在核心系统应用架构能够拆分，业务可以重新进行分析重组的前提条件之下，那么数据的访问也是可以重新再作切分，比如说联机和会计总账数据的适当切分，借贷数据的切分等。
2.由于银行的核心交易数据都是二维表结构化数据，最适合其处理的也是关系型数据库，我们不能将架构的扩展性寄希望于某些NOSQL分部式数据库的引入，这个不合理也不科学。在既有的关系型数据基础之上，我们要想提高数据库层面的架构扩展性只能通过分库分表的方式来降低数据的热点问题，从而将不同的业务访问分担到不同的数据库实例上，从而实现数据库架构的整体扩展性部署。
3.由于银行的核心交易数据都是二维表结构化数据，最适合其处理的也是关系型数据库，我们不能将架构的扩展性寄希望于某些NOSQL分部式数据库的引入，这个不合理也不科学。在既有的关系型数据基础之上，我们要想提高数据库层面的架构扩展性只能通过分库分表的方式来降低数据的热点问题，从而将不同的业务访问分担到不同的数据库实例上，从而实现数据库架构的整体扩展性部署。
4、互联网模式发展方法
4.1 定位互联网模式的位置
核心系统越来越复杂，尤其是传统的核心账务系统，也经历胖核心，瘦核心之变。当下微服务也在流行，未来十年，银行整体架构演变趋势如何？银行如何转型以适应互联网化的快速变化？
应该说互联网的发展对银行的业务模式和渠道模式起到了很大的推动作用，特别是随着互联网用户监管标准的变化，应该说有很大一部分业务来自于互联网模式。但是这个并不代表互联网核心会主导银行传统业务。对于大部分银行来讲还是辐射本地，有其固有的客户群体和固有的业务模式，更重要的是银行业的交易业务的账务规则和业务标准是不会随着互联网进行完全式的革命。所以传统的核心可能会随着时代的发展存在一些问题，但是并不代表传统核心系统会消失。无论怎么发展，互联网业务是属于渠道，我们不能做喧宾夺主的事情。
4.2 互联网模式发展思路
传统银行核心系统的生命周期往往在10年左右，甚至更久。一些新兴的企业进入到这个领域，特别是互联网金融企业，快速推出新产品，蚕食银行的中间业务，这也提出来一个问题，我们的后台是否有一个灵活的架构支撑这一需求。银行后台API化，服务化，把它暴露出来，这是一个关键的能力，表现就是业务敏捷化。这里也对核心的选择提出了三个选择点：
1.单核，构建新型的单核系统。
2.双核，保留传统核心，构建一个独立的新核心，以满足新兴的需求。
3.无核，没有绝对的核心，每个模块各司其职，组件化配置。
但是不管银行选择单核，双核，无核哪种形态，都需要将目标和自身的情况联系起来，需要更细心的分析和摸索，不能一蹴而就，也没有绝对选项。对于银行而言，在构建新一代核心系统的时候，需要有更多的考量：简单的说：看大做小，要看到未来业务需求对于核心系统提出的要求，也就是对核心系统提出的要求，比如技术发展趋势，业务发展模式等等，但是也需要结合银行自身的情况，自己已有的IT资产情况，IT服务和运维能力等等来实践，就是要将梦想照进现实。
1、银行核心系统存储解决方案
针对核心业务系统存在问题，以下以基于IBM ICM构建IAAS云管理平台的解决方案为例：通过统一管理和调度异构的IT基础设施，来支持复杂多变的业务需求；此外，基于自助服务的资源预约、资源分配、应用自动部署以及工作在共享资源池上的智能调度和实时动态调整。
如下图所示是基础设施层上的解决方案概要设计图。
这个图是IBM云平台SDE上对应的一个软件栈。从下往上看的话，
底层是物理资源，包括服务器、存储和网络。
IBM管理基础设施的软件主要有：PCM，管理baremetal，帮助用户对逻辑进行部署。PowerVC和zKVM提供虚拟化服务，GPFS提供弹性存储服务。
云平台主要是通过ICM来进行管理。
最上层的负载管理通过LSF平台进行。
该解决方案中，IBMPlatformLSF平台集群可以分成两组主机，分别是管理主机和计算主机。管理主机为集群提供专业化的服务，计算主机运行用户的工作量。
ICM通过易用管理平台为IT管理人员提供智能管理系统的入口。
如上图所示，传统阵列存在性能瓶颈，IOPS达到瓶颈，FlashSystemV9000包含一个SVC可以帮助解决Oracle数据库用户面临的性能挑战，通过将读数据存放在低延迟的全闪存阵列上，读操作会被更快的处理，从而带来性能的极具提升。利用SVC的VDM功能，实现关键数据的优先读，确保性能加速；同时镜像双份保存到两台物理存储，保证任一存储设备出现突发状况，始终有一台存储可以保持正常读写；日常维护中，可以保证在微码升级的场景下，有冗余的可用在线数据；存储池技术和在线迁移技术配合，可以实现新旧设备的便捷更替，对服务器透明，对OS透明，对业务透明。
对存储的增强，提供一个开放、可扩展、企业级的存储平台，对存储的改进主要是加入了对IBMGPFS的支持，用户可以通过IBM存储提供块存储服务和对象存储服务。块存储的话主要是虚拟机创建完之后，可以从IBM存储申请一块存储，作为虚拟机的一个块设备。对象存储的话，就是用户可以把一些需要备份的文件通过IBM云平台存放在IBM存储中。
这样设计的优势所在：
统一管理所有的异构资源，包括x86和power
通过云平台来帮助用户部署管理应用，同时还可以通过云平台实现应用的高可用。
存储虚拟化：支持超过90%以上异构存储厂商，有效保护用户投资。
实时压缩：2倍的在线可用空间，存放更多的数据，提高数据的密度
数据分层：提升数据性能，3倍的性能需求
精简配置：空间回收，只需要购买实际的使用空间，大量节省预留空间的花费
数据快照：无需额外空间开销
数据容灾：支持以太网，支持直连
在线数据迁移：停机时间最短，10分钟
设备利旧：充分利用旧设备
存储级别数据备份
2、银行核心系统数据库解决方案
2.1 架构规划设计原则
一、设计要素需要考虑以下问题：
1、不同RAC集群节点间的心跳交互数据流量会叠加；
2、主机CPU、内存的资源较其他分区消耗更大
3、对不同业务类型分区在同一台物理机上的分布，导致对存储IOPS和吞吐量要求大大提高，同一存储路径难以同时满足两种需求。
二、设计原则上要满足以下需求：
1、在Power虚拟化环境中部署Oracle数据库，建议要充分考虑生产、心跳网络带宽需求，尽可能采用万兆网络，做好冗余，避免网络带宽不足或高可用性不足；
2、要预估存储IO的类型及量的大小，根据不同存储访问类型，设计更多的存储路径满足需求，将vscsi与npiv的物理HBA卡分开，并为npiv保留更多的通道，增加冗余，减少拥堵，满足各业务分区对IOPS或者吞吐量的不同需求；
3、将不同业务特性的分区进行分布、搭配，如应用分区与数据库分区搭配，OLTP业务与OLAP业务搭配，重要系统与非重要系统搭配，形成错峰资源使用，平衡利用单台物理机的资源。
2.2 数据库性能影响
首先影响肯定是有的，具体的主要是网络、存储IO、CPU三个方面，因为虚拟化的平台，主要就是为了提高资源的利用率，需要用到资源共享，所以就较难以做到资源的独享分配。有些虚拟化平台可以直接接入存储，有些则不行，Power虚拟化就可以将存储通过NPIV方式直接分配给VIOC，在虚拟化环境中可以提高存储IO性能。
数据库一向是网站架构中最具挑战性的，瓶颈通常出现在这里。数据库是一个对IO高度敏感的软件，在架构设计中是考虑的重点，而虚拟化环境的IO性能又一直是一个瓶颈。所以虚拟化环境能否满足需要运行Oracle数据库需求，首先看产品的指标，如果指标满足要求，再进行压力测试，如果压力测试验证，确实能够满足要求，就放心的去用，否则不要随便改变环境。如果是像数据仓库类的，建议不要放在虚拟化环境中，其他交易类的系统根据业务情况，结合测试验证情况，可以考虑放在虚拟化环境中。
当前，按照文中的设计原则，Oracle数据库环境在由传统物理机方式改造迁移至Power虚拟化环境后，由于基础网络环境配置的优化，基本消除了由于心跳网络时延、拥堵等造成的节点宕机情况，RAC集群稳定性较传统物理机方式大大提高。存储的IO尽可能的进行了流量分类、分散，也未发现有IO瓶颈的存在。对于虚拟化环境运行好坏与否，关键在于监控是否到位，管理是否尽职尽责。
2.3 Power虚拟化架构设计要点
对硬件选型的建议，尽量选择高型号的主机，尽可能高配，硬件冗余性、稳定性相对会好些。在进行硬件选型时，我们有几点基本的准则需要知道。这些准则都是基于特定的元素的，比如CPU性能、I/O以及平均数据吞吐量等。然而，首先需要考虑的是我们的操作系统是什么，以及是否需要用到虚拟化技术。
举个例子，虚拟化服务器环境对高性能和多核CPU的反馈良好。需要高性能I/O的Oracle产品，更适合能够运行多线程的系统，这样的系统需要有64比特数据通路和高速互联。这些高速互联包含了针对SAN(存储域网络)的光线通道、高速通讯10GB以太网以及一个针对智能机架系统的高性能面板。
当然，进行硬件选择的时候，我们不应该仅仅考虑到服务器性能这一点。实用性、集成、扩展以及管理等因素对于Oracle环境来说都是非常重要。这些因素决定了最终的投资回报率(ROI)和总拥有成本(TCO)，这些都会影响一个企业的整体预算情况。那些易于升级的产品经过长时间的证明，往往会拥有更低的TCO并能增加投资回报率。当为Oracle环境选择硬件的时候，遵循上文的提到的原则将会对您有所帮助。这些原则并不仅仅针对性能方面，更重要的是成本考虑、利用率、预计增长以及硬件的生命周期。
2.4 同时满足IOPS和吞吐量
需要结合不同的业务类型、存储服务级别，配置更多的存储路径，将不同业务类型的数据流量分配到不同的存储路径。如将vscsi方式与npiv方式分离，并为npiv保留更多的通道，在满足不同业务类型的同时，还能避免单个路径流量过大，将不同数据流量分布在不同的存储路径中，保证数据库对存储的访问性能，避免出现路径流量拥堵的情况。
设计更多的存储路径满足需求，将vscsi与npiv的物理HBA卡分开，并为npiv保留更多的通道，增加冗余，减少拥堵，满足各业务分区对IOPS或者吞吐量的不同需求；将不同业务特性的分区进行分布、搭配，如应用分区与数据库分区搭配，OLTP业务与OLAP业务搭配，重要系统与非重要系统搭配，形成错峰资源使用，平衡存储IO的压力。现在一般存储都支持开启QoS，当然前提是存储本身的性能足够，也可以在存储层面做好优先保障。
2.5 数据库集群的心跳网络设计
一、硬件及参数
从Oracle官方的推荐来看，他们首先推荐使用万兆以太网，至少使用千兆以太网，负载如果很高那么私网可以采用infiniband。当然这个完全取决于客户生产环境的具体业务量及负载情况。这个仅仅是个参考，有条件的情况下可以按照推荐进行配置。私网的连接需要使用交换机，Oracle集群安装并不支持私网的直连架构。网卡及交换机的双攻击速率参数保持正确一致。
二、网卡绑定
各种平台都有自己的网卡绑定工具，而且提供负载均衡和主备模式的绑定。首先为了提高公网和私网的网络高可用，网卡需要绑定。对于Linux平台我们需要在配置文件“/etc/modprobe.d/dist.conf”中将数mode来控制网卡绑定的具体策略：mod=0，即：(balance-rr)Round-robinpolicy（平衡抡循环策略）。mod=1，即：(active-backup)Active-backuppolicy（主-备份策略）。mod=2，即：(balance-xor)XORpolicy（平衡策略）。mod=3，即：broadcast（广播策略）。
mod=4，即：IEEE802.3adDynamiclinkaggregation。mod=5，即：(balance-tlb)Adaptivetransmitloadbalancing。
mod=6，即：(balance-alb)Adaptiveloadbalancing（适配器适应性负载均衡）。对于私网网卡绑定方式mode=3&6会导致ORA-600，公网网卡绑定方式mode=6会导致BUG9081436。对于具体的绑定模式，对于平台版本低而且网络架构非常复杂的场合，还是建议主备模式，因为主备模式更稳定，不容易产生数据包路径不一致的问题。如果是负载均衡模式的场合，如果网络参数设置不是很科学的情况下，很容易出现从一个物理网卡发送报文，但是回报文却回到另外一个物理网卡上，网络链路再加入防火墙的规则之后，非常容易导致丢包问题发生。
而对于AIX平台来讲，将参数mode修改为NIB或者Standard值。Standard是根据目标IP地址来决定用哪个物理网卡来发送报文，是基于IP地址的负载均衡，也不易产生上述的丢包问题。
三、SCANIP
OracleRAC，从11gr2之后增加了SCAN（SingleClientAccessName）的特性。SCAN是一个域名，可以解析至少1个IP，最多解析3个SCANIP，客户端可以通过这个SCAN名字来访问数据库，另外SCANip必须与publicip和VIP在一个子网。启用SCAN之后，会在数据库与客户端之间，添加了一层虚拟的服务层，就是SCANIP和SCANIPListener，在客户端仅需要配置SCANIP的tns信息，通过SCANIPListener，连接后台集群数据库。这样，不论集群数据库是否有添加或者删除节点的操作，均不会对客户端产生影响，也就不需要修改配置。对于SCAN相关的配置，有以下一些配置注意事项：
（1）主机的默认网关必须与SCAN以及VIP在同一个子网上。
（2）建议通过DNS，按round-robin方式将SCAN名称（11gR2和更高版本）至少解析为3个IP地址，无论集群大小如何。
（3）为避免名称解析出现问题，假设我们设置了三个SCAN地址，那么HOSTs文件当中不能出现SAN的记录，因为HOSTs文件当中的记录是静态解析，与DNS动态解析相悖。
四、网络参数
操作系统平台上关于网络的内核参数非常重要，直接决定私网公网数据传输的稳定性和性能。不过针对不同的操作系统，相关的参数设置也各有差异。
1、Linux。对于Linux平台的内核参数，有两个非常重要（net.core.rmem_default、net.core.rmem_max）。具体功能解释如下：
net.ipv4.conf.eth#.rp_filter：数据包反向过滤技术。net.ipv4.ip_local_port_range：表示应用程序可使用的IPv4端口范围。net.core.rmem_default：表示套接字接收缓冲区大小的缺省值。net.core.rmem_max：表示套接字接收缓冲区大小的最大值。net.core.wmem_default：表示套接字发送缓冲区大小的缺省值。net.core.wmem_max：表示套接字发送缓冲区大小的最大值。
为了获得更好的网络性能，我们需要根据具体情况把以上两个参数从其默认值适当调整为原来的2-3倍甚至更高，关闭或者设置反向过滤功能为禁用0或者宽松模式2。
2、AIX。对于AIX平台的内核参数，以下设置是从Oracle官方文档摘出的最佳配置：tcp_recvspace=65536；tcp_sendspace=65536；udp_sendspace=((db_block_size*db_multiblock_read_count)+4096)；udp_recvspace=655360；
rfc1323=1；sb_max=4194304；ipqmaxlen=512；第1、2个参数表示TCP窗口大小，第3、4个参数表示UDP窗口大小。rfc1323启用由RFC1323（TCP扩展以得到高性能）指定的窗口定标和时间图标。窗口定标允许TCP窗口大小（tcp_recvspace和tcp_sendspace）大于64KB（65536）并且通常用于大的MTU网络。默认为0(关)，如果试图将tcp_sendspace和tcp_recvspace设为大于64KB则需要先修改此值为1。ipqmaxlen表示指定接收包的数目，这些包可以列在IP协议输入队列中。sb_max指定一个TCP和UDP套接字允许的最大缓冲区大小。
2.6 虚拟化与物理机混合部署
物理机和虚拟机结合的思路很好，对于重要系统，第一次准备上到虚拟化，总是有很大的担心，这可以是一个逐步适应的过程，根据实际运行情况，慢慢转向虚拟化。某行经验：在进行虚拟化迁移改造过程中，对于Oracle数据库集群的迁移，采用的方案就是“虚实结合”，先将其中一个物理节点迁移改造成虚拟化节点，稳定运行1至2周后，再将另一个物理节点迁移改造至虚拟化节点；绝大部分的Oracle数据库目前都运行在Power虚拟化资源池中，与传统使用物理机环境相比较，从标准统一性、资源利用率、维护工作量等都有更多的改善，对于虚拟化环境运行Oracle数据库的管理、运维等方面也都在逐步提升。从目前运行情况来看，可靠性和性能上暂时还没有出现过大问题，如果在虚拟化环境运行数据库，建议对物理CPU、内存资源池保留一定的余量，防止系统突发性能需要在线扩展相关资源。
（“规划篇&实施篇”完）
核心系统的变迁代表着银行业整体信息技术体系的发展，近年来，有一些银行大胆前行探索并且初见成果，但是并没有形成一套完整的方法论和体系，很多难点问题一直在困扰着银行科技人。
为此，社区组织“中小银行新一代核心银行系统基础架构方案设计线上答疑”，希望所有银行科技人共聚一堂，探索过的可以把经历经验分享给大家，没有探索过的可以把自己的想法和担心抛出来，让这个活动能帮助所有银行科技人明确前行的路，把握好发展的方向。
点击文末阅读原文，或复制以下地址到浏览器即可到活动页面：
http://www.talkwithtrend.com/activity/?id=1337
也可通过twt社区APP参与。
您可以先留言或提问，并在明天参加集中交流。
到“中小银行新一代核心银行系统基础架构方案设计线上答疑”活动页面可下载完整《银行新核心基础架构方案设计技术手册》。
该手册从分析角度、规划角度以及设计实施角度来诠释银行的核心交易系统建设所需注意的一些细节问题。从基础架构的现状、发展历程以及在当今互联网普及的这个环境下金融行业的核心交易系统面临的问题：系统敏捷性的问题、架构扩展性的问题、架构耦合性的问题等等。
手册采用了多位专家在社区发表的优秀文章及观点。对于每一个问题，不同的专家从不同的角度都做了详细的诠释，包括对问题的看法以及解决问题的思路等等。在规划篇当中，分别对系统建设的过程中涉及到的业务层、应用层以及基础架构层等各个方面进行了详细的方法论介绍。在设计实施篇中分别对银行核心系统的存储层和数据库层的关键技术和实施点进行了案例性的讲解。希望通过各个层面的诠释能给读者对银行核心交易系统的建设带来一个详细完整的解释，为大家提供具有价值的参考。
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”