工行“去O”数据库选型与分布式架构设计

工行“去O”数据库选型与分布式架构设计
www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

本文根据魏亚东老师在〖deeplus直播第225期〗线上分享演讲内容整理而成。

www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

魏亚东

工商银行软件开发中心经理

  • 中国工商银行软件开发中心三级经理,资深架构师。杭州研发部数据库专家牵头人和开发中心安全团队成员,负责技术管理、数据库和安全相关工作。
  • 2009年加入中国工商银行软件开发中心,致力于推动管理创新、效能提升,提供全面技术管控,推动自动化实施,实现业务价值的高质量快速交付;同时作为技术专家,为生产安全提供技术支持。

大家好,今天分享的主题是金融行业分布式数据库需求及选型。

本次分享分为3个章节:

  • 一、金融行业的需求核心与策略;
  • 二、工行数据库选型的发展历程,即方案选型历程;
  • 三、转型中遇到的各种心酸坑。

一、金融行业的核心需求与策略

1、传统IT架构挑战

大家可能都知道,工行最早是基于IBM大型主机搭建的核心系统,以及基于Oracle和IBM WAS搭建的OLTP系统,在分布式体系大热之前处于同业领先地位,当然现在也是处于同业领先的,但是科技成本也相对较高,所谓的一份价钱一分货就是这个道理。

www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

但是随着分布式技术的成熟,传统的IT架构面临着4大挑战:

1)从处理能力层面来看,传统应用(也叫巨石型应用)系统规模庞大,采用集中式架构设计,使用单一系统垂直扩展模式,扩展能力相对来说是有限的;另一方面,大数据时代引发海量数据分析处理和存储处理的问题,对扩展性、可靠性和吞吐量提出了较高要求。

1)从运行风险层面来看,客户对金融行业的系统有着更高的业务连续性保障要求,对不可用问题实际上是零容忍的,比如要求7*24小时业务不能中断。

3)从快速交付层面来看,传统巨石型应用实际上与快速交付是相悖的,应用内部模块、应用与应用之间耦合度高,使得软件开发和产品服务交付周期长,无法满足业务快速上线的需求,从而逐渐泯然众人矣,淹没在茫茫的金融行业洪流中。大家可以看到不论是金融科技还是科技金融,一大堆的金融公司已经淹没在前浪里。

4)从成本控制来看,大型主机运营费用昂贵,商业产品License费用高,买个机器和服务随随便便就几千万上亿的支出,真的是太贵了,所以随着业务系统做大做强,产品成本可能会成为压死骆驼的最后一根稻草。

为此,我们可以首先得出三点需求:

  • 一是应该优化应用架构、数据架构和技术架构;
  • 二是应该建设灵活开放、高效协同、安全稳定的IT架构体系;
  • 三是能够强化对业务快速创新发展的科技支撑。

2、双十一压力

说到这里,就不得不吐槽阿里的“双十一”,将购买压缩到一天,对顾客和金融系统来说造成双重压力,相较而言,京东的618就比较人性化,每天都可以剁手,大家千万不要以为我是给他们打广告,要打广告也是给工行融e购,请多多支持,谢谢。

www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

我们可以看下双十一的峰值变化情况,从09年开始,峰值只有400笔/秒,相较主机而言,有很大的差距,当然这也与他们当时的名气小有关;但是15年开始,借着云化和分布式的大旗,以及当时BAT的领头羊地位,仅4年时间,就从15年的14万笔/秒迅速攀升至19年的54万4千笔/秒。这就给金融行业的系统建设带来了4个问题:

1)高并发问题,我们可以看到,阿里为了提升峰值,做了大量的缓存,鼓励使用花呗,降低与外系统的交互,但是依然对金融行业产生额外的压力。

2)高可靠性要求,确保系统稳定可靠,客户可以稳定支付成功,避免因不佳的客户体现导致用户流失。

3)高成本压力,大幅扩容的设备,以及随之产生的运维成本,以及昂贵的商业liscence,给金融行业带来一定的成本负担。

4)同业竞争要求,大家都在做竞品分析,和同行进行比较,所以别人ok,你挂了,你面子上还挂的住么,所以各机构在双十一前进行大量的模拟测试,类似于高考前的黑暗日子。

3、金融行业分布式的核心诉求及策略

www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

为此,金融行业分布式的核心诉求及策略可以总结为以下5点:

1)应该具备企业级的业务支撑能力,支持高并发、可扩展和海量数据库存储及访问;原则上应支持同城双活,实现集中式向分布式的转型。工行的两地三中心容灾体系在国有大型银行中属于第一梯队。

2)应能大幅降低使用成本,可以基于通用的廉价的X86硬件基础设施;降低商业产品依赖,拥抱开源产品,互联网企业已经给我们做了一个很好的参考。

3)应该提升数据库的运维自动化和智能化能力,支持与自身系统进行适配性定制,工行即实现了行内系统适配定制。

4)金融行业还应考虑到社会声誉性要求,客户对金融行业的期望很高,特别是对银行等金融组织,所以要求也更加严格,原则上应该是7*24小时的不间断服务。像当年支付宝在15年的支付瘫痪事件仅仅上了下热搜,但是13年工行因为IBM主机bug的问题却上了新闻联播,这就是所谓的爱之深责之切吧。

5)要考虑到政治因素风险,虽然全球化要求技术无国界,但是从去年开始的贸易战,以及美国的实体管制清单,我们可以看到技术是有国界的。近期HashiCorp发布公告,其企业版产品禁止中国使用已经引发了一种担忧。说起HashCorp ,大家可能不一定熟悉,但是其旗下有大名鼎鼎的产品Consul,可以简化分布式环境中的服务注册与发现流程,大家一定耳熟能详。

最后中国人民银行在2019年8月23日发布了中提到“做好分布式数据库金融应用的长期规划,加大研发与应用投入力度,妥善解决分布式数据库产品在数据一致性、实际场景验证、迁移保障规范、新型运维体系等方面的问题,这也给金融行业指明了方向。

二、选型的发展历程(方案选型历程)

接下来,给大家介绍下如何选型以及工行的选型历程。

1、工行分布式转型发展历程

大家可以看下工行分布式的发展历程:

www.zeeklog.com  - 工行“去O”数据库选型与分布式架构设计

其大致可分为2个关键阶段,16年初-17年末为基础研究及试点阶段,之后为转型实施及推广阶段,大致有5个关键时点:

  • 16年初工行进行分布式体系研究,建立了基于dubbo框架的分布式生态服务;
  • 16年底借着人民银行对于个人账户的管理要求,实行三类账户的场景,开始了基于分布式的OLTP数据库研究,并确定了基于开源MySQL的OLTP数据库解决方案,因为MySQL 8.0的不成熟,所以我们采用了MySQL 5.7;
  • 17年末,我们完成开源MySQL初步能力体系的建设,涵盖了基础研究、配套方法论、应用试点等等;
  • 18年开始大规模的实施和推广,我们逐步建立企业级的数据库服务能力,包括引入了分布式的中间件,在高可用、运维能力的提升,资源使用率的提升,MySQL上云及自主服务的建设等等,同时开启了对OLTP的分布式数据库进行了研究;
  • 19年11月我们实现了国产分布式数据库产品GaussDB试点上线。

2、方案选型调研

大家可以看下工行的选型过程,希望可以给大家带来一定的