• 快捷搜索
  • 全站搜索

构建以分布式为核心的央行服务平台

2017-07-25 10:46:29作者:中国人民银行南京分行副行长 张奎编辑:金融咨询网
为进一步提升“十三五”期间人民银行的履职能力,适应内部业务创新和外部金融服务需求的快速变化,传统的集中式信息化架构必须加快朝着灵活、可伸缩、高效稳定、安全可控特征的新型技术架构转型。

为进一步提升“十三五”期间人民银行的履职能力,适应内部业务创新和外部金融服务需求的快速变化,传统的集中式信息化架构必须加快朝着灵活、可伸缩、高效稳定、安全可控特征的新型技术架构转型。人民银行南京分行提出以容器和分布式技术为核心构建央行服务平台的总体规划以及阶段性目标,并总结了架构转型过程中的阶段性成果及下一阶段工作。

图片1.jpg
中国人民银行南京分行副行长 张奎

南京分行信息化建设现状和存在的问题

        1.建设现状

        在总行科技司的统一指导下,经过多年的发展,南京分行信息化建设取得了一定成效:一是完成了“省级数据中心基础环境‘云’化工程”。南京分行先后完成了主机虚拟化、存储虚拟化等一系列数据中心“云”化基础环境建设,保障了总分行多个业务系统的安全运行。二是拥有一支实力较强的开发运维团队。在多个自建业务系统的建设开发过程中,涌现出一批能力突出的开发运维人员,为分行数据中心由传统管理模式向云平台化管理模式转变提供了智力资源。三是完成部分重要信息系统灾备建设。先后建设完成了营管部同城灾备中心和苏州中支异地备份中心的建设任务,初步实现了“同城数据双活”。

        2.存在的问题

        基础设施资源利用不均,缺乏弹性。省级立项项目均采用虚拟机集中部署于省级数据中心。一方面使省级数据中心各类基础资源紧张现象时有发生,另一方面各地市中支的基础资源使用率相对较低。同时,基于虚拟机的部署方式也存在弹性伸缩较为困难的问题。

        项目建设缺乏有力的架构管控。由于缺乏有效的架构管控手段,各系统包含了大量功能类似的模块,造成开发资源的浪费。同时,各类数据分散在不同系统中,不利于数据资源有效整合和深度利用。

        应用系统架构落后,需求响应不及时。采用单体应用架构构建的系统,各功能模块耦合度高,无法独立扩展。需求变更时,修改系统也较为困难。随着分析型、交互型应用系统建设需求的增加,单体应用架构必须向服务型应用架构转变。

        项目建设缺乏统一的管理平台和开发环境。随着项目建设复杂性的增加,系统开发往往需要由多个分支行协作完成,由于没有统一的开发管理平台,且各单位开发环境也不尽相同,使系统开发测试环境的搭建、代码提交后的测试、生产上线的部署存在大量重复性的工作,耗费大量精力,协同效率较低。

南京分行新型技术架构规划

        通过研究金融科技和互联网发展趋势,梳理南京分行信息化建设现状和存在问题,结合人民银行业务发展新要求,南京分行提出未来3~5年的目标技术架构是:在以虚拟化为基础的IaaS私有云之上,基于容器技术和分布式中间件构建适用于人民银行分支机构的云服务平台,形成高效稳定、弹性伸缩、安全可控的分布式服务型系统架构。具体目标技术架构见图1所示。

图片2.jpg
图1 目标技术架构图

        1.借力虚拟化技术,提高基础资源利用率

        (1)IaaS层主要规划设计

        继续完善以虚拟化为基础的软件定义数据中心的建设,实现计算资源、存储资源、网络资源的综合管理和交付。其优势在于:首先,基于虚拟化的IaaS云依然可以满足目前人民银行大部分遗留应用系统的部署需要,也有利于保护既有投资。其次,在完成服务器虚拟化、存储虚拟化的基础上,进一步研究网络虚拟化的应用,从而完成软件定义数据中心的“最后一公里”。最后,虚拟化后的IaaS层统一交付计算、存储、网络资源供上层使用,降低了基础设施管理的复杂度。

        (2)容器集群管理层主要规划设计

        容器集群管理层在IaaS层的基础上,按照一定的策略对全省IT基础设施资源进行统一管理和分配。应用系统容器化封装后,由容器集群管理层进行编排和管理,分布运行在IaaS层的任意位置。同时,容器集群管理层需根据应用实际运行情况进行动态调整,实现应用容器部署的弹性伸缩。

        2.转型分布式架构加强架构管控

        (1)分布式中间件层主要规划设计

        分布式系统是一个非常广泛的概念,它最终要落实到解决实际问题上,不同问题有不同的解决方法和架构。总体而言,可以分为有状态的支持持久化存储的“分布式存储系统”和无状态的“分布式计算框架”。构建分布式中间层的主要目标是实现应用和数据的分离,为上层应用提供稳定、可靠并且可动态扩展的基础服务。

        以分布式数据库为例,需要构建统一的分布式数据库服务平台,为各类应用系统提供高效、可靠的数据管理服务。该平台应至少具有以下特点:一是SQL兼容性,提供对SQL的完整支持,能较好地与我行大多数应用系统以及第三方数据分析类产品兼容;二是透明性,用户不需要关心数据的分布细节,不需要因此编写复杂的数据访问逻辑;三是一致性,保证多节点间数据的一致性;四是横向扩展能力,在容量或者处理能力不够时,可通过添加服务器扩展;五是高可用性,数据具有冗余性,部分节点故障不影响服务可用性;六是多租户管理能力,平台能在多用户环境下提供可靠服务,并确保用户数据的隔离。

        (2)业务服务层主要规划设计

        业务服务层分为两个中心,核心是数据服务中心。数据服务中心以大数据平台为载体,通过运用批量/离线计算、流式计算、机器学习等大数据先进技术和理念,破解当前人民银行系统存在的存储资源不足、计算能力不足、信息孤岛等问题。数据服务中心对结构化数据和非结构化数据实现海量存储,提供批量或准实时计算、分析,数据模型计算等功能。

业务服务层中的基础服务中心提供南京分行自主建设的基础服务功能。包括统一用户管理服务、统一报送服务、金融机构编码服务、报表和BI服务、即时通讯服务、搜索服务等。业务服务层中的各项服务未来将按功能划分为组件服务、业务服务、公共服务等。业务服务层与分布式中间件层为上层应用提供了稳定高效,可扩展的基础架构,打破了数据孤岛,有效解决了架构管控能力不足的问题。

        3.快速响应用户需求,为互联网应用打基础

        (1)应用服务层主要规划设计

        该层的主要功能是为传统应用和云原生应用提供服务化架构管理能力,经过服务化改造的应用服务互相调用,整体上完成对外服务。应用服务层改变了以往无论项目大小,全部从零开始的建设模式,同时也解决了原单体应用架构下无法快速响应用户需求的问题。

        (2)用户接入层主要规划设计

        目前银行信息系统的接入渠道主要是通过业务网、办公网、专网、互联网以个人PC电脑接入为主,缺少移动智能终端设备的接入和服务。随着智能终端的普及和广泛应用,智能终端成为重要的服务渠道。用户接入层将处理大量异构客户端的访问路由和负载均衡。应用服务层和用户接入层的建设,可适应互联网项目“需求多变、响应迅速、访问方式多样”的开发要求,为今后人行互联网应用建设打下基础。

        4.建立协同工作环境,提高科技工作效率

        (1)开发运维一体化平台主要规划设计

        该层的建设目标是构建开发测试运维一体化平台,统一全辖开发测试运维工作流程,助力全省一体化运维团队的建设。平台功能包括:项目管理、代码仓库、质量管理、组件仓库、测试管理、配置管理等。

        (2)统一管理门户

        统一管理人员和权限,提供云服务平台的自助服务功能和管理审批功能。开发运维一体化平台及管理门户的建设,可解决开发和运维过程中环境不一致性问题,减少科技工作人员的重复性劳动,同时提高全省协同工作效率。

架构转型阶段性工作成果

        1.开展云平台技术验证

        一是研究云计算相关技术。对容器集群管理平台进行了测试,其中包括商业方案和开源方案。验证了集群管理、弹性伸缩、镜像仓库等功能,证明容器云方案技术上可行;初步研究了SDN(软件定义网络)的相关技术,测试通过BGP、OSPF等协议将支持OpenFlow的交换机与传统路由器对接,协议处理可由SDN控制器来负责完成。证明传统网络与SDN网络共存互通是可行的。二是制定了南京分行IaaS私有云建设方案。与国内云平台厂家进行了多次交流,对服务器虚拟化、存储虚拟化、网络虚拟化和高可用等方面进行了深入探讨,对云平台所需服务器、存储、网络等设备技术指标进行了细化。

        2.开展开发运维一体化实践

        首先,引入DevOps理念打通开发和运维。利用自建项目建设契机,在开发过程中尝试全新的开发策略,采用DevOps模式的基本原则及流程方法,并基于容器技术实现系统交付,为解决目前人民银行分支机构科技部门在开发和运维上遇到的协同问题,做了有益的尝试。其次,初步实现持续交付流程,快速响应需求变更。采用开源工具链建立了一快速开发、测试、发布应用的管道,为业务系统的持续优化打下了基础。

        3.完成开源分布式系统测试,逐步完成产品选型

        一是实现了由开源软件搭建云存储平台的方案。该方案不但能满足数据分布式存储的需求,而且能提高存储的容错能力和扩展能力,降低数据中心的硬件维护成本。二是对多种分布式数据库产品研究。其中包括基于MySQL的中间件分布式数据库产品、开源大规模并行(MPP)数据库、以Google Spanner/F1为理论基础的NewSQL数据库等。这些产品均提供SQL兼容性支持,并能在ACID基础上实现数据库的分布式特性。同时,由于相互迥异的设计理念和软件架构,它们在不同数据规模、逻辑复杂度、应用场景下,又各自具有鲜明的特点。在实际构建分布式中间件层时,我们需要结合应用场景,选择合适的产品甚至加以改造来满足需求。

        4.验证分布式服务架构的可行性

        将按照服务型架构开发的云资料检索系统在南京分行、苏州、常州三个数据中心进行容器化部署,初步验证了分布式服务架构的可行性。

        5.开展大数据平台技术测试,形成后续规划

        一是基于金融机构编码信息库的建设任务,开展大数据平台功能验证和海量数据性能测试。测试结果表明,相关产品基本符合功能和性能需求。二是整理关键问题,形成大数据平台整体规划方案。

下一阶段工作规划

        1.开展容器安全性研究,确保安全可控

        容器技术发展如火如荼,与相关的安全技术也在不断推进。然而容器依托于Linux内核的LXC技术,辅以资源隔离技术隔离各个容器进程,其共享系统内核的模式较虚拟机这种独立内核的模式在安全性方面存在一定的降低。我们将从技术和管理两个层面开展研究,确保云平台的安全可控。

        2.明确云原生应用架构,制定开发测试规范

        一是需要明确云原生应用的技术架构,为新开发应用充分利用云能力提供指导。二是对云原生应用架构下的开发、测试、编译、集成、打包、部署、升级/回滚/卸载、状态监控等完整生命周期的各个阶段制定规范。

        3.云服务平台建设各阶段任务

        一期初步搭建基于开源容器集群管理系统的开发测试环境。二期完成包含分布式数据库、分布式存储、分布式缓存等中间件层的构建。三期搭建日志监控和自动化运维平台。四期完成云平台管理门户的开发。

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

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

本文评论

相关文章