• 快捷搜索
  • 全站搜索

分布式转型中的主机下移实践

2017-07-14 16:33:23作者:中国建设银行信息技术管理部总经理 金磐石编辑:金融咨询网
全球IT市场正发生巨大的变化,新技术正在改写游戏规则。主机一直以其高可用性、高吞吐率而备受大型银行的青睐,但随着分布式架构的崛起,主机面临着日益严峻的挑战。

全球IT市场正发生巨大的变化,云计算、大数据、物联网、人工智能等新技术正在改写游戏规则。主机一直以其高可用性、高吞吐率而备受大型银行的青睐,但随着分布式架构的崛起,主机面临着日益严峻的挑战。为此,各家银行都在积极探索“主机下移”的解决方案。主机下移不等于完全弃用,而是通过优化系统架构,将部分应用从集中式部署向分布式部署转变,构建多平台多技术融合的架构。主机下移旨在减少对主机的单方面依赖,实现自主可控,降低安全风险和成本。

无标题.jpg
中国建设银行信息技术管理部总经理 金磐石

        本文对主机集中式架构与分布式架构进行对比分析,提出“集中式+分布式”的融合架构,分享建设银行新一代系统建设中,实践多种主机下移方案的关键技术设计要点,为央行推动数字化架构转型提供实践参考。

选择主机下移需要拨开迷雾看清方向

        针对主机集中式架构、开放集中式架构、分布式架构,我们从七个方面进行了对比分析。

        可扩展性。主机集中式架构:应用服务和数据服务紧耦合,应用系统运行在同一套主机服务器集群中,扩展性主要依赖主机系统平台,具有很强的纵向扩展能力,不支持跨主机集群的横向扩展。分布式架构:应用服务和数据库服务松耦合,应用服务和数据服务分别运行在不同的服务器集群中,扩展性主要依赖应用平台,由于采用分库分表技术及X86服务器,因此应用服务器和数据库服务器均具有很强的横向扩展能力。开放集中式架构:应用服务和数据库服务松耦合,扩展性主要依赖于数据库服务器纵向扩展能力,如果采用小型机,纵向扩展能力略高于X86服务器。

        高可用性。主机集中式架构因并行架构和硬件的高可靠性,可用性可达到99.999%。分布式架构采用X86服务器,硬件的可靠性不如主机,但是因采用分库分表等技术,系统整体可用性也可达到99.999%,并可避免因集中式架构的数据库不可用引起全局性故障的风险。开放集中式架构采用的小型机或X86服务器硬件可靠性低于主机,整体系统可用性只能达到99.99%。

        ACID模型和CAP理论。ACID模型是指数据库事务正确执行的四个基本要素的缩写,包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。该模型主要适用于集中式数据库系统。由于集中式数据库系统共享存储,不存在将数据分片存放到多个数据库的情况,因此只需支持ACID特性就能够满足强一致性事务处理要求,主机数据库和开放集中式数据库是典型支持ACID模型的系统。

        CAP理论是指一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分布式架构设计时,必须做出取舍。对于分布式系统,分区容忍性是基本要求,否则就失去分布式的价值,设计分布式系统,就是在一致性和可用性之间进行取舍。目前大多数分布式系统选用最终一致性代替强一致性,换取高可用性,属于CAP理论中AP系统的范畴。CAP理论同样适用于集中式数据库系统,事务ACID属性实际包含在CAP理论“C”的内容中,主机数据库和开放集中式数据库因为没有分区特性,属于CAP理论中CA系统的范畴。

        交易一致性是银行核心业务系统的基本要求,远高于电商平台和其他互联网应用。银行的分布式架构需要在满足A P特性的基本要求下,针对银行核心业务特点提升最终一致性的“一致性”保障,避免账务风险。

        系统复杂度。对于系统的扩展性、可用性、一致性等特征,主机集中式架构依赖主机系统平台和数据库管理系统实现;开放集中式架构依赖开放系统平台和数据库管理系统实现;分布式架构更多依赖应用软件平台和应用系统实现。因此采用分布式架构的系统复杂度高于主机集中式系统和开放集中式系统,系统全生命周期的设计、开发、测试、运维等工作的难度都有所增加。

        敏捷性。主机集中式架构和开放集中式架构,系统紧耦合,单一系统规模庞大、功能繁杂,开发和变更周期较长。分布式架构采用服务化、单元化设计思想和分库分表技术,将系统拆分为若干较小规模的独立单元,每个单元独立开发部署,相比集中式架构更易支持快速迭代开发和灰度发布。

        总体拥有成本。总体成本不但需要考虑硬件、软件、网络及灾备建设等成本,还要考虑机房场地环境、能源成本,以及开发成本、运维管理和人力资源等成本。在给定的目标可用性和一致性条件下,根据统计和匡算,分布式架构(X86)的成本是集中式主机成本的1/10。

        企业性质。银行等金融机构更关注的是7×24小时不间断地提供优质的服务以及良好的企业形象。所以我们认为主机下移只是手段,信息安全、自主可控、架构优化、成本控制才是目的。

        通过上述对比分析发现,分布式架构并非完美无缺,完全替代主机集中式架构的条件还不成熟。银行应按照应用的一致性、可用性、性能、开发效率、成本等约束条件,合理选择相应架构。我们在主机下移的实践中采用“集中式+分布式”的应用架构。将交易量大、可用性和一致性要求高、需求变动不频繁的关键应用保留在主机上,也就是“好钢用在刀刃上”。将交易量大、可用性要求高但一致性要求略低的重要应用部署在开放集中式和分布式平台上。

        目前权衡了应用特点、安全性、成本等因素,主机下移的方案主要有三种。一是基于分布式架构重构应用的整体下移方案,完全脱离主机平台;二是基于数据复制技术的查询交易下移方案;三是基于数据库远程访问技术与数据同步技术的应用层下移方案。

主机下移在建行新一代系统中的实践

        下面具体阐述三种下移方案的设计和技术要点。

        1.基于分布式架构的整体下移方案

        核心思想:应用层与数据服务层整体下移到分布式平台。以X86和云计算为基础、以数据切分、读写分离为特征。采用横向扩展的方式,通过增加服务器的数量,提升系统的处理能力,每个节点形成一个可独立运行的单元,保证系统整体的可用性。

        建设银行贷记卡管理系统是分布式架构实现主机下移的典型应用之一。将原主机平台的账单、报表、备忘录等功能剥离到分布式平台实现,降低了主机资源消耗。

        分布式架构的核心在于并行拆分与一致性保证,下面介绍分布式架构关键技术要点(如图1所示)。

无标题1.jpg
图1 分布式架构技术要点

        (1)高并发处理机制。分库分表:使用SBF数据分布模型解决分库分表的问题(即Sharding Key分区键-Data Bucket数据桶-Table Family表族)。其核心思想是应用数据逻辑态与物理态的隔离,从请求数据识别出分区键,然后应用算法确定数据桶的编号,相同编号的数据桶形成一个表族。将数据桶映射为物理数据库的表,根据数据库的数量,将所有的表族均匀分布到各物理数据库中。分布式缓存:对于读多写少的公共数据,可采用分布式缓存技术实现数据共享,优化访问性能。

        (2)高可用机制。故障隔离:数据库分库分表后,在大幅提升系统处理性能的同时,规避了大型单一集中式数据库的运行风险。通过“SBF”数据分布模型,准确识别数据桶编号与物理数据库的对应关系,快速改变物理数据库可用性的标识,实现故障隔离。集群架构:每个分库仍然应该保持集群架构,这种横向扩展的部署架构具有无限性能扩展和高可用性。

        (3)一致性保证。日间一致性:日间对于调用外部组件的失败交易,支持交易重发或冲正机制,保证交易事中一致性。为避免频繁的冲正和重发影响正常交易,对于冲正和重发失败次数达到指定阈值的交易,不再进行冲正和重发处理,转由日终核对机制处理。日终一致性:对于日间经多次重发或冲正失败的交易,采用日终批量方式与关联方进行核对,确保一致性。

        2.基于数据复制技术的查询下移方案

        核心思想:采用数据复制工具将主机数据以准实时的方式复制到开放集中式数据库,查询交易所需信息直接从开放集中式数据库中获取,不再访问主机数据库。

        建设银行对公存贷款系统是采用基于数据同步技术实现主机查询下移的。该方案遵循读写分离的原则,将涉及客户合约、账户、介质的维护类交易及账务类交易保留在主机平台,将交易明细的查询类交易迁移到开放平台,主机和开放平台之间采用准实时方式同步,保证账户信息及流水信息的时效性。

        数据复制下移方案的关键在于控制数据延迟和高可用保障机制。由于采用异步复制技术,开放平台的副本数据与主机平台的主本数据存在延迟,如果延迟时间过长就会影响用户体验。控制数据延迟的时间,就是保障不影响用户体验的前提下将尽可能多的查询交易下移到开放平台,节省主机资源。对公存款查询系统通过优化数据复制策略、使用高性能X86服务器、数据库优化等手段,保障把数据延迟时间控制在一定范围内。

        高可用保障机制:利用企业服务总线的访问控制机制控制前端接入渠道或组件,建立第一重保障机制,实现外围组件访问对公存款系统的查询交易切换到开放平台。对公存款查询系统建立第二重保障机制,当数据延迟比较高时,以服务方式穿透访问主机数据,确保结息日等数据延迟比较大的特殊时点服务也能够正常运行。建立根据不同数据延迟容忍度的不同具体使用场景采用不同的数据访问策略的第三重保障机制,对于数据实时性要求极高的场景以服务方式穿透访问主机数据,确保“新开户并联动签约”、“招投标”等对实时性要求极高的场景也能够正常运行。

        3.基于数据库远程访问的应用层查询下移方案

        核心思想:将数据库远程访问技术与数据同步技术融合。一方面,基于数据库远程访问技术(SQLJ)将数据服务层保留在主机平台,应用逻辑下移至分布式平台。另一方面,融合数据同步技术,将部分数据落地到分布式平台,进一步减少对主机的访问量。

        客户信息系统的查询类交易按照应用层下移的方案进行了改造。下文中图2展示了传统的应用架构;图3展示了基于SQLJ改造后的中间架构;图4展示了创新应用层下移架构。

无标题2.jpg
图2 传统应用架构

无标题3.jpg
图3 基于SQLJ 改造后中间架构

无标题4.jpg
图4 创新的应用层下移架构

        (1)数据库远程访问(SQLJ)。传统的客户信息交易从Web界面发起,经过企业总线路由到主机平台,在主机平台调起交易,并在主机平台数据库中完成数据查询,将结果按原交易路径返回。在交易全路径中,逻辑服务层与数据服务层均部署在主机平台。经过SQLJ改造后的客户信息系统,交易仍然通过Web界面发起,但不再经过企业总线路由,而是Web端缓存交易注册表副本,直接调用部署在分布式平台的应用,通过SQLJ技术远程访问主机平台DB2数据库。由此,应用逻辑层由主机平台的中间件下移到分布式平台应用服务器。

        (2)SQLJ技术与数据同步技术融合。通过SQLJ技术实现新一代客户信息系统查询交易下移后,基于现有架构又进行了二次优化。在主机日终批处理时,通过批量的方式将变化的数据同步到分布式平台。在联机时段,当主机平台完成客户信息修改时,通过EDA的方式向分布式平台发送数据变更信号,当分布式平台接收到变更信号后,会立即触发起一笔数据库远程访问请求(即基于SQJ的交易),将主机平台修改后的数据同步到分布式平台数据库中,同时修改分布式平台的变更登记表,标识此条记录已经同步。在联机时段,当分布式平台执行查询请求时,首先会查询数据变更登记表,如果所查询记录已为同步状态,则会在本地ORALE数据库完成查询并返回。如果如查询记录为未同步状态或分布式平台查询无此数据,则发起数据库远程访问请求,远程访问主机平台数据库完成查询交易。

        (3)协处理器。主机配置的协处理器(ZIIP),可以分担数据库远程访问中所产生的CPU消耗,而协处理器的价格仅是普通处理器的2.67%。

结语

        相比集中式处理架构,分布式架构具有高性能、易扩展、低成本等优势。但在银行的一些关键应用领域,集中式架构在稳定性、一致性方面依然具有一定优势。目前来看,“集中式+分布式”的融合架构是一种适合银行业务特点的架构方案,该架构融合互联网和银行传统IT技术,各有优势,互为补充;“集中式+分布式”强调整体上采用分布式架构,一些关键应用上采用集中式架构,这将是银行IT架构未来发展趋势。总体来说,银行业未来IT系统架构需要在保持传统金融行业对于“高可用、高标准和低风险”的特性的同时,满足“高性能、高弹性和低成本”的要求。

        在架构转型过程中,不能简单照搬互联网金融公司经验,而要根据银行自身业务特点和不同应用场景,结合现有的技术资源,做好IT架构研究。建设银行的主机下移实践,愿为“加快架构转型,建设数字央行”提供经验分享。

(文章来源:金融电子化杂志)

扫码即可手机
阅读转发此文

本文评论

相关文章