重塑核心银行基础架构

1、重塑核心银行基础架构1Gartner: Pace-Layered Application Strategy2银行核心转型的平台决策-集中式 vs 分布式及业务功能分布3System z的特点及大型银行的实践 Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate InnovationSystem of Innovation(Interaction & Content)System of Record(Process & Data)System of Differentiation(Integration

2、& Exchange)分类业务流程改变节奏生命周期战略关注点相关方/责任人资金来源实验性, 不清晰, 动态,探索性快速, 经常, 随意(每周,有时每天)3至12个月颠覆式战略;创新业务模式适度的高管参入; 高度的最终用户参入部门 Opex;创新预算高度配置化和客户化中等, 频繁(3至6个月)2至5年敏捷性/灵活性;竞争优势高度的 LOB 主管参入; 适度的最终用户参入Capex 和 Opex;IT 或部门预算集成的, 标准化, 稳定的缓慢, 不经常, 渐进式(6至12个月)大于10年标准化; 运营效率高度的高管参入;低度的最终用户参入Capex 和 Opex; 年度预算The pace-lay

3、ered approach acknowledges that process and data integrity requirements will be different within each layer, and defines a set of architectural standards at each level to accelerate an organizations ability to adapt.1Gartner: Pace-Layered Application Strategy2银行核心转型的平台决策-集中式 vs 分布式及业务功能分布3System z的特

4、点及大型银行的实践 IBM方法论:一个典型的基础架构设计框架银行核心系统平台选型要素银行核心系统的选择会根据各行的业务需求从功能性及非功能性两个方面进行评估，而系统平台的决策则重点从非功能性角度进行决策。 核心银行系统主要非功能性需求规模性能可用性和弹性高峰时段每秒处理的交易量数据量：包括数据库规模和其他所有业务数据量账户数联机交易响应时间批处理窗口计划内及计划外停机时间RTO and RPO关键业务服务实现双活运维管理在系统设计时，需要考虑提供对响应能力，利用率，吞吐量、容量和性能的测量功能；需要定义一种可持续的监测和分析服务水平数据的机制安全性信息安全系统安全审计能力核心业务数据库逻辑集中

5、的典型架构模式集中式分布式中间模式架构特点：单一的数据映像/视图统一的集群中间件简洁的基础架构应用开发集中于业务功能实现并轻松实现数据的实时强一致性客户案例：各行业均有大量案例架构特点：按业务线进行分库处理；大业务库进行二次小规模分库分表处理采用多套分布式的传统中间件应用层面需要考虑分库分表的情形并进行特别的处理以保障数据的强一致性客户案例：个别银行和电信用户架构特点：按业务线进行分库处理；大业务库进行二次不同规模分库分表处理针对自身业务特点自行开发专用中间件进行交易的分发和整合处理业务上允许数据的最终一致性而非强一致性客户案例：某电商/某第三方支付平台集群中间件应用应用应用应用应用业务线A业

6、务线B业务线C业务线M业务线NA1A2A3A4M1M2M3中间件中间件中间件中间件应用应用应用应用应用业务线A B C D EA1A2A3AX W X Y ZAYZ1Z2Z3ZXZYE1E2EN自行开发专用中间件应用应用应用应用应用不同架构模式的特点和挑战分析处理方式集中式半集中半分布式分布式互联网为例业务要求承担社会稳定民生不可或缺的金融基本服务需要满足监管以及风险管理的要求需要业务支撑核心系统满足严苛的实时事务完整性和数据强一致性的要求承担社会稳定民生不可或缺的金融基本服务需要满足监管以及风险管理的要求需要业务支撑核心系统满足严苛的实时事务完整性和数据强一致性的要求提供的服务用于提高民生生

7、活质量无严苛的监管以及风险管理的要求有线下的服务可以替代业务支撑系统无需满足严苛的实时事务完整性和数据强一致性的要求方案特点相对简洁的基础架构（基于主机及商用软件为主实现），包括系统、数据库、中间件到应用的统一集中部署和管理统一/单一数据视图保障信息的实时单一性应用开发人员无需考虑系统级功能的实现而只需专注于业务功能实现或业务创新具备非常强的高可用及扩展能力简化的开发、测试、灾备环境的部署较为复杂的基础架构（基于小型机及商用软件为主实现），存在多套数据库和中间件环境导致应用设计、开发、部署及运行的复杂度的提升可部分解决较大规模业务压力带来的挑战通过投入人力在应用程序层面实现部分“系统级”缺失的

8、功能并在一定程度上解决一致性问题非常复杂的基础架构（主要基于PC服务器及开源软件实现）需要投入大量人力在应用开发尤其是专用中间件的开发方面基于分布式数据库架构的应用开发通过自行开发的专用中间件得到简化主备数据库异步复制模式可以实现数据备份及读写分离等可能挑战需要具备非常强大的业务连续性保障方案高端服务器及相关商用软件初始采购成本分库分表导致应用开发变更复杂度大幅提升批量作业时间窗口的延长可能的新业务推出时间的滞后对未来业务进一步成长所带来的新业务高峰的承载能力(或者进一步分库分表的复杂度)单边帐引发的对账处理压力开发人员需要花相当比例时间用于”系统级”功能实现而非业务要求的实现或业务创新由地域

9、数据竖井转变成业务线数据竖井所可能导致的部分数据孤岛的存在由于分库分表导致应用开发及应用变更的复杂度提升专有中间件功能的局限性，特别是在跨库跨表的情况下单边帐引发的对账压力（包括内部系统之间的不一致及和外部系统的不一致）可能的监管要求加强所带来的挑战银行未来集中式数据库架构模式有三种平台选择System ZX86 Scale Out 事务及数据的完整性性能、成本及可扩展性并行处理复合负载高可用性及容灾能力High End Power高可用性及灾备测试中，难以确认数据库恢复的一致性可扩展性：需要基于所有技术组件进行调优以达到所需要的性能。如网络、存储技术的成熟度：涉及多厂商复杂的系统集成环境。网

10、络成为系统集成的重要组件（不像大型机的内存集成）。技术能力的短缺及技术的不成熟、不稳定以支持实际核心系统的生产环境。全球银行100强中的92家运行在System z 主机上，中国共有11家银行的核心应用运行在System z主机上证明的性能及规模90% 以上的中国银行使用Power(includes AS400) 证明的性能及规模1Gartner: Pace-Layered Application Strategy2银行核心转型的平台决策-集中式 vs 分布式及业务功能分布3System z的特点及大型银行的实践 选择System z主机的主要技术优势事务、数据强完整性保障线形可扩展性混合负载

11、的有效管理高可用性生产系统均采用z/OS Parallel Sysplex并行偶合体集群架构 （一般包括4节点服务器 + 2节点并行耦合器）DB2/IMS等数据库基于集群部署支持统一的数据大集中CICS等交易中间件基于集群部署进行跨服务器的统一资源调度优化和负载均衡普遍已经部署同城、异地、两地三中心、双活等方案实现容灾和业务连续性的需求软硬件一体化的设计和高度集成事务及数据的完整性(Integrity)完整性在不同的业务场景有着不同程度的需求，对于银行业实时事务及数据的完整性对于经营风险或者用户体验有着密切的关系。System z平台-交易信息完整性信息存在于单一系统中，信息的完整性通过简单高

12、效的系统级方式得以保护。简化应用的复杂度，减少业务后期处理的成本System z平台-监管与核算信息完整性减少了信息的多头存在，建立统一监管与核算的信息处理与视图，及时有效。Router 负载分发OLTPOLTPUnix应用层数据访问层应用应用应用应用Unix业务相关的数据合库（ECIF，账户，产品)数据集成平台Unix平台-交易信息完整性信息存在于多个系统中，两种基本模式用于提供信息的完整性。一种是基于协商的分布式处理（2PC），这种机制解决了多系统间的数据完整性，但付出了冗长的交易时间与复杂的出错处理（甚至人工干预）的代价。另一种是基于应用的异步模式。这种模式造成应用的复杂度，造成单边账的

13、几率大，依赖于更多的业务后期验证、平账处理Unix平台-监管与核算信息完整性多个系统的存在，无法保证监管与核算信息的及时性和有效性。通常来讲，这些信息的汇总是经过以几天或几星期的延迟来完成的。控制信息锁信息缓冲区TORTORAORAORTORTORAORAORZOS2Coupling Facility动态虚拟IP自动分发（SYSPLEX Distributor）OLTPOLTPCICSPlexDB2 data sharingSystem z10 System z10 )DB2DB2ZOS1应用层数据存储层数据访问层业务相关的数据合库（ECIF，账户，产品)国内主要商业银行的规模比较及核心平台银

14、行资产规模机构账号数量（百万）客户数（百万）每天交易量TPS 核心系统平台信用卡平台业务连续性系统建设118.9万亿1757460043728744万笔(2014/9/30)7376笔/秒(2014/9/30)System zSystem z两地三中心，同城双活215万亿27305117368447990万笔（2014/11/11)11655笔/秒(2014/11/11)System zSystem z两地三中心，同城双活在建316万亿23547-42044974万笔(2014/11/11)8807笔/秒(2014/11/11)System zSystem z两地三中心，同城双活在建412.6

15、8万亿1120090035019464万笔(2014/11/11)4726笔/秒(2014/11/11)System zSystem z两地三中心，同城双活在建55.96万亿270220010011500万笔(2014/11/11)2741笔/秒(2014 CNY)System zSystem z两地三中心，同城双活63.14万亿1000100608000万笔2000笔/秒(2014 CNY)AS400System z两地三中心，同城双活筹备72.68万亿（2011）6557040500万笔IBM UnixIBM Unix82.77万亿（2011）7006030400万笔AS400IBM Un

16、ix94.61万亿（2011）509IBM+HPUnixIBM Unix102.41万亿7692114.58317万笔（2014/11/11信用卡交易）1937笔/秒(2014/11/11卡交易）HP UnixSystem z异地灾备及应用双活111.5万亿505IBM UnixIBM Unix121.46万亿6627036700万笔600笔/秒（预计全部上线后）System zSystem z建设中131.89万亿52827203500万笔（信用卡）800笔/秒(2014/9卡交易)System z + IBM UnixSystem z异地灾备 备注：此表中，因统计口径和统计时间不同导致数据

17、可能存在出入且部分数据为估算，该数据仅做为量级上的参考。| Feb 8, 2010 混合处理能力：在德国一家银行最近的实践验证，将UNIX上的批处理(Batch Job) 应用迁移到 System z上，性能提高了两到三倍UnixSystem zI/O处理性能I/O处理由中央CPU控制完成运行批处理作业时，大量同步I/O操作导致CPU利用率低，无法通过增加CPU提高批处理性能具有专用于I/O处理的CPU (System Assistant Processor)运行批处理作业时，即使有大量的同步I/O操作，CPU利用率仍可达90%以上操作系统设计原则Unix最初是为交互式开发环境而设计将批处理和

18、一般交互式作业都作为进程(process)管理，无区分z/OS最初是为批处理而设计的操作系统针对批处理(如时序安排scheduling等)方面有独特的设计系统架构设计由于UNIX操作系统本身的局限，对大型系统，一般将应用服务器和数据库服务器分开部署；对批处理作业，这种架构会带来处理性能上的瓶颈。应用和文件、数据库服务都在同一个操作系统内完成，访问效率高混合工作负载 提高系统利用率，提高投资效用System z 的虚拟化使得混合高低优先级的载荷时而不必牺牲高优先级载荷的性能高基准的支撑平台帮助应用更专注于实现业务功能和提升创新能力，应用部署和基础架构复杂度带来的挑战及非功能性方面需求的满足基本通

19、过平台能力实现，从而简化应用层面的设计和实现！客户选择大型主机平台的主要理由最可靠的业务支撑业务系统不会因为单一硬件部件故障或维护而宕机停止服务业务系统不会因为集群中的单一节点故障或维护而中断业务系统不会因为单一数据中心不可用而导致服务中断最优异的联机和批量性能大规模并发压力下保持毫秒级的联机交易响应时间打造领先客户体验强大的批量作业处理能力确保次日业务顺利开展最先进混合负载管理能力支持日间/联机批量放心运行提升客户满意度最强大的扩展能力最为领先的跨硬件、操作系统、数据库以及应用中间件的全方位集群体系架构设计业界最强纵向扩展能力及最强横向扩展能力轻松应对全国大集中的要求及各种业务高峰 不影响业务运行条件下实现快速的处理能力的提升及升级换代最领先业务连