今天分享的主题是工行“去 O”数据库选型与分布式架构设计。

图片来自 Pexels

本次分享分为三个章节：

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

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

传统 IT 架构挑战

大家可能都知道，工行最早是基于 IBM 大型主机搭建的核心系统，以及基于 Oracle 和 IBM WAS 搭建的 OLTP 系统，在分布式体系大热之前处于同业领先地位。

当然现在也是处于同业领先的，但是科技成本也相对较高，所谓的一份价钱一分货就是这个道理。

但是随着分布式技术的成熟，传统的 IT 架构面临着四大挑战：

①从处理能力层面来看，传统应用(也叫巨石型应用)系统规模庞大，采用集中式架构设计，使用单一系统垂直扩展模式，扩展能力相对来说是有限的。

另一方面，大数据时代引发海量数据分析处理和存储处理的问题，对扩展性、可靠性和吞吐量提出了较高要求。

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

③从快速交付层面来看，传统巨石型应用实际上与快速交付是相悖的，应用内部模块、应用与应用之间耦合度高，使得软件开发和产品服务交付周期长，无法满足业务快速上线的需求，从而逐渐泯然众人矣，淹没在茫茫的金融行业洪流中。

大家可以看到不论是金融科技还是科技金融，一大堆的金融公司已经淹没在前浪里。

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

为此，我们可以首先得出三点需求：

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

双十一压力

说到这里，就不得不吐槽阿里的“双十一”，将购买压缩到一天，对顾客和金融系统来说造成双重压力，相较而言，京东的 618 就比较人性化，每天都可以剁手。

我们可以看下双十一的峰值变化情况，从 2009 年开始，峰值只有 400 笔/秒，相较主机而言，有很大的差距，当然这也与他们当时的名气小有关。

但是 2015 年开始，借着云化和分布式的大旗，以及当时 BAT 的领头羊地位，仅 4 年时间，就从 2015 年的 14 万笔/秒迅速攀升至 2019 年的 54 万 4 千笔/秒。

这就给金融行业的系统建设带来了四个问题：

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

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

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

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

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

为此，金融行业分布式的核心诉求及策略可以总结为以下五点：

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

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

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

④金融行业还应考虑到社会声誉性要求，客户对金融行业的期望很高，特别是对银行等金融组织，所以要求也更加严格，原则上应该是 7*24 小时的不间断服务。

像当年支付宝在 2015 年的支付瘫痪事件仅仅上了下热搜，但是 2013 年工行因为 IBM 主机 Bug 的问题却上了新闻联播，这就是所谓的爱之深责之切吧。

⑤要考虑到政治因素风险，虽然全球化要求技术无国界，但是从去年开始的贸易战，以及美国的实体管制清单，我们可以看到技术是有国界的。

近期 HashiCorp 发布公告，其企业版产品禁止中国使用已经引发了一种担忧。说起 HashCorp ，大家可能不一定熟悉，但是其旗下有大名鼎鼎的产品 Consul，可以简化分布式环境中的服务注册与发现流程，大家一定耳熟能详。

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

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

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

工行分布式转型发展历程

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

其大致可分为 2 个关键阶段，2016 年初-2017 年末为基础研究及试点阶段，之后为转型实施及推广阶段。

大致有如下五个关键时点：

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

方案选型调研

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