银行新核心基础架构方案设计技术手册

1、银行新核心基础架构方案设计技术手册目 录分析篇4银行核心基础架构的现状4银行核心基础架构面临问题5耦合性问题5资源格局限制5扩展性短板6数据安全局限性6银行核心基础架构重构必要性6三步走战略分析7面对 FinTech 时代的机遇与挑战7集中式与分布式9微服务与巨石10银行核心基础架构重构难点分析11交易和核算的分离问题11系统去耦问题11思维转型12思维转型13规划篇13 HYPERLINK l _TOC_250024 银行核心系统去耦设计13 HYPERLINK l _TOC_250023 业务模块的逻辑拆分13 HYPERLINK l _TOC_250022 应用模块的分布式部署14 HY

2、PERLINK l _TOC_250021 基础架构的逻辑解耦14 HYPERLINK l _TOC_250020 资源池化方法14 HYPERLINK l _TOC_250019 应用和资源的映射关系分析15 HYPERLINK l _TOC_250018 虚拟化方案的设计15一、各个资源池的设计15二、虚拟服务器对资源的分配策略15三、资源的动态优化策略15 HYPERLINK l _TOC_250017 基础架构扩展性方法16 HYPERLINK l _TOC_250016 前提条件16 HYPERLINK l _TOC_250015 应用层的扩展性设计16 HYPERLINK l _T

3、OC_250014 数据层的扩展性设计16 HYPERLINK l _TOC_250013 互联网模式发展方法17 HYPERLINK l _TOC_250012 定位互联网模式的位置17 HYPERLINK l _TOC_250011 互联网模式发展思路17 HYPERLINK l _TOC_250010 设计实施篇18 HYPERLINK l _TOC_250009 银行核心系统存储解决方案18 HYPERLINK l _TOC_250008 银行核心系统数据库解决方案19 HYPERLINK l _TOC_250007 架构规划设计原则19 HYPERLINK l _TOC_250006

4、 数据库性能影响20 HYPERLINK l _TOC_250005 Power 虚拟化架构设计要点20 HYPERLINK l _TOC_250004 同时满足 IOPS 和吞吐量21 HYPERLINK l _TOC_250003 数据库集群的心跳网络设计21 HYPERLINK l _TOC_250002 一、硬件及参数21 HYPERLINK l _TOC_250001 二、网卡绑定21三、SCAN IP22四、网络参数22 HYPERLINK l _TOC_250000 虚拟化与物理机混合部署23文档介绍目标人群本文章适合银行从事 IT 建设的架构师、工程师以及主导核心系统基础架构及

5、应用系统建设或者改造项目的项目经理等人群，可以帮助大家对项目或者技术选型及定位有一些相对 比较清晰的认识，从而指导其相关的技术工作。写作目标本文从分析角度、规划角度以及设计实施角度来诠释银行的核心交易系统建设所需注意 的一些细节问题。从基础架构的现状、发展历程以及在当今互联网普及的这个环境下金融行 业的核心交易系统面临的问题：系统敏捷性的问题、架构扩展性的问题、架构耦合性的问题 等等。对于每一个问题，不同的专家从不同的角度都做了详细的诠释，包括对问题的看法以 及解决问题的思路等等。在规划篇当中，分别对系统建设的过程中涉及到的业务层、应用层 以及基础架构层等各个方面进行了详细的方法论介绍。在设计

6、实施篇中分别对银行核心系统 的存储层和数据库层的关键技术和实施点进行了案例性的讲解。希望通过各个层面的诠释能 给读者对银行核心交易系统的建设带来一个详细完整的解释。分析篇银行核心基础架构的现状伴随着信息技术的发展历程，国内的金融行业一直在经历着各种变革。众所周知在银行 业内，其核心系统对于银行的重要意义，可以说核心系统的变迁代表着银行业整体信息技术 体系的发展。总的来看国内银行业的核心系统发展经历了三个阶段：第一阶段：七十年代末到八十年代中期，银行的储蓄业务以及对公业务逐渐以计算机代 替手工操作，计算机是一个以网点为基础的分散式信息管理域。这个阶段谈不上信息化的变 革，仅仅是电脑取代了手动操作

7、，完全是一种分散式的管理模式。第二阶段：八十年代中期到九十年代末期，这一阶段银行开始通过使用计算机网络技术 实现银行部分业务的实时联机处理，并逐步实现了银行在一定区域范围内的数据集中及互联 互通；区域集中让所辖银行得以共享数据资源，统一了科目设置，改进了业务流程。第三阶段：二十世纪初至今，这一阶段即所谓的数据大集中阶段。全国性的银行数据通信网络框架基本建成，各银行的综合业务处理网络相继建成，一个多功能的、开放的银行信息化体系初步形成；核心系统由原来的网状架构统一成总线集成架构，系统间的接口规范以及报文格式等都形成了统一的行业标准，并且这些技术及标准在不断的优化发展过程当中。 国内大部分城市商业

8、银行，中小股份制银行等都是在第三个阶段直接发展起来的。其核心系统的建设也是直接套用既有标准规范进行实施的。应用架构基本遵循着总线架构模式，业务处理层面既承担了后台联机业务处理又承担了银行账务处理；基础架构层面根据具体的业务负载不同基本会采用 IBM 的大型机、中型机、小型机等物理机模式；数据库层面基本采用的比较成熟的关系型数据库例如 DB2、Oracle、Infomix 等；高可用架构多数采用的是前一个时代的操作系统层面的双机热备软件实现的主备模式。当前，金融脱媒提速，金融监管日趋严格，对商业银行自身的发展提出了更高的要求， 商业银行要想取得持续稳定的发展需要进行架构转型。架构转型是一个复杂的

9、过程，中小银行应基于自身的特点，更不能脱离自身情况，盲目跟进，而是应该采取循序渐进的实施策略， 合理规划，有序推进。商业银行面对的竞争空前激烈，金融脱媒提速，金融监管日趋严格， 对商业银行自身的发展提出了更高的要求。与此同时，云计算、大数据、区块链、移动互联、 人工智能等一系列的新一代信息技术的发展和应用，正式宣告了 FinTech 时代的来临，在为银行的发展带来了全新发展机遇的同时，也对银行信息化建设提出了更多的挑战。在这其中，IT 架构的搭建是银行信息化建设的顶层设计中最为关键的一环，也是根本性的提升信息化能力的有利手段，它向上承载了企业愿景及顶层战略，向下指导着各信息系统的定位和功能，发

10、挥着无可替代的中坚作用。相对于大型银行和全国性股份制银行来说，中小商业银行面临着科技人员储备不足，信 息技术基础薄弱，IT 架构规划能力不足等方面的问题。原有的 IT 架构多呈现“自由生长” 的状态，且难以满足业务高速发展的要求，IT 架构转型势在必行。架构转型是一个复杂的过程，中小银行应基于自身的特点，更不能脱离自身情况，盲目跟进，而是应该采取循序渐进的实施策略，合理规划，有序推进。银行核心基础架构面临问题耦合性问题从银行的数据大集中到目前来讲，银行业务已经经历了将近 20 年的发展。在互联网和信息化没有爆发的年代，银行的业务类型相对固定，发展较为稳定。银行的核心系统大部分 处于安全性、稳定

11、性以及高效性的考虑形成了大核心或者旁核心的局面，也就是既有存贷产 品服务功能又有基础性的公共服务功能还有银行的会计核算功能。近些年来随着互联网以及 信息化的爆发式推进，银行的业务受到了越来越大的冲击。利率的市场化发展要求银行的产品计算模式必须能够经得起灵活性的挑战；金融产品市场化竞争的激烈要求我们的产品及服务必须能够随时创新随时变化；互联网及移动信息化的发展要求银行的支付结算手段必须能够跟得上客户的环境变化；行业标准及国家政策的变化要求银行能够快速适应并变革。我们举几个简单的例子：比如说为了争取客户，对于符合某些条件的客户的存款产品，我们需要定制特殊的利率或者算法，如果我们的核心系统并非基于面

12、向对象或者服务的设计模式来实现的松耦合架构，那么可能会因为我们流程化的产品定义模型以及客户定义模型导致我们对核心系统内部进行较为大的变更；比如说我们面临互利网的环境希望推出有特色的产品来吸引客户，很可能由于核心系统的接口模式固定化导致我们无法快速实现产品的创新和退出；比如说我们面临的营改增问题，如果账务核算和联机业务以及公共处理模块儿能够逻辑隔离，那么这类的问题就不会带给我们核心系统巨大的改动量， 也不必为此承担巨大风险。诸如此类问题会有很多，所有的这些挑战都不是过去那个胖核心或者大核心环境能够解决的问题。这就要求银行的核心系统在应用系统层面必须实现对象化服务化的松耦合模式。资源格局限制从系统

13、的基础架构来讲，由于过去那个大而全的开发模式导致核心系统本身的体量非常 大。在一个物理计算节点上需要支撑多个相互复杂调用的应用服务。这也就形成了过去的大 型机、中型机、小型机的物理格局现状。从单个业务或者交易的处理上来讲，这种架构一定 是稳定的、高效的、安全的。随着信息技术的发展，我相信今天各家银行的大部分系统都已经实现了资源的虚拟化级池化，最起码在应用节点的部署上基本都实现了。至于资源池虚拟化的好处就不用多说了， 但是为什么核心系统迟迟没有实现呢？原因有两点：首先是核心系统的体量太大，如果不是新建，很难把握核心系统内部的逻辑关系实现架构的调整。再有就是由于核心系统的体量太大，那么它对资源的需

14、求量也是非常大的，不是单个虚拟资源能够解决的问题。我们暂不从架构本身的先进性来谈这个问题，我们从服务的角度来考虑考虑。相信核心 系统本身承载的几个模块儿：存贷产品、公共服务、客户信息、账务核算。过去这几个模块 儿可能相对提供服务的负载相对比较固定，所以一直安全稳定运行了这么多年。但是今天在 渠道整合以及渠道创新的冲击下，相信它们各自在日常的运行当中提供服务的频率以及他们 需要的负载是存在巨大差异的，而且是在不断变化的，在这种场景下如果继续保持物理资源的独立格局限制，那么必然带来的是应用上和业务上的僵硬。扩展性短板其基础架构扩展性瓶颈主要集中在两个方面，第一个方面就是支撑银行核心系统平台层的扩展

15、性瓶颈，另外一个方面就是核心系统应用层本身扩展性的瓶颈。从平台层本身来讲， 由于传统模式下的核心系统的高负载高压力的特点，大多数银行都是采用小型机、中型机、 大型机等集中式物理架构。那么今天互联网业务的膨胀式发展必然会引发核心系统基础架构处理能力本身的扩展性要求，主要表现为处理并发以及处理复杂业务逻辑上的需求。这种基础架构本身是不具备灵活扩展能力的。另外一方面由于互联网渠道业务的扩展，金融管理制度的快速改革，金融账户属性本身的多样化发展等因素造成的应用层面本身的变更也变得比以往任何一个时期都会频繁，但是我们传统的核心系统都是会计、产品、总账、联机等模块儿相对比较聚合的状态，任何一个小的改动都可

16、能影响到所有的模块儿，再有就是传统核心系统业务逻辑似乎都有一个通病，就是对并发处理设计的考虑很少，这些因素都会限制我们核心系统应用层的扩展性。数据安全局限性所谓数据安全性主要是指在面临设备物理故障或者是逻辑错误的时候，核心系统数据本 身的容错能力。这个容错能力一方面来自于基础架构本身的数据高可用能力以及数据的容灾 架构设计，另外一方面来源于应用层对于数据在整个流动过程中的校验保护机制。传统核心系统的数据保护从基础架构层主要有几种方式：其一是基于传统块儿存储做的数据复制架构，例如 HP 的 CA 技术、IBM 的 PPRC 技术，EMC 的 SRDF 技术等；其二是基于操作系统卷管理器层面做的逻

17、辑镜像技术，例如 LVM 的镜像技术、VxVM 的镜像技术等；其三是基于数据库层面的复制技术，例如 Oracle 的 DG 技术，DB2 的 HADR 技术等； 其四是为了避免数据逻辑错误而采用的传统备份技术。这些技术往往各有优缺点，单一的技术体系或者是把不合适的技术手段运用到核心系统数据保护上，在真正发生问题的时候，后果往往是灾难性的。近些年来一些现实的案例也充分说明了这一点，例如本来的双机高可用技术由于设备参数的错误设置导致脑裂问题，由于物理的复制缺乏逻辑校验导致了故障场合下的数据切换失败等等。传统核心系统大部分采用的是胖核心的架构模式，其实有一个非常重要的原因就是过去 的技术体系当中，应

18、用系统之间、应用模块儿之间、应用接口之间的数据校验处理机制相对 比较空白，一旦一个业务逻辑跨越了比较多的环节，那么非常普通的一个传输错误、网络中 断或拥堵等事件就有可能导致整个交易处理的不一致或者是不完整。为了避免这种情况的发 生，过去的核心系统尽量将很多的关联模块儿放在了同一个物理平台上，以集中的方式来避 免这种情况的发生。但是随着今天我们业务的膨胀式发展，这种集中到了一定的规模就形成 了一个限制。要打破这个限制将应用解耦并分布式部署，需要解决的一个难题就是要以完善 的校验机制来保障整体业务逻辑的完整性和一致性。银行核心基础架构重构必要性三步走战略分析传统核心系统大部分采用的是胖核心的架构模

19、式，其实有一个非常重要的原因就是过去 的技术体系当中，应用系统之间、应用模块儿之间、应用接口之间的数据校验处理机制相对 早期的银行 IT 主要解决传统手工记账与传票核算电子化等核心任务，主要采用“柜面服务+核心系统”为主体的系统框架，应用逻辑和 IT 系统都极为简单。随着银行业务的高速发展，陆续推出银行卡、支付结算、投资理财等新型的业务产品和种类，核心系统所承载 的交易范围越来越多，系统规模愈发庞大，处理压力日趋增大;同时，原有面向会计核算的 系统架构已经难以满足快速变化的市场需要以及客户的多样化需求。为解决上述问题，首先应当对核心系统的功能进行重新定义，并对核心系统与其他应用 系统之间的业务

20、流程进行重新设计，通过对核心系统的合理“瘦身”，以开放、灵活、松耦 合的原则重新布局银行的各类应用系统。为了快速满足市场变化以及客户差异化需求，还需 要大幅度提升核心系统等底层平台的参数化配置能力。遵循上述建设思路，北京银行通过“三步走”战略，实现了 IT 架构的华丽转身。第一步，对核心系统的功能进行重新定位，将非核心系统交易处理功能逐步剥离使其成 为专业应用系统，并搭建全行级的企业服务总线，负责对全行交易进行统一调配管理，同时 使用科学有效的全行级的服务治理手段，实现对服务的分析、定义、设计、实现、组合、运 行、退出等全生命周期过程制定标准规范并严格执行，保证服务的统一性和标准化。第二步，剥

21、离核心系统中数据处理加工及统计分析的功能，搭建企业级的操作数据存储 平台，经过几年的系统建设，逐步形成“全行级数据服务总线”，与企业服务总线共同组成“双总线”架构。除此以外，通过制订全行统一的数据标准并引入数据管控平台，落地数据 治理，大幅度提升数据质量。第三步，打造“以客户为中心”的新一代核心业务系统，重构核心系统交易调度框架及日终批处理平台，全面提升参数化配置能力，使得系统架构整体水平及性能得到了质的飞跃。 在技术平台全面升级的基础上，新一代核心系统实现了客户信息统一管理、利率及费率差异化定价、产品参数灵活配置、账户多层级化并向产品型账户转型、网点层级多样化、会计引擎模型化的业务支持能力。

22、依托参数化的架构设计使得新一代核心系统成为业务发展的强力支撑。面对 FinTech 时代的机遇与挑战全球金融治理核心机构金融稳定理事会对“金融科技”的定义为：金融科技是指技术带 来的金融创新，它能创造新的业务模式、应用、流程或产品，从而对金融市场、金融机构或 金融服务的提供方式造成重大影响。FinTech 时代对银行信息系统，特别是整体 IT 架构带来了深远的影响和变革。下面，将结合北京银行近几年的实践经验，从应用架构、技术架构 和数据架构三个方面，讨论中小银行在新时期中进行 IT 架构转型的思路、难点及对策。1.加强统一管理，应用架构向“大平台+微服务”方式转型应用架构是对实现业务能力、支撑

23、业务发展的应用功能的结构化描述，重点需回答业务 功能在哪里实现最优的问题，包括应用的设计原则、分层分域与边界定义、集成关系等方面 的内容。中小银行受自身技术资源有限的实际问题，存在根据部门需求被动开发，缺少统一 的应用架构规划、设计及统一管理，部分功能重复建设。鉴于上述问题，在应用架构转型方面，我们要考虑如下几方面问题：一是基于现有系统功能，整合应用，解决目前应用系统多、功能分散、重叠、界限不清 晰等问题，推动全行集中的“企业级”应用平台建设，即进行“大平台”建设。二是面对新时期下业务和产品需求的不断变化，原有的单体应用模式由于耦合度高，关联依赖复杂，变更的时候在开发和运维方面都存在较大困难和

24、风险;同时，也不便于进行扩 展。为解决上述问题，需要对业务系统进行充分的组件化和服务化，构建“微服务”架构。三是全面提升“IT 服务 IT”的能力，通过平台工具的引入，提升开发、测试及运维的自动化智能化水平，加强统一管理。例如：北京银行使用的项目流程全生命周期管理平台， 通过一系列自动化部署流水线完成环境部署、代码的发布、测试、版本管理等项目流程全生命周期的管理，合理利用有限的开发资源，很好地满足了业务和监管要求。2.以混合式集成解决方案，平稳推进技术架构转型技术架构是支撑应用和数据的技术基础。互联网、数字化及智能化等一些系列技术的高 速发展，对传统银行业的支付、理财、客户管理等核心领域产生了

25、极大的冲击和挑战。中小 银行大多采用的是小型机和高端存储，不利于资源灵活管理和成本合理控制，原有的集中式 闭源技术架构已经不能满足互联网时代开放、高效、弹性及多并发的业务发展要求。通过对自身业务与技术现状的深度分析以及对未来 IT 发展趋势的合理预估，北京银行逐步确定以“便捷容量、弹性扩展、自主可控、高质高效、安全稳定”为主要目标搭建技术架构;以将集中式与分布式进行有机结合的混合式集成为总体策略保证传统金融对于“高标 准、高性能、低风险、低成本”的特性要求;明确以“先管理后交易系统、先普通后关键系统、先外围后核心系统”为实施步骤平稳开启技术架构转型之路，并积极探索“主机下移”的解决方案，减少对

26、主机的单方面依赖， 也为未来全面国产化之路奠定坚实基础。3.构建多元化数据架构，满足多样化数据服务需求数据架构立足于解决数据全生命周期过程的统一管理，包括数据产生、数据流转、数据 整合、数据应用、数据归档与消亡等内容。中小银行在数据应用建设方面起步较晚，数据处 理的方式比较单一，对于海量的、不同类型的数据加工及应用能力不足，已不能满足新时期 业务对于数据分析的需求。只有通过创建全方位数据整合能力的多元化数据架构，才能满足“大数据”时代不同层次的多样化数据服务要求。北京银行经过多年的努力，在数据架构上逐步构建起由源系统数据处理、采集交换、数据传输、加工计算、数据应用等多方面共同组建的“智慧数据生

27、态圈”，实现标准化、平台化、智能化、移动化的发展要求。在这其中，大数据平台是整体数据架构中的重要支点，该平台依托大数据及云计算技术自建，以“优化客户体验、强化风险防控、建设智能化运营、 提升营销能力”为切入点，持续打造智能高效的“金融大数据服务”，逐步实现从数据支撑向数据驱动的模式转变。北京银行依托大数据平台对行内数据、外部数据进行沉淀整合，对外提供个人、企业身 份信息核验，个人、企业工商报告及消费行为偏好报告等实时查询服务接口，有效提升全行 的业务营销能力水平，全面降低获客、营销成本;同时，从交易反欺诈模型、大数据征信体系两个领域入手，探索大数据与银行风险防控工作的结合点与创新业务应用模式，

28、主动加强 金融风险管理，为全行客户的资金安全保驾护航。集中式与分布式集中或者分布本身是两种处理问题的方式或者风格，就像是同步与异步一样。但是市场 上的一些流行理念却活生生将集中与分布划分成了两个彼此对峙的阵营。在所谓的集中式阵 营中，如果一定要找一个靶子，那么基于 IBM Z（俗称主机）的技术堆栈可以算得上“众矢之的”的集中式源头。传统银行的 IT 架构目前多为集中式和分布式的混合架构，不同的系统架构迁移策略也不一样。对于集中式架构，多为大型机或者小型机服务器，操作系统为 UNIX 系统。集中式架构的过渡，对于原有系统的架构没有任何影响，因为 LINUXONE 本身也是大型机服务器的架构，唯一

29、需要处理的，就是 UNIX 系统的迁移，提前做好操作系统的兼容性适配工作就可以完成迁移。对于分布式架构，大部分银行是基于 X86 服务器构建，操作系统多为 LINUX。对于这种架构，操作系统的兼容性测试和适配的工作量要小一些，因为 linuxone 本身对LINUX 系统支持的很好。linuxone 在支持分布式架构方面，主要是在单台 CPU 中通过虚拟化扩展的形式，创建一个可软件定义的分布式系统。对于分布式架构来说，如果远有分布 式架构是基于物理机，可以直接进行 P2V 的迁移。如果原有的分布式架构是基于虚拟机， 那么更多的工作量是完成 V2V 的迁移。因为 linuxone 支持的虚拟化是

30、 Z/VM 和 KVM，在虚拟机转换方面，适配的工作量更大一些。在现阶段，银行可以选择一些新建的系统或者非核心的系统，在 linuxone 上先完成部分业务的部署，建立基于 LINUXONE 的基础架构，然后根据业务系统的情况，逐步完成架构的过渡。linuxone 对比大型机和小型机。linuxone 基于大型机 Z13 基础架构，所以对比大型机，只是在操作系统上可以支持 linux，其他特性与大型机完全一样。对比小型机，在性能上，LinuxONE 有着非常强大的硬件配置，最多可支持 141 颗处理器，8000 台虚拟机以及成千上万的容器，并且具有多级虚拟化能力。在安全性上，有着比小型机更可靠

31、的安全架构。LinuxONE 是商用服务器中唯一获得 EAL 5+最高等级安全认证。提供从芯片、交易、到档案全面且高速的加密机制，确保对关键敏感的数据与资料的保护。LinuxONE 的加密技术，能够将每一笔交易记录进行实时监测，并保护数据安全，可以为银行提供最安全的信息系统。主机的技术堆栈在半个世纪前开启了以服务器为核心的计算时代，发展和成熟于业务、 数据大集中处理时代。其一直立足于关键事务处理的企业级计算。作为一个发展最为成熟的通用商业计算体系，不难发现其技术堆栈秉持的一些关键性假设和原则：以成熟、领先的贯穿全堆栈的系统优势，来为用户换取在开发交付和运行维护上更大的专注性。这其实是多年来流行

32、在企业级计算领域的一个重要原则Separation of Concerns（关注分离、专于其事）。经典的企业 IT 组织格局以及技术支持生态也都是基于这样的基本原型逐渐演化形成的。在成熟的主机用户身上，我们能够看到一些典型的特征。比如，从系统角度：精简的系统部署、充裕的扩展能力、连续的业务可用、集约的运维规模。从开发角度：专注于业务的开发模式，更好的架构包容性（有容乃大）。不难发现，要达到的首要目标并不是所谓集中，而是打造一个最高品质的通用商业计算体系。换言之，就是通过系统化的技术手段保障其核心价值的可复制性和普遍性，而不依赖 于对运维或应用等外部因素提出过多特质化的要求。当然，在多年的实践中

33、，运维和应用也 一定会根据系统的特点（优势以及短板）而发展出具有独特性的资产。可以说这几年主机用 户一系列以减少消耗为导向的优化举措也是非常有益的探索。但是我们应该认识到，一个成 熟的商业技术堆栈与兴起于互联网超级玩家的技术堆栈在发展模式上的确存在差异。超级互 联网玩家追求对于技术全栈尽可能的自主掌控是基于其超级庞大的业务和科技体量、爆发式 的发展增速，以及业务和科技融为一体的企业基因。商业系统的运作则是基于契约式。说白 了就是，用经济手段交换能力，用合约手段保障承诺。当然，今天国内互联网巨头纷纷开始 以科技输出进入这个领域，都面临着从“自食狗粮”向商业契约化的过渡和转化。这一点迟 早会把不同

34、基因的参与者拉回到同一个角斗场。其次，就算回到集中与分布的技术纷争。我认为也很难完全把一个技术体系简单归为集中或者分布。很多人可能没有认识到，基于主机的传统交易中间件 CICS 本身就是为分布式服务而构建。CICS 的缩写据说可以解释为 CICS IS CONTAINER SERVICE，这并非笑谈！ 作为分布式服务所需要的容器化运行环境、远程调用框架、服务的注册、发现、路由、负载均衡等等能力在这个技术体系内都有对应的经典实现方式。至于在物理部署模式上是采用水平扩展、垂直扩展或者混合模式，更多的是从性能的优化、运维的效率、扩展的空间等多种角度来综合考虑。反观近年来市场上流行的分布式架构实践，其

35、实质往往无外乎是开源技术的采纳，应用的服务化（甚至微服务化）、以及去状态或者无状态化，严格一致性的妥协， 广泛的异步式处理，再加上数据的业务性或者技术性分散。在过往全球互联网巨头的实践中， 这些手段的运用都是有其上下文和条件的。但是如果将之作为一个教条的概念，甚至赋予新一代“银弹”的期望，不求甚解甚至囫囵吞枣，也会带来负面而深远的影响。“不把所有鸡蛋放到一个篮子里”成为了所谓分布式阵营的一个貌似绝对正确的理念和 旗号。在实践中，可以看到不少过于僵化和教条的做法，比如在没有扩展性瓶颈的前提下单 纯用技术性手段强行分拆数据。我认为一些问题已经超越了鸡蛋和篮子的关系。而是要不要 把蛋黄和蛋清放到一个

36、蛋壳里！未来运维和业务将不得不为这些麻烦而买单。套用流行的佛系用语，“是诸法空相，不生不灭，不垢不净，不增不减，不集中不分布， 不同步不异步。”实践者需要睁开智慧的架构之眼，以己之眼明辨是非，而不人云亦云。微服务与巨石随着微服务架构的迅速蹿红，这颗新的“银弹”又给市场注入了巨大的想象力。人们在传统的交付和运维苦海中挣扎着，怎么加班交付都不够敏捷，怎么解耦应用都还是一团乱麻， 怎么监控生产都还是如履薄冰。与微服务相对的巨石架构随即躺枪成为了万恶之源，如过街老鼠人人喊打。然而如果我们稍微研究一下微服务架构的历史沿革和实质，会发现其关键强调的是一种 架构和交付的文化，“微”的目的是为了服务能够独立、

37、自治的垂直演进。记得曾经有一种 非常有趣的说法，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两 张批萨就够了，这是就是著名的“Two pizza team”原则。在这种模式之下，devOps 几乎毫无例外的是刚需。然而如果仅仅是教条地将微服务作为一种普遍性准则，不分场合，生 搬硬套，同样会遭遇尴尬。在实践中，人们往往最多的问题就是，找不到传统应用重构为微服务的合适场景。而且这种架构和交付方式对于经典的组织结构和文化也造成了极大的冲 击。如何跳出传统的红海（苦海）的束缚，找到一片业务和架构的蓝海，成为了很多实践者 关心的话题。回到“骨感”的现实中，对于传统企业而言，微服务的采纳

38、有可能并不是一个最急迫的 核心问题。而且我们相信经过这么多年应用的治理，在一个有一定水准的企业内，巨石架构 的弊端也没有外界想象那么严重。但是在实践中，必须承认服务化治理本身的确是一个既急 迫又长期的过程，自 SOA 时代以来落下的功课早晚是要交上的。“高内聚、低耦合”在什么时代都是服务的黄金法则。我们在前面曾经提到过，主机架构对于应用有着更大的包容性。这一点在服务治理的历程中是可以得到印证的。记得十几年前，IBM 就建议主机 CICS 的用户在部署应用时，尽量将长交易、短交易，不同业务目标的应用分配部署到不同群组的 CICS 容器（region）中去。这样可以利用系统对于混杂工作负载的调度管

39、理能力，充分地利用系统资源。然而这么多年过去了，大多数国内银行的主机用户仍然利用着系统尚充裕的垂直扩展性，保持着近乎极简的部署模式。不少用户不分或者极少划分业务群组，在每个 CICS 容器中都部署近乎全量的应用，并通过外围路由来区分不同类型的访问请求。这样的做法从积极的意义上，可以认为充分利用了系统架构的优势，简化了开发、部署和运维，并通过架构的包容性为服务治理争取了时间。然而，人们也应该意识到，这样的架构如果平移到另外一个所谓的分布式应用平台，其结果将是灾难的。毋庸置疑，服务的治理是一项长治久安的百年大计。从这个意义上，微服务本身并不是 解决这个问题的“一招鲜”。微服务或者巨石作为两种不同风

40、格的架构，从长远来讲是可以 共生共存的，更何况在二者之间还有广阔的地带。关键是找到彼此最合适的领域。我认为在 垂直的数字化场景这个领域中，可以尝试在新的数字化堆栈中开展微服务的尝试。当然这种 尝试也需要找到合适的抓手，不可僵化套用。比如，在一些大型企业的实践中，先通过无状 态的弹性应用去推动新技术堆栈的发展，有可能是更加符合现实诉求的。最后，通过以上的探讨，让我们尝试抛出一些架构融合的观察和建议。在传统经典的技术堆栈（如基于 IBM Z）之外，新的技术堆栈（所谓数字化双翼）正在成型，并迅速演变。这些技术堆栈之间并不能简单用商业/开源，集中/分布，传统/颠覆来进行概念化二元对峙 的区分。在各自的

41、发展路径上，甚至是可以彼此参照，互相包容，共同进化的。银行核心基础架构重构难点分析交易和核算的分离问题交易和核算分离呢，其实说白了，就是先让客户将业务做完，而账务处理呢却在晚上通 过跑批的方式处理。这样就是借贷平衡记账了，比如我们现在的一个缴费交易，首先从客户 账务上扣钱，然后记到一个对应的内部科目里去。这样就实现了一借一贷。但是这样的记账 有个弊端。就是客户可以很多个，但是对应的内部科目却只有一个，由于每次记账这个内部 户都是被锁住的（防止脏数据），那么如果在大量并发交易的时候，很多客户都在缴费，就 会出现锁表的情况，造成业务中断。还是这个缴费功能，白天客户缴费了，客户金额立刻扣减，同时登记

42、一个客户台账。等到晚上批处理来执行的时候，批量的将这个台账数据跑入内 部户中完成记账处理。这样从客户的角度来看，金额实时减少了，说明缴费成功了，而对于 账务处理，在晚上按顺序批量执行，不会出现大量抢占内部户资源的情况。系统去耦问题这个解耦其实是核心系统本身的解耦，因为传统核心系统将联机业务和账务业务结合到 一起，非常庞大。而且联机业务本身各个模块之间得耦合度非常高，产品灵活性及架构的扩 展性不是非常好。所以这个解耦是说我首先要把核心系统中的总账剥离，然后将联机业务涉 及的模块进行重新分析设计，改造为内部耦合性相对小一些的架构，从而可以支撑应用节点 本身的分布式部署。并不是说要打破现有的总线架构

43、。实际上核心系统的去耦主要就是要把总账系统剥离，总账系统从核心剥离出来之后，核心面临的集中式压力就分散，其他交易系统与原有核心系统的架构耦合性就会小，整体架构的耦合性都会降低。同时也为未来互联网的核心交易业务架构的变革提供了条件。业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据，这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。今天的互联网

44、时代，很多银行的互联网业务已经成为银行的核心业务。要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离，更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对

45、接各种业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为业务服务瓶颈，它的处理只影响银行后台会计事务，属于内部业务。第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂， 可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。多法人支持， 在数据库底层设计中引入法人字段，做到数

46、据隔离。总账系统从核心剥离要看剥离到什么程度了，剥离得太多，那原来的核心就不叫核心了，涉及到具体业务层面的术语我不太清楚，我的个人理解是，要剥离就得梳理总账系统的组成， 这些组成之间又有哪些关联性，剥离之后如何继续进行关联，跨系统关联的性能和并发如何考虑；应用系统（无论是外部交易系统还是核心内部交易系统）对这些组成的交易事务是在一个事务内部还是分开多个事务（如果这些组成剥离开来，各系统的交易事务也得考虑到剥离）；剥离后的批量问题如何解决（原来集中式批量，现在分布式批量）；剥离后原核心的定位和新核心的位置（两个或多核心间其实也是紧耦合的，毕竟总账中的子集还是要依赖于 总账的，如果剥离了子集，核心

47、总账还是要出来获取子集的）；如何分步式，稳妥的进行剥 离，也就是剥离方式的安全有序性问题等等。耦合性最大的应该是账务系统，清算头寸等，几乎只要是交易系统，只要涉及到账务， 也就是钱的交易，都要记账，那就得去核心系统的数据库里记，取核心系统数据库里查，否者各个系统都管着各自的账务，那这个账务同步的开销就更大，没法进行下去了，就想区块链那样，账务交易实时性能更是无法保证。所以说交易系统和账务系统是高度耦合的，无论这个交易系统是在核心内部还是核心外围，都有这样的问题，所以问题的核心不在于剥不剥离交易系统，而在于剥不剥离账务类系统，也就是双核心或者多核心其实做的事情都是一件事，就是账务类系统剥离，有的

48、把清算头寸从核心剥离，有的把互联网账务处理从核心剥离等等，为的就是减轻传统核心的压力，组建多核心，但可能也会带来很多新的问题，剥离的过程也是需要仔细梳理和思考的，比如账务和清算头寸是紧耦合的，头寸剥离出去后，核心还可能要出去取这个头寸信息，那此时的核心就不是真核心后台了，而是多核心共存，互相融合的了，这个融合又可能带来很多新的问题和思考，总之不是那么轻易的事，任重道远， 稳重求进。思维转型思想决定着行为。长久以来，传统银行的科技团队始终将确保客户和银行的资金安全作 为恪守铁律，特别是对于承受风险能力较弱的中小银行来说，安全生产就是生命线。所以在 技术的选择上，使用最成熟、最稳定、最可靠的技术，

49、一直是中小银行的基本工作原则。因 此，在最初的技术选择上无一例外地选择使用以 IOE 为代表的成熟商用软件和体系架构。新时代的 IT 架构转型，在设计、开发、测试、运维及管理上需要有不同的思维和技术能力，这对现有技术团队的思想观念和工作模式造成了巨大的冲击，需要有一个“脱胎换骨” 的转变过程。例如北京银行高层领导高度重视 IT 架构转型工作，清晰且坚定地向自己的管理层和员工，传达银行在 IT 架构转型的战略和想法，并推动银行全身心拥抱这一场全新的技术革命;二是虚心向在新技术应用方面更具优势的互联网公司及金融同业学习，并采用多 种形式的交流合作，做好新时代下的系统能力建设;三是技术部门与业务部门

50、需要更加密切 合作，协同推进新的 IT 架构发挥最大价值。思维转型相对于原有的 IT 架构，新的技术架构对于设计、研发、运维等人员的知识结构有着新的要求，架构转型需要与人员知识结构转型相配套。目前的新兴技术具有类型多、变化快等 特点，中小银行没有充足的技术力量对这些新技术进行跟踪与探索。而研究这些技术的大多 为创新型公司，一般规模小、成立时间短且缺乏对银行应用特点的理解和金融行业的实战经 验，难以提供持续稳定的技术支持。一是在诸如云计算、区块链等关键技术上组建研发实验室，对新技术进行研究、创新、 试点和培训，为银行发展储备相关技术人才。将专业性人才的培养集中在核心技术领域，可以使得中小银行中有

51、限的 IT 人员发挥最大价值，切实保证关键技术的自主可控;二是高度重视并积极建立吸引和留住关键人才的长效机制，通过建立信息科技专业技术岗位序列，让专家型技术人员有良好的职业发展空间;三是积极开展与国内有实力供应商的合作，通过成立金融科技实验室联合开展技术难点的研发和攻关，共同找到新技术在银行领域应用的最优方 案。多年的架构转型发展之路，充满了困难、阻碍，有过质疑、犹豫，也有成效和欣喜。在FinTech 时代的浪潮下，随着转型工作向银行核心应用及基础环节的推进，难度、风险和困难也将越来越大。对此，北京银行将在战略上坚定不移，在战术上高度重视，在实施上细致 入微。在确保现有信息系统稳定、安全运营的

52、前提下，顺利推进架构转型的全面胜利，从而 有力支撑业务创新!规划篇银行核心系统去耦设计业务模块的逻辑拆分业界并没有一个统一的定义，但是有一点可以明确的是银行的核心系统不是一个单一的应用系统，而是一组应用系统的组合。具体包括：存款管理、贷款管理、支付结算、会计处理、总账处理等等。在这些模块儿当中有一个核心的线索可以将其串联到一起就是账户数据， 这个账户既有个人的账户也有机构的账户。所有围绕账户产生的一些借贷行为组成了银行核心系统联机业务的流转以及会计实务的处理。今天的互联网时代，很多银行的互联网业务已经成为银行的核心业务。要解决传统核心的去耦问题，首先第一个需要解决的问题就是根据自己银行的业务发

53、展模式来决定是否将互联网的账户和本地账户进行分离，也就是一类账户和二三类账户的分离。如果我们的二三类账户业务非常庞大，而且发展趋势页也非常明确，那么不仅仅需要核心系统本身的账户分离， 更需要业务部门重新来定义二三类账户业务的管理模式和权限归属问题。接下来，第二个需要解决的问题就是联机业务和总账业务的分离。总账业务系统可以单 独切分为一个独立系统，联机业务、信贷业务、支付业务、互联网交易等等这些业务完全成 为一中对等的模式来支撑银行的日常金融服务。总账业务系统成为一个单独的可以对接各种 业务类型的账务平台，由于它属于账务类系统没有实时提供金融服务的属性，也就不会成为 业务服务瓶颈，它的处理只影响

54、银行后台会计事务，属于内部业务。第三个需要解决的问题就是联机业务系统内部本身的设计。以客户为中心的设计，建立基于全面了解客户能力的客户统一视图，提供客户统一入口的客户服务全面整合。建立组合模式的产品工厂，可以根据业务创新进行产品的灵活组合，而不是单一死板的产品模式。实现灵活定义的利率工厂模式，根据未来客户服务的市场化建立内部定价体系，提供多维参数化定价体制，提供多为利率组合模式，既可以实现通用计算模型又可以实现特殊化的利率模型。 多法人支持，在数据库底层设计中引入法人字段，做到数据隔离。应用模块的分布式部署传统的核心系统，无论是联机应用还是批量应用基本的部署方式还是物理机的独立格局部署方式，从

55、其他系统的业务请求到核心系统内部请求的处理基本都属于独立格局，这个流程涉及到的请求、调用、处理等事务基本都属于固定模式，没有任何动态分配算法来支撑。 我们在核心系统去耦工程当中，非常重要的一个事情就是要解决这种独立部署的格局。首先就是要解决核心系统联机应用的负载均衡支持问题。有些核心系统的设计已经采取了分布式 架构，利用一些分布式中间件以及缓存的中间件来实现联机业务请求的分布式部署。这是一 种趋势，无论是用 Tuxedo 软件负载，还是利用 F5 硬件负载，都应该实现应用层面的负载均衡部署。当然支撑这种部署方式的前提是应用层面必须具备对业务处理逻辑的校验，无论 是会话策略还是链接策略，都因该具

56、备交易处理的逻辑校验功能，以支撑核心系统业务处理 的分布式架构。基础架构的逻辑解耦核心系统的基础架构主要是指支撑核心系统应用以及核心系统数据库的平台架构，既包 括计算资源的集成又包括存储资源的集成。如果采用大型机、中型机、小型机的架构势必会 导致核心系统本身的灵活性受限。如果采用通用 X86 分布式的架构又会担心其处理能受限导致系统整体的稳定性和高可用性受限。因此在核心系统基础架构的选型过程中既要考虑到单个物理资源的处理能力受限问题， 又要考虑到单个物理资源对整体核心系统群的扩展性和灵活性受限的问题。因此在当前环境下，应该结合二者之优势来设计整体核心系统整体。单个物理资源的选型我们要考虑到其足

57、够的处理能力，横向的资源扩展我们要考虑到资源的横向组合性，足够适应虚拟化技术、资源池技术带给我们的资源整合优势。数据库的选型我们要充分注重其纵向的处理能力，应用服务器的选型我们要充分注重其横向的扩展能力。资源池化方法应用和资源的映射关系分析说到应用和资源的映射关系，其实就是什么类型的应用需要什么类型的资源去支撑。比 如说有些应用是计算秘密性应用，有些应用是内存密集性应用，还有一些应用是存储密集性 应用。但是对于资源实体，也就是我们的服务器或者是存储设备来讲，是无法实现特定应用 类型的资源配比，因此一定会造成某一方面或者某几方面的资源浪费而某一方面的资源紧缺。因此，在核心系统各种资源池化的整体思

58、路框架之下，首先是要分析出核心系统各个业 务模块，各个层面对资源的需求状况究竟是什么样的。例如，可能联机交易业务的处理更多 的是内存资源的耗用，而批量业务的处理更多的是 CPU 资源的耗用。数据库内的数据处理更多的是 IO 和内存资源的耗用。只有前期对于核心系统各个模块儿的资源耗用特点有一个清晰的把我，那么才能支撑我们后期对资源池的划分和虚拟资源的设计。虚拟化方案的设计多为虚拟化方案的设计，主要是指对虚拟化解决方案的选型以及具体虚拟化设计方案的 规划。对于虚拟化解决方案的选型主要依赖于我们所选硬件的兼容性要求，例如 X86 服务器的虚拟化解决方案相对宽松，而 Power 架构服务器的虚拟化解决

59、方案相对比较狭隘。所以今天的客户更多是选择了基于 X86 架构的服务器资源。当我们选定了支撑我们虚拟化方案的硬件资源之后，那么就是对具体虚拟化设计方案的规 划。主要涉及以下几个方面的详细规划设计：一、各个资源池的设计无论是什么样的资源池化技术，一个共通的功能特性就是可以实现 CPU、内存、网络、存储等资源的共享技术。用哪些物理资源去组织成为那些可用的资源池就是我们这一个步骤需要考虑的问题。对于应用服务器资源来讲，彼此产生冲突的是 CPU 和内存资源，需要建立统一的 CPU 和内存资源池。对于数据库服务器来讲，除了内存资源的冲突之外，更多的是存储资源的冲突，因此需要建立统一的存储资源池。二、虚拟

60、服务器对资源的分配策略由于不同的应用对不同资源的获取和访问具有不同的属性特点以及不同的重要程度之分，因此我们在对不同虚拟服务器的资源分配上需要建立不同的动态分配以及优先级策略分 配模型。比如，在数据库服务器和应用服务器的资源竞争策略当中，那么数据库服务器的内 存优先级一定高于其他服务器；在联机应用服务器和批量应用服务器的资源竞争当中，一定 会有时间段的区分，设计争夺策略的时候需要充分考虑到时间段的分布；数据库服务器和其 他服务器存储资源的使用和竞争过程当中，一定会有 IOPS 和高可用的区分，在具体的分配策略当中我们需要充分考虑到这一点的区别。三、资源的动态优化策略所谓资源的动态优化策略是指在