张升:农业银行的分布式架构应用实践与展望

近年来,以阿里为代表的互联网企业提出的“去IOE”,在业界引起了广泛的讨论。“去IOE”直接含义是不使用传统IT巨头的产品,这些厂商产品虽然好,但基本处于市场垄断地位,用户议价能力较弱,成本高昂,技术受制于人,供应链风险较大。“去IOE”更深层次的含义是采用分布式的架构替代集中式的架构,构建高可用、易扩展、低成本的分布式架构。

随着国家安全可控政策的实施,移动互联网的兴起,业务量的迅速提升,以及利率市场化所带来的成本约束日益显现,银行业信息系统采用分布式架构是大势所趋。近年来,农业银行在分布式架构方面进行了一些探索和实践。

一、概述

分布式架构简介

一般可以将架构分为两类,一类是以垂直扩展(Scale up)为主的架构,如通过增加单机配置,或者将中低端设备升级成为高端设备,用以提升系统的处理能力,称之为集中式架构,早期的哑终端主机架构是典型代表;一类是以水平扩展(Scale out)为主的架构,通过横向扩充节点,如一个节点扩充到多个节点,每个节点运行独立实例,节点与节点之间通过网络互连,随着节点扩充系统处理能力能够随之提升,单节点失效时,整个集群仍然可以对外提供服务,称之为分布式架构。

信息系统发展到今天,单一的架构难以满足业务量、数据量不断增长和业务需求灵活多变的要求,集中式架构与分布式架构不再是泾渭分明,往往处于融合状态,如农业银行全国数据大集中工程实施以前,核心系统部署在各省域中心,通过交换系统实现全行的业务联网,从全行来看,核心系统是一个分布式的架构,但从某个省中心来看,又是一个集中式的架构。全国集中以后,核心系统基于主机的并行耦合架构,将核心业务全部集中到一个数据库当中,通过耦合器实现内存共享,一般将其理解为集中式架构,但该架构本身也采用了许多分布式技术,如应用服务层、数据服务层、存储服务层均实现了多节点部署,单机故障不会影响到业务的连续运行,系统处理能力可以通过垂直扩展或者水平扩展提升。

优缺点分析

1、集中式架构的优缺点

集中式架构系统底层一般采用成熟的商业基础软件构建,这种架构的优点是成熟稳定,可用性、可靠性好,银行的技术人员可专注于业务功能开发,无需过多关注底层技术的实现。全国数据大集中后,农业银行核心业务系统交易成功率和业务连续性得到了进一步提升,产品创新与推广更为高效,业务量年均增长率近30%,至2014年底,日均交易量在2.6亿笔左右,峰值交易量突破3.2亿笔/日。自集中以来,虽然业务产品和业务量均大幅增长,但底层技术架构基本保持不变,运维更为集中统一,有力地保障了业务快速发展和生产的平稳运行。

缺点方面,一是风险度集中,虽然产品比较成熟稳定,但一旦出现软件或者逻辑上的极端异常,也有可能导致整个集群不可用,从而引发全局性停业。二是我国人口基数大,随着经济的快速发展,业务量在全球处于领先,许多新的问题、产品缺陷将有可能首先在我国触发。三是成本高昂,集中式架构对基础软硬件产品的可靠性、可用性依赖度高,这些技术产品基本被极少数公司所垄断,缺乏有力的竞争者,IT成本居高不下。四是核心技术受制于人,供应链风险较大。

2、分布式架构的优缺点

分布式架构按照一定的维度将系统进行拆分,通过一定的负载均衡机制,将业务分摊到多个节点上处理。这种架构的优点是可以采用更开放的架构,各节点松耦合,对底层产品的可靠性、可用性依赖降低,可以基于廉价的硬件和开源软件构建,受单一厂商的制约较少,可以引入多家厂商竞争,成本更为低廉,可用性、可扩展性更好。尤其是随着应用规模的扩大,边际成本将更低。

这种架构的难点是要做好各节点的协同工作,尤其是要处理好数据的一致性、完整性问题。根据CAP理论,在可用性、分区性与一致性三者之间,同时只能满足两个,如果要满足可用性(A)、分区性(P),就需要牺牲一致性(C),业界的一般做法主要是根据业务特点,通过较为复杂的应用设计,放弃实时一致性、保障最终一致性来解决该问题,分布式架构增加了应用设计和研发的复杂度。此外,随着节点数的增加和分布部署,对运维管理、异常处置也提出了更高的要求。

二、农业银行在分布式架构上的实践

随着Linux等开源软件日益成熟,X86服务器的可靠性、处理性能快速提升,虚拟化、集群、大数据、高速网络技术得到广泛应用,为构建分布式架构提供了有利条件。近年来,农业银行在主机和开放领域对分布式架构进行了研究和实践。

主机领域

以新一代核心银行系统建设为契机,农业银行对主机的架构进行了优化。

一是将交易路由层分离出来,采用独立的负载均衡设备实现交易的统一接入和负载均衡调度,减少了对主机的依赖,降低了资源消耗。

二是采用读写分离设计,构建主机开放融合架构,将查询类交易的应用逻辑处理下移到国产X86服务器上,通过DRDA方式访问主机数据库,从试点情况来看,交易下移后可比下移前可节省60%左右的主机计算资源消耗,效果明显。

三是将明细数据下移到开放平台上,基于Hadoop架构实现明细业务查询。

四是将可以下移的业务系统整体下移到开放平台,减少主机资源使用。

开放领域

全国数据大集中之后,农业银行大力推进集群架构、虚拟化技术的应用,采用Linux替代UNIX,用X86服务器替代小型机,引入集群数据库和MPP数据库,探索存储虚拟化应用,构建更加开放的分布式架构,同时加强监管控等运维平台研发,降低分布式架构所带来的运维压力,提升系统运维标准化、自动化水平。

1、农业银行开放平台分布式架构

下图列出了农业银行目前开放平台的典型架构,从应用接入层、应用服务层到数据服务层和存储服务层,均实现了分布式部署。

图1:农业银行开放平台分布式架构

1)应用接入层负责前端访问需求的统一接入,以及对后端应用服务器的交易分发和负载均衡,负载均衡集群采用软件或者硬件实现。通过应用接入层实现了前端对后端的透明访问,后端系统可以根据业务量和系统性能按需扩展,弹性部署。

2)应用服务层负责应用逻辑的处理,以Java和.net平台为主,集群中各节点基于对等结构,运行状态独立,任何一个节点出现问题,能够通过前端负载均衡集群及时判断和隔离,硬件层面全部采用X86服务器,2014年以来新购设备全部实现了自主可控,基于计算虚拟化实现资源使用的弹性伸缩。

3)数据服务层负责数据的存取服务,按类型总体分为联机事务处理(OLTP)和联机分析处理(OLAP)两个领域。

OLTP领域一般采用成熟的厂商产品,保持2-3家形成一定竞争,降低集中度风险。对于大业务量的OLTP场景,采用读写分离、联机与批量分离设计,或者按照一定的维度对数据库进行拆分,如网银系统,日均交易量已经达到上亿笔,单数据库处理起来压力非常大,按照客户等维度拆分成多个数据库,实现了数据库的堆叠和横向扩展,单个数据库异常对全局无影响或者影响极为有限。

图2:分布式数据库架构

随着X86服务器可靠性和处理能力提升,以及集群数据库技术的成熟,农业银行加大了X86服务器在数据库领域的使用力度,2014年,全国集中的信贷系统数据库从高端小型机迁移到国产X86服务器,日均交易量达3000万笔。在新一代银行卡受理环境系统建设中,全面采用X86服务器构建集群数据库计算环境,根据业务特点,进行针对性的设计,保障了数据库单点失效后的业务连续性。对于业务量不是特别大的场景,利用虚拟化技术,构建集中部署、有效隔离、弹性伸缩的数据库资源池,为系统整合提供了支撑。

OLAP领域,农业银行较早地实现了分布式数据库集群架构,2011年,以审计三期系统建设为契机,基于分布式数据库集群,采用几台X86服务器,实现了全行审计数据的大集中,管理数据达30TB以上,满足了上千审计人员的使用。基于此,将分析型系统的数据库部署架构全部统一到X86集群上。2013年开始,农业银行积极与国内主流厂商开展合作,攻克多个技术难点,构建了分布式的MPP集群数据库,目前最大的集群达到56节点,所管理的数据1.5PB,日作业量达40000以上。在业务逻辑相对简单或者非结构化领域,采用Hadoop架构满足数据分析需求,2013年底,核心系统明细查询业务迁移到Hadoop平台,满足了广大客户明细查询需求。

4)存储服务层

存储层主要是完成数据的存储、备份,农业银行主要使用的存储分为SAN和NAS两类,通过LVM镜像、存储复制、虚拟化等技术实现存储的高可用。在品牌方面保持3家左右的竞争,近年来随着国产自主可控产品的日益成熟,农业银行在国产SAN、NAS存储方面应用日益广泛。此外,基于服务器、万兆网络、固态盘和软件定义的分布式存储技术逐步成熟,农业银行也对其进行了研究和试点。

2、分布式架构与运维管理

分布式架构降低了单个节点对基础软硬件的可靠性、可用性依赖,通过架构来保障系统的整体可用性。但随着分布式架构、虚拟化等技术的实施,设备与系统数量快速增长,一个系统涉及的节点众多,为运维管理带来了较大的挑战。为此,农业银行在监管控系统建设方面做了大量工作,以提升运维管理的标准化、自动化水平。

一是在监控管理方面,大力推进基础架构与应用产品的集中监控管理,经过多年的建设,基本实现了计算、存储、网络等基础架构的7*24小时监控,对关键应用系统建立了端到端的实时监控,出现异常后,能够实现快速发现、快速定位、快速处置。

二是研发推广了自动化运维管理平台,实现了系统的批量部署、合规检查等功能。

三是研发推广了集中密码管理与行为审计系统,实现了密码集中管理、单点登录、行为审计。

四是基于ITIL流程平台,推广ISO20000等规范,统一了变更、事件、问题等管理流程。

三、未来展望

虽然农业银行近年来在分布式架构上做了一些研究和实践,但仍有许多提升空间。特别是农业银行正在建立两地三中心多活架构,以此为契机,将进一步提升分布式架构在多中心的应用。

一是主机平台上,深入研究业务特点和应用架构,将可以下移的应用和数据迁移到开放平台。进一步推广主机开放融合架构,扩大查询交易迁移范围,从核心系统业务类型来看,查询类交易占比达70%左右,如果能将大部分查询类交易移植到融合架构上,效果将更为显著。另外,以同城中心建设为契机,实现核心系统的同城双活部署,确保极端情况下的数据零丢失和业务连续运行。

二是开放平台上,通过对集群技术、分布式数据库、分布式存储等技术的深入应用,结合业务特点对应用进行精心设计,以同城和异地灾备中心建设为契机,将业务合理分布到多个中心,构建多活架构,进一步提升系统的健壮性和应急处置能力。

三是运维管理上,加强开发与运维的融合,持续优化完善现有的监管控平台,加强流程平台与自动化平台的融合,进一步提升端到端的运维管理标准化、自动化水平,提升问题发现、定位、处置能力。

总结

综上所述,分布式架构具有更好的可扩展性,对基础软硬件的可靠性、可用性依赖度更低,可以采用更加开放、廉价的产品构建。但我们也要看到其给应用设计、研发、运维管理所带来的挑战。总之,技术是为业务服务的,无论是集中式架构还是分布式架构,各有优缺点,我们需要根据不同的应用场景,选择合适的技术架构。此外,银行与互联网企业在信息系统建设上,无论是业务类型、风险容忍度、监管要求上,还是技术架构和文化机制上,有着较大的差异。确保客户资金安全和生产运行稳定,是银行信息化建设的首要原则,在分布式架构应用当中,要结合技术可控、风险可控、成本可控综合考量,要本着实事求是、稳妥前行的原则逐步推进。

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2015-07-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏美团技术团队

美团即时物流的分布式系统架构设计

美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点:

20420
来自专栏罗超频道

360移动搜索:周鸿祎玩微创新

6月3日360移动搜索App终于出世了。相关报道显示,360此前在移动搜索领域并非毫无作为,而是低调地进行广泛的布局:360浏览器、手机助手、安全桌面等产品都内...

30470
来自专栏技术博文

Linux哲学思想--基本法则

1、一切皆文件; 2、单一目的的小程序; 3、组合小程序完成复杂任务; 4、文本文件保存配置信息; 5、尽量避免捕获用户接口; 6、提供机制,而非策略。 自从L...

35280
来自专栏镁客网

热点 | 谷歌被曝收集用户隐私,Android、ios用户双双中招

据外媒报道,美联社最新调查显示,谷歌正通过旗下应用自动存储用户的位置数据,即使在隐私设置中关闭位置记录,也是无济于事。并且,此次中招的不仅仅是安卓机,只要用户安...

8110
来自专栏沃趣科技

从运管到云管,从离散走向集约

刚刚过去的火热七夕节,也恰巧是云计算诞生十周年纪念日。十年前的今天,Google创始人埃里克·施密特在公司年度战略大会上首次公开提出“Cloud Computi...

42460
来自专栏CDA数据分析师

如何在数据农耕时代做个好“数农”?说说数据收集埋点这件事儿

本文由CDA作者库成员王安原创,并授权发布 原文来自公众号数据化决策(Data_Driven_Decision)。 CDA作者库凝聚原创力量,只做更有价值的分享...

233100
来自专栏云计算D1net

六大神器助力SaaS公司留住老用户

不管你信不信,平均每个SaaS公司每年都会失去5 - 7%的用户。这太让人惊讶了,因为相对了如何留住用户,大多数SaaS公司似乎更加专注于如何获取用户。 但是为...

25530
来自专栏极乐技术社区

小程序一周报 | 小程序游戏类目开放测试 / 朋友圈小程序广告全量上线

15930
来自专栏web前端教室

【可能】nodeJs,到底能做什么?

这段时间的0621前端零课程讲下来,感觉我的学生们对于nodeJs是一种“无感”的状态,就是不知道学了node能做什么,不知道学习nodeJs的目标是什么。所以...

24960
来自专栏云计算D1net

云计算服务提供商不能会告诉你的秘密

云计算具有成本、资源扩展、弹性大等优势,但任何事物犹如硬币具有两面性,云计算也有一些你必须知道的劣势,服务提供商是想要把你所在他们的产品上,但并没有强迫你维持忠...

36430

扫码关注云+社区

领取腾讯云代金券