民生银行信息科技部资深专家黎育龙:民生银行分布式建设实践

近日,在一次金融分布式架构技术研讨会上,民生银行信息科技部资深专家黎育龙进行了题为“中国民生银行分布式建设实践”的主题发言。

发言分享:

我分两部分跟大家汇报一下:第一,民生银行在分布式建设方面的成效;第二,分布式技术的交流。

为什么我要先和大家介绍一下分布式介绍的成效呢?民生银行的核心系统用的是德国SAP系统,SAP系统原来是ERP里的核心系统,并不是存款产品。当时民生银行在做新一代的时候选了这个系统,但目前来看突出了很多问题,比如说在容量和交易量的增长上,在硬件成本上持续上升,授权费用特别高等问题。

SAP是传统集中式架构,没有扩展性的,数据库是单点的结构,是基于DB HA架构,总体来说性能达到了瓶颈。

国内大部分银行都有这样的问题,我们的交易量是全世界第一的,我们作为SAP核心系统的客户也是这样,我们面临的很多问题在他们德国实验室也是第一次面临,所以很多问题需要优化时都要提到德国开发中心去,流转流程特别长,根本达不到交付的要求。我们自己后面也培养了很多SAP的专家,但是跟我们的期望差距还很大,并且技术是封闭的找不到人,基于这些压力我们觉得要把核心系统重新做。

在2018年1月份时存款核心上线了,分布式改造上线对我们来说意义很大,实现了民生银行技术架构的转型,全行都向分布式架构转进。通过此也沉淀了分布式技术体系、架构规范、分布式设定模式,用于支撑全行分布式架构的改造需要。

另外在现在金融压力的大情况下实现了降本增效,所有服务器全部是X86服务器,也提高了资源利用率。另外现在很强调自主可控,系统是我们自主研发的,所以完成了自主掌控,也摆脱了对厂商的依赖。

在业务方面能够支撑10亿级客户容量,并且能够在交互方面按照周来做功能发布。单帐户管理成本从SAP的2.2元降到6分钱。通过项目的建设我们得到了国家银监会、人民银行的很多奖,也申请了18项专利。

讲一下分布式具体机制的交流,我们觉得科技金融的关键基础门部式肯定是一个方向,无论从外部来看市场环境、国家战略、行业背景,还是从内部核心系统、成本控制、把控能力上都需要走分布式架构的这条路。

原来民生银行是集中式架构(存储+小型机(主备灾)),现在全部的服务器都是X86的,可以实现流量灵活调拨,并且做到横向扩展,也可以实现多数据中心多活的架构。

我们启动项目是由2014年四部委联合发布“分布式技术与金融云的研发与探索”,当时民生银行以分布式核心作为项目去发布。这是当时建设分布式核心的几个目标,要打造国产化自主银行系统,另外要建设全行分布式架构能力。

在实施策略上先建设了一套分布式技术平台(DAP)平台,以分布式核心作为第一期试点,下一期把SAP核心存款全部迁移过来,应用核心系统直销银行在2018年1月份已经上线投成,目前预计比较平稳。

其实直销里也有一类户,传统SAP里的现金重空管理在今年1月19日也会上线,明年年底全量SAP直接下线,全迁过来。

对分布式架构整体能力规划分成三层,目标是要实现全部资源弹性扩展能力:

第一层,基础设施层,在计算能力、存储能力、安全、云管理等实现弹性,现在用了容器化技术。

第二层,数据层,实现弹性计算能力,在存储引用了对象存储、分布式文件系统、文件传输、分发、非结构化等都已经做了改造,运维管控运维服务能力实现了分布式事务、分布式平台的功能大数据作为分布式建设方面,包括分析计算、实时跟非实时计算。

第三层,应用层,实现了单位化多活的分布治理能力,有多活的分布式接入层,以及服务的注册发现、服务的配置管理。批处理方面建立了适配分布式架构建立了相应的平台,可靠消息发布能力。同时有开发运维管理能力,实时工艺、规范文档等,和DevOps体系在一起配套建设。

银行最重要的是业务连续性,所以我们把高可用的能力根据三层架构进行分配,在基础设施层能实现云化资源、虚拟化。在数据层通过客户分区和分库分表分散风险。在应用层通过微服务化的解耦应用、无状态支持快速扩展,通过流量控制、服务降级、客户分区多活的方式实现应用层高可用的能力。

民生银行在分布式建设过程中沉淀的分布式技术平台,技术平台主要沉淀了几项能力:

1.分布式数据访问(CDAL);

2.分布式事务;

3.分布式服务框架;

4.作业管理;

5.配置中心;

6.缓存等。

这就是分布式平台提供的能力,所以分布式应用是在平台上进行建设的(长在平台上)。

平台分为四层架构,最下层的DevOps是配套的管控,在分布式平台上主要分成接入层、应用层、数据层,接入层主要负责一些服务接入、流量调拨,在应用层配置管理、流水、配置中心、技术中心、应用还有全局路由、全局区列。数据层主要是通过独立的数据件实现了分布数据读写分离的能力。

这是在建设分布式平台时实现的同城双活单位化架构,把应用分成三类,有点类似于传统银行3A、AQS、ASS)架构,我们分成全局区、机房共享区、分区单位应用,通过应用的切分实现了全行应用单元化多活架构,这样所有的数据中心都是对外提供服务的,任何一个数据中心的故障都不会造成全行整体应用的不可用,并且目前在同城能实现RTO接近于零的容灾切换。

在去年春节前的时候董事长视察时还做过一次毫无任何准备切换,切换在瞬间完成,无一笔失败。

民生银行的技术架构在核心之前是有支付引擎,还有NPS,NPS是指非帐户类的交易系统,往下是存款的核心,里面有客户信息、对公存款、对私存款、卡管理、帐户管理、管控等,这里面实现了产品工厂的能力。核心业务都可以通过产品分享进行配置化的上线。

分布式核心核心应用分层架构分成了ABCD,A层是协议层,B层是组合交易层,C层是原子层,D层是数据访问层。在B层进行服务的流程组织,全部配置化,所以通过这一套层级架构切分新业务功能可以按周上线。

简单介绍一下在分布式建设中主要做了哪些关键的能力建设。

在服务接入方面建设了服务网关、服务限流等。平台应用主要建设服务框架、配置中心、批处理框架、消息中心。消息中心目标完全基于开源自主开发的。

服务框架描述的模型是服务注册和发现的能力,主要解决服务的调度还有服务最高发现以及软负载和容错能力。配套的服务框架里落地了服务治理能力,主要实现线上治理、服务监控、服务管理。线上这部分能力基本上全部是在服务框架里,有故障的隔离处理。监控是在服务框架层面、服务治理SDK里进行数据的采集。

民生银行原来也是有很多异构架构,协议也不是完全统一的,所以做服务治理的时候分布式可以直接通过治理框架来接入的,但其他的还有服务网关有点类似于Service Mesh架构。整个治理方面管控端的监控、分析、配置中心、治理中心、监控中心等全部都是企业级的。

数据访问层是自主开发了一套CDAL,能够实现数据分库分表和读写分离的能力,提供了两种方式:

1.SDK,SDK是直接和应用打包在一起的,可以使用负载均衡、SQL解析、SQL重写、SQL路由、SQL执行、结果集聚合合并等。所有的数据库分布分表对应数据访问层也有一套管控平台,里面是企业级多租户的架构,可以通过界面化的勾选配置实现。

2.CDAL Proxy,这和SDK能力上是差不多的,但更强大一点,可以独立运行实现多套应用共享、资源共享的方式。目前共享部署上并不是很推荐这种方式,因为很多时候不同的应用开销资源是不一样的,要做到资源完全隔离风险还是比较大的,目前还是一套应用部署一套。

为什么要建设这个呢?有些应用没法进行重写,如果有中间件存在的话可以把分布式改造屏蔽掉,应用基本上可以实现零修改实现分布式数据库的分库分表和读写分离能力,在存储引擎方面我们可以支持MYSQL、Oracle、DB2。使用CDAL Proxy后,应用可以在面对多个数据库存储时,就像面向一个数据库一样。

原则上讲要避免分布式事务的存在,建议CAP里追寻AP,尽量柔性思路和最终一致性。在能力上支持可靠消息的最终一致性和反向处理策略。现在我们发现只是基于这一套东西有很多问题,因为某种意义上就是把复杂性抛给应用开发了,我们自己在开发一套分布式事务框架,尽量把分布式事务复杂性从应用中剥离出来,只是在做的时候比TCC做的简单一些和少了一些浸入性,我们把这一块儿给剥离出来。

分布式消息中心,是基于开源技术开发的,但是结合了金融场景,比如说有些时候并不是所有产品都是组件对组件或者说系统对系统的,比如,有些时候需要客户跟客服人员要进行一对一的消息传递,需要更贴近银行业务场景。因此我们的消息中心,不仅是一套消息中间件,更是一套EDA的架构,并且完全贴合银行业务做的工作。

同时,我们也建设了一套DevOps体系。简单谈一下分布式核心运维体系,分布式系统怎么运维?

一开始在建设过程中我们发现挺复杂挺多挺麻烦的,跟原来集中式比设备肯定要多,应用也要多,因为我们使用的是微服务的架构,服务、配置肯定要多的多,微服务后原来的传统核心是整个存款都放在一起,但现在只是把核算放在外面,在这样的情况下应用有16个。

无论从建行体系还是民生体系都有全局路由、交易分发,微服务之后所有的服务是一个串一个或者一个串好几个,交易的组合顺序也不一样,系统状态复杂性要多得多,因为流量是在多数据中心之间进行切换的。

因此,我们建立了十大运维工具:运维管理集中化,基于CDAL进行开发;自动化工具;交易监控平台,云服务系、全链路跟踪系统等。通过ZIPKIN,不仅在服务链路上做到全链路跟踪,同时还可以做到服务方法级调用。简单总结一下十大工具,主要想做到的能力是全面掌控、精确定位、快速响应,防患于未然。我们数据中心给我们的要求是“双十”,十分钟定位问题,十分钟解决问题。

(来自:金融科技创新网)

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181213B10QZ200?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券