当前位置:电子银行 > 正文
民生银行分布式架构实践分享

  一、分布式架构建设的背景

  这里面有一个背景是说其实在讲这个大概的背景之前,我有必要先稍微展开一下,我们的现状,我们的核心是2007年9月27号开始做的,用的老的核心,历时七年,大概在2013年5月27号上线完了,上线完以后,就会面临一个迫在眉睫的问题,第一个,老的核心我是亚太区第一家,也是全球最大的用户,一旦出了问题以后,需要原厂返修,第二个成本非常高昂,现在整个的一套核心技术,整个一套成本下来是八千多万,每年的运维成本,lisence的费用同样高昂。第三个就是随着用户的增多,lisence的费用又会随之增长。

  另外一点现在TPS最多每秒钟测下来差不多六千多,但是实际上我们每天对交易量差不多一千多万名,再往下我要么就用类似DB2的结构,但是这里面也有很多问题,这是我们面临的一个迫在眉睫的问题,当然分布式我们也知道,就说是这个银行这几年包括海量创新,极致快的业务需求,和传统的一些架构之间的矛盾,所以这里面也很多问题,基于此才是我们做整个分布式架构的初衷和背景。

  但是这个项目我也是已经银监会的指导,所以说我们在2014年我们也是获得国家发改委给我们的一个指导,我们在银监会的指导下,国家发改委也支持我们做这方面的一些探索,我们的目标是什么?我们的目标是希望,其实我在上次演讲里面也讲了,我们可能在座的都在银行,或者在金融行业做科技的,我觉得这个科技,我们今天面临一个很大的问题,

  第一,一家银行的科技怎么样才叫先进,没有一个标准,但我觉得从电信这几个方面,趋于先进性,先进性包括技术的先进性,它的架构的先进性,它的产品的先进性,第二个就是安全,我的数据安全,我的运行安全,我不出事,第三个就是效益,除了这些我觉得站在用户的视角,就是决策层觉得你投入产出好,支持整个业务战略的转型,用户可能觉得科技很好,快速引领我业务的发展,监管层觉得,你这个发展的很快又平稳,行业的用户觉得,你这个提供给我的工具我去拓展业务的时候武器很先进,但是最终还是用户体验好,我们能够给用户提供极致的用户体验,要让用户觉得,你这个用户界面很好,你的产品很先进,所以我是觉得,科技如何来实现它的价值,就是我们要希望能够达到一种极致的用户体验,海量支撑、高并发、高性能、弹性,业务连续性、降本增效,这也是我们希望实现的目标。

  分布式架构的历程我就不讲了,大家都知道,我们今天在讲大数据、云计算、人工智能、区块链,但是在这里面我是觉得,在每一个技术方向里面,我们要分清楚技术的干流和支流,有一些是干流,有一些是直流,我感觉在那个屋,我们跟华为有一个媒体采访的时候,大家还问到了很多区块链,其实大家知道区块链,我们在国内,我们跟招商两家都加入R3了,这两年我们也在做一些区块链的探索,但是坦白的说,我个人觉得区块链只是一个技术的支流,它不是干流。而干流是什么?干流就是我们的云,就是我们的大数据,这些是叫技术的干流。

  分布式也是,我们传统的架构基本上都是一种集中式的。谷歌当然为了解决每天海量数据存储的时候,研发出了分布式,这个分布式今天我们可能在各行各业都看到了,在互联网行业我们看到的最多,但是在传统的金融行业我们看得比较少,包括我们今天看到的无锡的太湖之光——现在世界上运算能够最强的超级计算机,每秒钟峰值达到12点万万亿次,平均也达到9.3万亿次,这些都是一种并行的架构,是分布式架构的实现。因为传统的机器的容量是有限的,但也知道,五大行用得都是大机,招商、中信、广发用的中型机,兴业、民生、浦发我们用得小型机,网商和微众他们用的是PC服务器,但他们的核心,网商和微众,他外围的系统用得分布式的架构,但他的核心仍然用的是集中式,不是分布式的,因为这个也可以理解,因为我要集中做上线,他们是有技术能够去做这个东西的,但他们也是为了集中做上线这也是没办法的,所以这是整个分布式架构的一个历程,我来讲一讲民生银行分布式架构的一个应用实例。

  二、民生银行分布式架构应用实例

  这个是一个整个的核心架构,在这个架构里面,我们可以分为几个部分,一个是分布式客户的管理系统,分布式阶梯管理系统,分布式凭证,还有我们的这种账户管理系统,以及我们对私、对公等等,都是整个的应用的架构,这个架构我不展开讲了。

  我们分层架构就是说我们希望分为几层,第一层是应用的一种分层,就说是在第一层里面我们是A层,A层里面我们主要是说来解决一个协议的处理,然后B层是一个组装,C层是原子的服务,D层是持久。其实大家都知道,没有分布式之前,我们常用架构是什么?我们通常用的都是外部serverless我们通常会加一些一个F5,F5做负载均衡。分布式就在于说,外部式serverless之后,就不需要走F5了,走的是一个软的东西,这个软的东西就是我们整个分布式里面最核心的东西,就叫分布式服务的框架,这个分布式框架是一个最核心的东西,这是一块。

  我觉得在这块框架我们大家知道,阿里有一套叫dubbo的东西,在2013年的时候,阿里将dubbo开源给我们,我们一看发现,设计的理念架构很先进,但是场景不一样,电商的场景跟金融的场景不一样,没办法,得重改、重写。

  所以说这里面有几个底层的一种框架,第一层最核心的就是一个分布式服务的框架,B层就是服务主张,C层原子,D层持久化,也就是说分为这四层,这四层里面分布式平台提供组建支持和核心应用,应外通过接口AP来使用一些组件。这个事情我们现在已经上线了,其实我们从2014年开始做的,这个事情也做了三年半,这个过程当中也趟过了很多坑,也是不断的实践,所以本来想去年11月份上线的,但去年11月份,刚好赶到我们29家村镇银行的核心要上收放了,要开放重叠到一起,一直到今年的1月23号,目前上完线以后,现在的情况是我把我们的一千二百万的电子账户迁过来了,电子账户不支持二三类,我们电子账户这个是直销银行是一类、二类、三类账户都有,为什么我们要迁过来呢?因为我们直销银行要独立,它要独立的话,他可能相当于成为子公司,他的核心系统必须要做,迁过来之后,现在的交易量大概多少呢?大概是一天一千八百五十万笔左右,我们现在整个的系统的交易量是一天差不多八千九百万笔左右。

  我现在正在做的一件事情是什么东西呢?我现在正在把我的底层的这一部分正在做改造,我们预计在明年的差不多九、十月份,我就把我的整个的老核心系统我就干掉了,直接全部迁到我们分布式上面,这是这样的一个逻辑。现在严格来说,我这个跑的核心,每天只有一千九百万。一千个百万也差不多了,因为我五年前,新核心上线的时候,我那个时候一天的交易量是两千三百万笔,也基本上差不多,所以这是整个一个逻辑。

  另外一点就是说,因为它可以提供横向扩展,所以说我上午也讲了,我现在就跑在24台华为服务器上,我也没存储,过去买存储,现在直接就是机器自身带的硬盘,然后机器坏了直扒拔掉重新换,所以说可以支持横向扩展,随便扩展,用的mysql的数据库,而且现在就说是核心业务单点功能我们可以按周交付,而且现在成本也挺好,原来的成本每个帐户两块二,现在六分钱,所以说这是整个的一个进展。

  下面我主要讲一下整体的架构设计,大家可以看到,他分为几部分,第一部分叫应用层,第二部分叫数据层,第二部分叫基础设施层,在应用层主要是提供一种多活的分布式服务的治理能力,还有这个批处理的作业能力,以及应用的监控的能力,分布式交易的服务能力。这里面分布式消息是非常重要的一块,但是多个服务器之间调度的时候,必须有一套准确的消息机制,我现在可以这样说,我在我所有的整个架构里面,我都实现了自主,我现在唯一没有实现的就是这个分布式消息。分布式消息现在我们要重写它,需要一年半的时间,我才能写,但我们时间有限,所以就这一块用的是阿里的,其他的东西全部是重写的,全部是我们自主研发,自主来做的一个事情,所以这是应用层。

  将来分布式消息这块是非常重要的,第二个就是一个分布式持久化能力和分布式数据库服务能力和大数据能力,分布式和传统的集中式架构在交易方面有一个最关键的一个区别就在于说,一个叫强一致性,一个叫最终一致性,这两个是有区别的,最终一致性叫什么意思呢?也许我这个交易跨越了ABCDE,我中间失败了以后,我有的实施要靠我自身的补偿机制来实验,所以往往会发现,咱们在讲银行架构的时候,我们讲分布式不是我光底层做个分布式数据库就OK了,那不行的,至少我认为在当下的数据库不行,也就是说,你把所有的希望寄托于一个点,分布式数据库来实现,我认为这是不完美的,你只能是什么呢?每一层都要分布式,就是最前端的全局的路由,分布式服务的框架,到中间这一层,每一层都要分布式,如果说我只是前面实现了,后面没实现,那你分库分表这一层就可以不要了,过去很多的分布式都有这种技术。在这里面,分布式持久化能力、分布式数据库服务能力、大数据平台,包括基础设施层都有这样一个。

  也就是说,这里面有几个分布式数据库访问,我上午讲了,我是说银行的应用场景,总结下来就分为这几类,第一类叫通道型的应用系统,什么叫通道型呢?手机银行、网银,这些都叫通道型,因为它只是一个过程记录,在这一层你完全可以做双活,你只要把一些全局的表,定期的一度的单做一个统一就行了,这一层是很好做的,这一类型叫通道型。

  你放两个数据库,放在两个机房里面,这个坏了,你把那个卡断,给他弄过来,这就很快了。第二个叫可以读写分离型的。因为银行总有业务场景,说白了,你梳理一下你每天top 10应用场景不就行了吗,对于读写分离型的,OK,你读写给他做一下分离,第三类,分库、分表型,有一些表,就是过一阵子他就变得很大怎么办呢?这种时候就需要分库分表型的。第四种,强账户依赖型的,所以你会发现,阿里在去IOE架构的时候你会发现它有一个最核心的账户,一定要最后去,为什么?因为你最终无论手机银行和干嘛,它只是一个渠道和通道而已,他进来以后最终你要落实到那个账户上,交易上,这个就叫强依赖性,你分为这几种场景,要针对不同的解决方式,这一种叫分布式数据访问。

  第二个分布式事物,你要知道,最终一致性和强一致性,强一致性就是我们传统的,就像过去我们大机上用的,也可以靠数据库来实现交易的一次性回滚。但是在分布式里面有的时候要靠一个,对分布式你要实现一个最终的一致性,也就意味着,当我发现有一笔交易有问题的时候,我要靠应用,我要写一笔交易把它冲正,把它补偿,分布式服务的框架与管控,这是非常致命的一块,也就是是说,我们通过服务的框架来做服务的访问限制和限流,服务的跟踪,我认为这是我们整个下一步要做微服务治理非常重要的一块。这也就是我刚才跟大家说的,目前在这块可能是国内阿里的那一块dubbo做得不错,但是dubbo他们现在内部好像也又用另外一套架构。

  分布式批量作业调度,大家都知道,银行每天晚上我要做批处理,第二天早上领导要看头寸、看报表,这个东西也非常关键,分布式配置管理,当有N台服务器的时候,这些配置传统的我要装机,交易中心这是最要命的,分布式缓存,以及我的交易的迷等性和统一的重正,在分布式环境下,我们要建一个全局的唯一的序列,几个核心的要点,我们可以看到,分布式架构的基础架构的设计,首先在服务的接入层,实现服务的路由及管控能力,支持服务与数据单元化部署,我们可以到在服务的接入层,包括服务路由,访问控制,服务的限流,交易的迷等性,以及在应用层我们实现分布式服务式框架,消息中心、注册全局系列,配置中心,分布式P处理的框架,这是这一层。因为我觉得今天来得都是咱们专家和行业的比较资深的,所以我讲到就不展开了,因为技术的细节我相信大家都影响是非常熟,再加上时间有限也就30分钟。

  第二个叫分布式服务,我们要建立分布式服务的框架,集成分布式消息及批处理的框架能力,其实在分布式数据库访问的时候,大家可以看到,我刚才讲的,你要根据场景,数据层、数据库有读写分离的,有分库、分表的,以及再往下就是我们整个的devops的分布式运维的基础能力来支持分布式应用的持续的集成和部署。

  关键技术,在这里面服务的治理能力分为服务的线上治理、服务监控、服务管理,服务的线上治理大家可以看到这里面访问控制,很重要的一块,黑白名单、流量控制、印花控制、故障处理、服务发现、服务路由、服务调度、负载均衡、服务降级,我刚才跟大家讲了,过去我们很多时候是靠传统的,传统的叫业务是靠什么?靠F5,但是F5里面,其实你对你服务很多东西的一些微观的治理可能就缺少,你看我们再举个例子叫做有一句话叫服务限流,叫流量控制。

  举个例子,我这一瞬间,当我出现一个瞬间的秒杀的时候,与其让我秒杀死,我还不如限流,有一些我就帮你进来了,这一些都是说我们包括这些黑白名单访问控制等等,服务的监控,包括我们的成功率,技术业务的失败率,交易量的控制告警以及链路的追踪,还有响应时间的异常交易,服务的SLA的评估,服务的管理,包括我们的服务定义,目录、定义、配置服务的全生命周期技术,服务的权限,容量的规划等等,这是整个的一个。

  这一套东西其实我觉得,我们整个下来,过去我们常常说,我们要做微服务什么东西,我觉得传统那一套架构难度挺大的,我们也是通过这一次分布式的东西,把整个的服务治理,相对来说从底层、架构层梳理的就比较清楚,其实这就叫做整个银行IP架构的一个底层技术的转移,涉及的理念我们可以看到这是技术的架构,在这个架构里面可以看到把每一个配置分离,动静分离,一点接入,集中管理,动态识别,动态赋能,也就是我们有一个叫做服务的消费者,也就是传统的服务应用,到我们的网关,到我们的服务治理的客户端,然后在整个的一套逻辑和框架,也就是注册中心是负责物理地址的注册,变更和变更时间的同步通知,配置中心是管理所有的静态配置,负载分摊应用配置获取的压力,治理中心是统一门户,所有超出的入口、承载,服务自己的流程,记录所有变更,变更时间的发起者,地址服务器是提供一点接入的,命名和身份识别的服务,实现组建动态附加能力,管理地址、位置和功能影射的关系,而且大家可以看到,在这一块,我们还有一个日志分析平台,过去,我们在上我们那一套核心的时候,因为我们自身的人员不足,我找了28家开发公司开发的,结果用了无数的平台,我在底层处理日志的时候非常痛苦的一件事,因为大家日志格式不统一,带来很多的麻烦事,我们在这次的时候,直接在底层一个大数据的日志分析平台。

  这个日志分析平台,我同时对这个日志分析平台在做运维的大事件分析,所有的事情都可以任何事件我觉得有了那个日志分析,我们是说风起于清平之间,浪乘于蔚蓝之间,所有的东西我都可以给他做一个预判和预测,过去我很难做到,解决问题,服务的接入要提供服务的统一入口,并将外部请求的路由的相应服务上,提供细力度的服务访问安全控制,确保系统的安全生产运行,提供多维度的服务限流,有效的来解决瞬间爆发的高并发访问,我们要支持交易的迷等性,防止同一笔交易重复处理,所以这里面也就几块,服务限流、交易幂等性、服务网关、访问控制,平台应用,这里面就是一个解决问题,分布式通信。分布式通信工业提供面向远程过程调用的服务框架和面向消息通信的消息中心。这个我刚才讲了,这个不是说传统的MQ了,传统的MQ更不行了,因为它本来就不是解决分布式,我们也看了市场上一些开源的东西,还是不行,所以说这个产品是非常关键的,分布格式的配置管理来解决分布式场景下大量应用结点配置管理和变更复杂的问题。

  分布式批处理,我觉得每家银行都有这个问题,批处理。因为交易量越来越大,系统越来越复杂,外界的模块越来越多,每个环节都会有可能造成你整个批处理的延时,所以分布式批处理也是非常关键的,集中应用于数据分布式之后批处理作业开发与运行的运行机制,配置中心难点解决问题,分布式配置管理解决分布式环境下大量应用结点配置管理和变更复杂的问题,他的难点是配置分发的延时控制和多结点的一致性控制,大家可以看到这样的一个示意图,也就是说,我们客户端一个应用,它根据本地的配置,去配置服务器批量下载配制多本地仓库,它要去注册中心、注册并监控,然后根据接收到的变更配置信息,然后再通过我的一些接口,然后去我配置服务端去下载,完了以后这个服务器所以说这是一个集成到管控平台的一个液面,这个也是一个重要的难点。

  数据访问,我们叫做分布式数据库访问,它实现数据库水平扩展,完成分库分表,读写分离的C口自动路由,对应用透明性能高,关于分库分表,市场上有这么几种工具,第一种就像我们原来最早用的是支付宝的分布式的访问接口,后来我们发现,做得挺好的,但是还是跟银行的场景不符合,因为电商的场景跟这个场景没办法,后来我们就重写。淘宝也有一个工具叫淘宝的分布式的数据访问接口,腾讯也有一个自己的接口,百度也有一个,这是一个很难的,你为什么做这一层,你不做这一层,你不就是单点了吗,你不就是传统的架构了吗?所以这一层肯定是要做的,这一层就叫做分库分秒的一个东西,所以说我们自己也是重写这一块东西,而且我们不光写了这块,还在最前端写了一层全局路由,这个分库分表,这个东西就是跟我们传统集中式的架构里面一个很大的不一样。

  有人会说我用一个分布式数据库也可以,但是分布式数据库有它一个缺陷,这个产品N年前就有,但是我觉得,现在我看到华为正在研发一个分布式数据库,我们现在也正在合作,但是我始终觉得,分布式的东西你不能把所有东西集中在一个点,你需要在每一层都做这个事情,因为我本身就是搞数据库的,所以说我对这个问题也是不停的在思考。分布式数据访问层,路由负载均衡,改写、执行、合并,管理的模块,再到后面高可用的数据库的数据库,写库、读库,分片、分区等等。

  应用的分库分表,解决的问题是数据库层支持横向的扩展,避免分布式事物应用透明降低运维的复杂度,这个里面我们也可以看到,我们产品的服务组建里面有ABCD,有N个业务的处理的单元,在这个业务处理单元,我们的客户的信息,我们的分区建,我们的分区算法都有,其实严格来说,就需要你对银行的场景,就像我刚才讲的,抓住主要矛盾,你每年梳理一下,你银行里面top 10的交易都是什么,对每一种交易的场景,对每一中业务的一个逻辑给它梳理清楚,找到一个每一种场景的一种最合理的一种方式。

  一致性保障机制,大家可以看到,本地事物应用微服务和组建化的设计思想,充分应用最大程度避免分布式收入。第二,幂的一致性,服务提供方,实现服务处理的幂等性,避免重复提交事物,最终一致性,就是说应用通过对帐,一致性检查等补偿手段来确定业务完整性和最终一致性,我们这一次里面最终一致性是我们用到的。所以,为什么呢?因为过去民生银行在上一代核心的时候是用SOA架构,客观传统的银行核心系统里面包括了很多,我们就不是的,我们的核心里面就包括卡,BP,MM和我们的存款,我把很多的支付就剥离出来了,还有安保也剥离出来了,我们过去就面临这样一个问题,我做一笔交易的时候,这个交易跨越了ABCDE5个系统,我做到A的时候,CDE还没有到怎么办,所以,当时就开发了一个异常处理平台,这个异常处理平台,一定要靠应用在前端补偿机制弄掉。所以,很多情况是分布式不是拿回来直接用,而是都是结合我们的场景来做一些这种开发和定制,自动化运维和部署提供分布式系统开发到运维全生命周期管理,提供分布式核心应用批量部署和变更,提供分布式系统的监控,预留管理控制台,我们要持续地集成,进行代码,每一日的自动的编译打包运行,根据编码的规范进行代码扫描并产生结果,自动执行代码的测试,应用发布,我们支持应用的多环境管理,支持应用的在线发布和负载均衡配制,支持应用版本管理,我们上完线以后,就像在直销银行手机客户端,我们完全支持白天都可以做这个事情。

  因为我是分布式的,大不了这个功能现在开放给一部分的用户,因为我过去一部分的架构很难实现,运维管理也就是说提供监控与日志管理,提供服务的跟踪机制,提供分布式系统管理控制台。容器元和大数据技术,解决问题,那么,基于容器实现一个全流程管理,支持多环境部署,实现应用环境的隔离,支持应用滚动的升级与发布,这个我觉得就是什么呢?我原来每一周发布一次已经够频繁了。但是也没有办法用,客户恨不得每天变更一次,还有,基于大数据技术实现日志的采集存储处理和更新就是我刚刚讲的,我们现在每一步在做的时候有一个统计的日志一个处理平台。

  就是交易链路核心业务尽量在同中心完成,关联应用交易数据同中心发布,交易链路非核心业务跨中心异步完成。单元划分,分成业务单元,以客户为统一维度进行交易链路的服务管理,分区的单元划分分区模式,保证核心业务客户均匀分布不同的分级单元,核心业务尽量自包含,共享业务单元不可以按照同一拆分为划分。然后,被核心业务高频访问,因为现在都是一种多活的一种架构,当然,多活是同城,异地很难做到,异地是一个网络的同步的延迟很难做到,但是,我们在同中心,我们在60公里的时候,做的就是这样的。所以,对于这种方式来说不存在什么呢?我那边出情况了,我就是能力下降了一点而已,这个是一种多活的。

  我们可以看到也就是说整个利用架构,数据中心A和B就是负载均衡,全局共享基于服务接入,全局系统,同城共享期,还有在底层。在没有做这个之前我们是怎么做的呢?因为核心已经上线了,上线了以后,其实最好的解决方案是什么了?是这个应用在上线的期间,就要把它的情况想清楚,在很多东西靠应用端实现,底层来实现,我们没有办法,核心政治任务要上线,上先了以后拿回来做测试也是不现实,我就是尽量不动业务系统,所以,我们做的就是数据库层面的,所以,这个在国内也是大规模批量应用,在60公里的地方每天就这样跑着,我最重要的系统就是这样跑着,有问题吗?有问题。什么情况之下?我发生链路抖动的时候有问题,我做大规模地批处理的时候就有问题,你不用怎么会积累经验呢?我们这几年用了几年,也积累了丰富经验,针对这个情况怎么解决,共享了该很好,我们传统情况怎么切换?我们编一个剧本,我们过来喊一声口令,这个就是某种情况之下是大家都明白的,你都是不知道什么时候会发生,这个就是传统。

  传统这个东西问题在于什么?把所有希望都寄托在数据库里面,这个里面还存在着链路抖动,今天用这个方式地层都是分库分表的,我原来做的方式就是像把rac放在同一机房,一跟线,10几米拉到60米,就是这样一个问题,今天完全是这个架构实现,不是有这个架构就可以随便弄,还不是的,还是尽可能地要把一些核心的业务能在同一个中心就在同一个中心,不可以在同一个中心就退而求其次,这些东西都是要开始都思考清楚的。

  我们看一下运维的支撑体系,分布式系统如何运维?包括核心系统如何运维?原来一个是分散,几百个分布式应用实例,单应用,几十台应用服务器,数据分散,N个库拆为N个表,M乘N个库,过去大家想想,我们做备份做灾备的时候有底层,第一层底层传输。第二层,要么我在数据层层面做一个,今天我们没有存储了,存储都是用在机器带的硬盘里面,这个分布在N上面备份怎么做?这个里面就比较的复杂。所以,数据分散,

  第二个,就是服务层次复杂,这个里面包括很多。路由,应用服务器,还有应用关系复杂,还有系统状态一个复杂。因为我们现在跑什么?我现在是这样的,因为3年之内准备把银行系统80%的系统分布式化,大家不要为了分布式而分布式,有一些系统就让他待着,为什么一定要分布式,所以,做的过程当中刚刚可以解决掉就解决掉。这个是这一点,我们民生银行有15%左右的系统是分布式,我今年明年做的科技三年规划里面希望可以解决70%80%的系统,这样我每年的成本都可以大幅度下降,应用,服务多,配制多,我们可以看到,我们要解决一个服务治理,分布式管控平台,应用的查询,运维的试点,硬件,起动监控平台,运维操作的自动化,持续交互,分布式一个平台,机房切换一个自动指挥平台,应用排除可视化,实时交易分析,实时链路分析,运维架构可视化,还有云服务系统,包括服务跟踪的智能化,日志分析一点清,还有服务跟踪,我们做到这样一些体系。

 

  第一个运维操作自动化,快速起动时间,172个硬实例实现秒级流量切换,今年春节最后一天,我们董事长觉得这个分布式核心做的比较好,就到这边来慰问一下大家,请大家酒吧,我们去机房现场切换一下,白天现场可以做这个事情。过去不会这样的,过去还是有一点难度的,这个是这个,可以秒级别地切换。应用集,主机集,集成集和机房集,可信部署,结果,部分包括自动对这个进行检查,这个里面是这样一个层次结构,大家可以看到,运维管理集中化,这个是针对运维试点,这个里面有一个视图,这个里面可以看到整个数据存储做的分布分表,一个表1024张,不一定非得1024张,这个都可以的。只不过我们表比较大,数据库做了集中查询,1024表可以视为一张表等等。

  其实这一块儿东西不知道原来大家有用过吗?传统数据库都是有一些产品,有一个DPF的一个产品,它其实就是解决什么呢?就是N年前一个产品,就是一个分区的,但是那个时候更多解决一个数据仓库,数据仓库,这个消息机制比较的复杂,他更多是面向一个ORUP应用,如果假设里面东西比较多就有问题了,这个消息广播连接非常的复杂,还有一个技术可视化,我们可以看到,我们第一步可以看全景,看系统之间一个调用感到,系统下一个交易量,点击系统的视图,第二查自己,性能分析,交易量分析。第三步,追别人,交易的系统调用关系,各个步骤的耗时,二维码,交易在各个系统的耗时分布,这个就是一目了然,所以,这个是整个这样一个节奏。其实大家也都是知道,我们现在有很多的行也用一些流量分析的软件,市场上面也有的但是,他这个是第一个层次,如果你要想深入地来去做,没有标准的产品,只可以靠自己。首先要有足够的信息做资源化。组件的功能, 这个追踪每一个完整的链路,包括应用链,消息中心,数据库等跨接点的调用,收集调用链路每一次调用出入差,用于异常分析,收集链路上面每一次调用的性能数据,这个就非常的方便,我排错的时候。

  现在提了一个要求,为什么呢?因为我原来是数据中心老总,后来不小心当了老了,我就提了一个要求,你必须要双10,你必须要10分钟之内找到问题的原因,10分钟之内解决,要求比较高,但是,只有高压力人才会有动力。我给你说,我过去那种架构做不到,但是,一种新的架构里面,因为很多东西可以写的很详细才可以这样做的。所以,架构实施建议,改造要点,科技业务能力分层,渠道层,客户场景服务层,集成层,产品层,数据层,技术开放能力层云化资源层。

  第二,应用业务要分类,哪一些是渠道型应用,什么是分离型应用。配制型应用,什么是状态应用?分布,分秒型,多活,举一个例子。安保平台,这个系统就是典型的查询非常的多,相对非常静态的,你不可以把跟网银系统分一起,这个都是有不同的讲究的。其实银行系统要说它简单,他还是不简单。但是,做一个统一方法分论,这个逻辑梳理出来,应用拆分,状态型业务功能下沉,实现应用层无状态化,第一阶段,就是架构的X86改造,第二,就是云化基础设施改造,第三云化服务。设计的原则,总则,就是进行垂直平分切分,这个大家可以拍下来,今天讲的都是干货,都是三年半过程当中实际过程当中做的一些探索,很多事情也是知易行难,道理明白了,做的过程当中怎么做都是难事情,所讲的东西都是高度提炼一个总结。进行一个垂直垂平切分,垂直切分优先,并尽量分拆成流水型应用,状态型应用,状态型业务集中下沉,垂直切分原则,业务高,子系统兼数据隔离,原服务能力可以由子系统独立完成,水平切分原则,就是客户为度。同一个客户关联放同一个数据库里面,统一交易原则服务操作同一个风险业务逻辑,这个里面包括总体的工程,建议副工程,连接交易工程,公共工程,每一个工程有接口实现的这个过程。

  以及整个分布式的架构,这个里面大家可以看到,整个的一些接入层,包括业务服务层,包括应用技术开放能力层,包括一个云化资源层,这个是这样一个愿景架构。

  三、分布式架构实施建议

  因为时间有限,也只可以做这么多的分享。我们是希望可以走这样一条路,其实中间因为我本人是核心小组的组长,所以,还是有共同的感悟。因为常常觉得互联网公司,有的时候觉得不一样,场景不一样,就是我们面对的很多的东西都是不一样。所以,实际上在做的过程当中会发现有一点复杂,另外一点,今天我们也是抛砖引玉,希望大家到我们民生银行交流考察。谢谢大家!

(文章根据会议记录整理)

相关链接:

作者:牛新庄 来源:互联网金融工作委员会 发布时间:2018-06-20 08:10:19
 
 
  我要发表留言  查看所有评论
 

*
 限制字数显示剩余字数,最大长度: 500 还剩: 500
用户名:
       尊重网上道德,承担一切因您的行为而直接或间接导致的民事或刑事法律责任