查看其它 1 个回答jxnxsdengyu的回答

jxnxsdengyujxnxsdengyu  系统工程师 , 江西农信

在金融科技背景下,对于传统银行的核心系统如何变革,如何进行新核心系统技术路线选型,依然存在不少困惑。新一代核心系统选型方向很多,这主要是不同银行对于核心系统定义的范围不同,其改造的难度、范围也不同,这点很重要。

目前已经完成改造的大行,都经历从过去以引进国外系统、自己消化改造为主,到自主开发建设的过程。国内大型股份制商业银行也大多经历的此类过程。所以可以看出,实施如此重要、难度的工程,逐步积累经验,形成一定规模的人员队伍是极其关键的。没有完全引进的系统,也没有完全合脚的鞋,合适的系统都是要自己参与的。

因此,建议根据自身业务规模选取业内比较成熟的构架,组成业务人员、开发人员、运维人员、厂商参与的项目作战团队,才好实施核心改造。架构选型目前已经有很多种成熟方案,适用不同规模和要求的银行。比如,就新核心基础架构而言有沿用传统小型机加SAN存储模式实现,也有基于虚拟化平台甚至容器平台建设。具体要看业主自身对业务连续性的要求,中小银行、民营银行倾向于互联网云平台模式。股份制和传统银行在核心选型上还比较保守。下面对具体技术路线的选择详细分类说明:

1、银行新核心系统基础架构技术路线选择方面

(1)开源技术方面

随着金融业务多元化的飞速发展和去IOE浪潮的推动,银行IT基础架构逐渐从传统商用技术架构向开源、分布式系统架构转型。分布式架构性能突出、扩展性好、资源利用率高等特点,可以为业务系统提供更好的性能和弹性。目前主流的分布式数据库、分布式存储、SDN网络、大数据技术均以开源技术为主,开源架构技术成本更低、效率更高、可以高度定制化、不再依赖于固定厂家的硬件和技术支持、开发和测试方法更为敏捷,所以各大企业都在极力打造以开源技术架构为基础的可用性高、性能突出、部署简单、运维高效、产权可控、成本低廉的IT基础架构。然而,在选择开源技术的时候,需要重点考虑以下点因素:

  • 开源社区的活越性:开源的出了问题只能靠团队的知识储备和社区,所以团队的知识储备还是非常重要的,有自主开发团队,可以大胆使用开源,不过确实得读读开源协议。没有开发团队,如果要是开源,购买服务商/集成商的服务能力来完善开源的服务;
  • 生态链的完整性;基础架构技术选型涉及到兼容性、安全防护、数据迁移、备份、容灾等均需要一个完成的技术生态圈支持,而不是单一的性能突出和功能完善。
  • 技术先进性和前瞻性;
  • 易用型和可用性;
  • 应用场景和成本;
  • 二次开发及维护能力;

(2)分布式架构方面

目前很多银行都在探索分布式架构的核心,以蚂蚁金服为代表的互联网公司也在同银行合作研究分布式核心架构,分布式架构的确是未来的一个方向,然而关于银行核心系统是否适合于分布式,对分布式的不同理解,会产生不同的答案。在分布式架构中,包括几个环节:分布式应用,分布式存储,分布式数据库。

新一代核心系统应用层逐渐实现分布式多节点运行模式,可以很好的解决核心应用单节点问题,可以告别传统HA主备机模式。分布式核心系统应用应该是未来主要的发展方向,优点很多,有条件考虑运行在成熟的商用虚拟化平台,甚至私有云平台上面。另外监管要求部分面向互联网业务要有计划迁移到云平台,也是一个很好的选用试用私有云平台的契机。

分布式事务数据库采用多种模式实现数据的分散存储,将数据库压力分散到不同服务器上。与集中式数据库相比,分布式数据库可以均衡交易负载,并采用高并发的架构提升系统的交易处理能力,而其统一的资源管理机制也使得数据库的性能扩展不再是设备的替换式升级,而是通过增加存储或计算节点来实现弹性升级。目前,分布式事务数据库在互联网应用场景下的探索取得了良好的成效和大量的实战经验,积累了很多成熟的技术应用经验。但是,相比于传统数据库架构,特别是对于银行核心系统事务的高一致性要求,分布式事务数据库架构更加复杂,难度更大,组成部件更多。通常,分布式事务数据库可分为中间件层、数据存储层和控制调度层。中间件层负责将数据按既定规则分发到多个数据存储节点上,并保证跨存储节点分布式事务的一致性;数据存储层用于数据的实际存储,执行原子SQL 操作和本地事务控制;控制调度层主要负责数据导入导出,备份恢复功能,以及对数据库集群的统一维护和管理。

(3)微服务架构方面

微服务还没有准确的定义,与其说是一种架构,不如说是一种理念。微服务的核心诉求是应用或组件独立部署,减少没必要的耦合。如果设计的好,会使一些业务变更不影响其他业务,甚至可以做到灰度部署。但是,微服务到底微到什么程度,则是架构成败的关键。极端的,有将一个系统的每个接口均独立部署,这会加大运维和管理的负担,没有必要。对银行核心进行微服务架构改造目前不具备技术条件,没有稳定的案例和强劲的需求不会对目前开发模式进行修改,各家银行的业务大体相似有各有不同,在没有对核心业务模块进行细致梳理和解耦前,目前可能不适于冒然做微服务架构改造。

2、银行新核心系统容灾架构技术路线选型方面

(1)新核心系统同城灾备的数据同步方面

数据同步类型分多种,有数据库级别、存储级别。数据库级别有日志复制方式和数据方式同步;存储级别,需要厂商的相关技术,如EMC的SRDF, IBM的Metrol Mirror等,IBM DS 系列存储也有自己的同城Mirror技术。

相比较而言,存储层数据同步属于比较底层的数据同步策略,灾备端将数据拉起到使用状态过程比较复杂,数据库层同步方式,在启用灾备端的过程相对比较简单可控。

(2)新核心系统同城应用级灾备方面

应用级灾备可采用两种成熟的方案,如VMware作为基础平台在同城双中心互联光纤条件好的情况下,可以实现跨中心VMware集群。保障平台上运行的应用VM虚拟机在两中心间HA切换或者在线Vmotion。甚至有用户实现跨中心Vsan,同时保障双中心数据一致性。因此完全有条件将核心应用部署在VMware平台。

基于Power平台PowerVC的LPM也是核心应用层的优异承载方式。采用中低端小型机服务器,例如Power S822/Power S922,构建应用资源池,统筹考虑软硬件成本,包括服务器、操作系统、虚拟化license、三年维保,总体拥有成本接近X86平台,但却获得了小型机的RAS特性。

银行 · 2019-03-15
浏览4115

回答者

jxnxsdengyu
系统工程师江西农信
擅长领域: 存储灾备双活

jxnxsdengyu 最近回答过的问题

回答状态

  • 发布时间:2019-03-15
  • 关注会员:4 人
  • 回答浏览:4115
  • X社区推广