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

以下文章来源于DBAplus社群，作者魏亚东

文章插图

DBAplus社群
围绕Database、Bigdata、AiOps的企业级专业社群。顶级大咖、技术干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙，受众20W+ 。

文章插图

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

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

大家好，今天分享的主题是金融行业分布式数据库需求及选型。
本次分享分为3个章节：

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

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

文章插图

但是随着分布式技术的成熟，传统的IT架构面临着4大挑战：
1）从处理能力层面来看，传统应用（也叫巨石型应用）系统规模庞大，采用集中式架构设计，使用单一系统垂直扩展模式，扩展能力相对来说是有限的；另一方面，大数据时代引发海量数据分析处理和存储处理的问题，对扩展性、可靠性和吞吐量提出了较高要求。
1）从运行风险层面来看，客户对金融行业的系统有着更高的业务连续性保障要求，对不可用问题实际上是零容忍的，比如要求7*24小时业务不能中断。
3）从快速交付层面来看，传统巨石型应用实际上与快速交付是相悖的，应用内部模块、应用与应用之间耦合度高，使得软件开发和产品服务交付周期长，无法满足业务快速上线的需求，从而逐渐泯然众人矣，淹没在茫茫的金融行业洪流中。大家可以看到不论是金融科技还是科技金融，一大堆的金融公司已经淹没在前浪里。
4）从成本控制来看，大型主机运营费用昂贵，商业产品License费用高，买个机器和服务随随便便就几千万上亿的支出，真的是太贵了，所以随着业务系统做大做强，产品成本可能会成为压死骆驼的最后一根稻草。
为此，我们可以首先得出三点需求：

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

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

文章插图

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