银行数据库安全可控替代方案探索

2019-09-17 19:35:56 基础技术研究阅读数 220 收藏

本文链接：https://blog.csdn.net/TIME_1981/article/details/100936934

作者：陈伟，王辉

内容摘要：本文通过银行对基础软硬件安全可控的要求，对于其中最难替代的数据库产品，基于商业银行业数据库产品的应用现状进行分析，提出了采用国产及开源数据库产品的替代方案建议。

关键词：数据库、安全可控、分布式、NewSQL

一、前言

根据Gartner2018年数据库系列报告，数据库产品作为IT架构中重要的基础软件之一，在下一阶段的IT基础架构建设中的地位将会不断提升。适用于新业务、新场景、新要求的新一代数据库，极可能成为下一代企业架构转型的最核心部分，也成为了银行安全可控工作的重要内容。

目前，银行业出于对数据库产品高安全和高可用的要求，在现有核心业务系统中选用的数据库产品一般为国际大型厂商的成熟产品，如IBM的DB2、甲骨文的Oracle、微软的SQL Server等。但随着业务的不断发展，银行对数据库产品的需求已经逐渐多样化，除了能满足我们业务系统需求外，逐步对数据安全、自主掌控的要求也越来越高，不少银行业已经开始了自己的转型尝试，并取得了一定的成果。

中国人民银行近期印发的《金融科技（FinTech）发展规划（2019-2021年）》也提出要“加快扭转关键核心技术和产品受制于人的局面”。为此，本文从安全可控的角度，以国产及开源的数据库产品为方向，探索商业银行数据库产品替代方案。

二、数据库产品分类

传统数据库产品按照关系类型可以分成关系型数据库(RDBMS，即SQL数据库)和非关系型数据库（NoSQL数据库），代表产品及分类见下表：

关系类型	细分	典型产品
关系型		商业软件：Oracle、DB2、SQL Server 开源软件：MySQL、PostgreSQL
非关系型	键值 (Key-Value)	MemcacheDB、Redis
	文档存储	MongoDB
	列式存储	HBase、Cassandra
	图关系	Neo4J

按照处理方式可以分成联机事务处理OLTP（On-Line Transaction Processing）和联机分析处理OLAP（On-Line Analytical Processing）,代表产品及分类见下表：

处理类型	典型产品
OLTP	Oracle、DB2、SQL Server、MySQL、PostgreSQL
OLAP	Greenplum、Teradata、AnalyticDB、GBase

下图对现常见的数据库产品做了比较清晰的分类，横坐标以数据处理方式分成OLAP和OLTP型，纵坐标以关系类型分成关系型和非关系型。

（图片来源：William Blair）

数据库产品的发展也在与时俱进，近几年在数据处理类型上的又出现了一种新的类型：HTAP (Hybrid Transaction/Analytical Processing)，它是在线事务和在线分析合称的简写，即(HTAP=OLAP+OLTP)。此类数据库既可以处理在线交易事务，又可以支持在线实时分析，即满足关系型数据库ACID事务特性、对SQL的完整支持，同时又兼备非关系数据库的高扩展性和高性能，此类数据库一般被称为NewSQL数据库，在后文中我们还会再做详细介绍。

三、银行业数据库产品应用现状

银行业的数据库产品应用主要集中在三个领域：适用于OLTP场景的关系型数据库、适用于OLAP场景的数据仓库和适用于非结构化数据的大数据产品，本文主要讨论适用于OLTP场景的关系型数据库产品。

目前，银行业的IT架构正在从传统竖井式的单体应用向微服务架构进行转型。在传统应用中，每一个单体应用对应一个独立的数据库，在微服务体系架构中，每个单体应用被拆分为若干个相对独立的微服务，几乎每个微服务也都同样需要数据持久化能力，因为成本及数据治理等问题，为每一个微服务搭配一个数据库的方式显然不现实也不合理，当然我们也看到了商用数据库在这方面的考虑，如采用多租户的方式。IT架构的转型会持续相当长的时间，在这个过程中必然会面临两种类型的需求：其一是现有传统单体应用的数据库产品替代，其二是新的微服务架构下的数据库产品选型和替代。

四、替代方案探索

（一）采用单体开源数据库替代

针对第一种需求，业界较多采用的方案是结合应用向x86体系迁移，选用开源数据库进行替代。目前一般使用开源的MySQL、PG等来替代传统的Oracle、DB2、SQL Server等产品，并采用主备或HA套件方式实现容灾和高可用性（如MHA、Keepalived、Zookeeper、HAproxy等），如工商银行、中国银行、招商银行、兴业银行等大多数的银行均已开展了实践。此类方案简单明了，不再赘述。

（二）采用分布式数据库替代

针对第二种需求，首先需要解决企业面临的多个问题。如：第一个问题是数据的弹性扩张，传统数据库采用共享存储的方式存储数据，越来越难以面对日益增长的数据需求所带来的压力，新的数据库产品应当能够解决容量在线调整等一系列问题；第二个问题是数据的碎片化，在原有单体应用架构中，数据分散在多个数据库之中，企业级统一视图缺失，同时又存在同样的数据缺乏共享、由多个应用独立维护所导致的数据不一致问题，这些问题也必须得到解决；第三个问题资源日益扩张所带来的运维压力增长，新的数据库产品要能够支持自动化智能运维；等等。

其次，新的数据库产品还必须满足银行的一系列基本要求。如：完整的一致性事务（ACID）支持、完整的SQL标准支持（包括与Oracle、MySQL等兼容性）、混合分析和事务场景支持（HTAP）等等。

根据业界已开展的尝试，目前主要衍生出两种流行的选择方案。

1、基于中间件实现分布式

第一种方案基于MySQL、PostgreSQL等开源数据库，以分库分表的方式支持海量数据及弹性扩张。其中分库分表功能可以通过在应用端开发来实现，更多的则是采用分库分表中间件来实现。中间件+数据库的基本架构如下图所示：

（图片来源: ShardingSphere官网）

开源中间件产品种类繁多，其工作原理一般是重新实现JDBC的API，向上层应用提供与原来一致的接口，内部先进行SQL的解析、重写、路由等处理，再将重整后的SQL按照传统方式发送到数据库进行执行，获取结果后进行归并处理最终返回给前端应用。代表性产品如开源的Sharding-JDBC、MyCat、Atlas、cetus、DBProxy、ProxySql、TDDL，以及部分国产商用套件如爱可生DBLE、热普的HotDB，万里开源的GreatDB，中兴科技的GoldenDB等。

下图为某商用国产中间件+开源数据库整体架构平台架构：

分库分表中间件位于应用和数据库之间，它屏蔽了底层数据库的复杂性，降低了对应用的业务侵入性。在应用方面，工商银行目前选用了商用中间件产品，已在三四十套应用上采用了DBLE分布式解决方案，其余单机版MySQL也都运行在了相关平台之上。央行也即将在全国账户大集中系统、存款保险系统等较核心的系统上，上线DBLE分布式解决方案。

其中工商银行的应用架构图如下：

（图片来源：工商银行-林承军-工行开放平台OLTP数据库转型实践）

分库分表中间件的方式在提供便利的同时也存在着不少弊端，如绝大部分中间在实现分布式事务均采用2PC的方式，存在同步阻塞，协调者单点故障，或因为协调者与参与者因为网络问题造成的数据不一致问题，无法实现真正的分布式事务支持，往往只能实现最终一致性（BASE），虽然相关产品做了一定的优化，但终究受实现方式的制约，我们一般建议这种方式下应用应尽量避免分布式事务，对于分布式事务比较常用的方式如TCC、消息队列等。这将导致其无法应用在有着强一致性要求的银行核心业务场景之中。再如中间件一般无法实现对于应用的完全透明，仍对应用存在一定的侵入性，对于应用的SQL语句存在或多或少的限制，或需要一些特定的语法来实现某些特定需求。因此在有些场景下会出现一定的问题，故需要一种更加高效的方案替代。

2、基于原生分布式数据库

第二种方案即自研或选用原生的分布式数据库。它是从底层开始重新研发，一般基于x86技术体系进行设计，不依赖于具体的机型和硬件，并将容量控制、分布式事务、容灾高可用等因素纳入到设计之中。同时在使用上，分布式数据库对应用完全透明，对应用无侵入，对于分库分表等工作均由数据库底层实现，应用无需关心数据如何存储和分布，只需将其当做一个普通数据库来看待即可。

为了解决分库分表方式的弊端，如果能够把中间件的功能下移到数据库层，通过数据库内部完成，再辅助以其他的相应扩展及优化，很多问题就可以得到完美解决：如支持分布式事务，具备ACID特性，水平扩展等。这种将中间件和数据库结合方式产生了一种新型的数据库，这就是我们上文提到过的新型原生分布式数据库。

分布式数据库的研究大约起步于2005年左右——NoSQL类型数据库诞生。这类数据库主要解决了单机上无法存储全部数据的容量问题。与此同时，基于传统关系型数据库的分库分表中间件也同步发展起来。至2012年~2013年，谷歌先后发表了Spanner和F1两篇论文之后，人们开始看到二者之间结合的可能性，新的分布式NewSQL数据库开始进入了蓬勃发展期。国内厂商们顺势而上，因此目前已有不少国产或开源的分布式数据库可供选择，代表产品如OceanBase、TiDB、巨杉数据库（SequoiaDB）、GaussDB100、OBASE等。下面将对这几种数据库进行简单介绍。

OceanBase是蚂蚁金服的金融级分布式数据库产品，它采用结构化数据存储，实现了SQL接口并完全兼容MySQL协议。支持多地多中心部署，支持水平扩展，其各个节点之间完全对等，每个节点都有自己的SQL引擎和存储引擎，不存在单点问题。OceanBase的产品架构图如下：

（图片来源：oceanbase.alipay.com）

OceanBase在互联网企业中应用广泛，也有着南京银行鑫云+互金平台、网商银行等同业实施案例。

TiDB是一个基于Google的F1/Spanner体系自研而成的开源数据库，采用无共享分层架构以K-V格式存储数据，模拟出关系型数据表，兼容绝大部分Mysql常用语法。TiDB支持多地多中心部署，支持水平扩展，主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server，其系统架构图如下：

（图片来源：PingCAP）

目前多家银行和互联网厂商已在自己的业务场景中将TiDB投入使用，如北京银行、微众银行等的企业级NewSQL数据库即选用了该产品，工商银行也对该产品进行了POC，在美团、平安科技等互联网企业中也有着大量应用。其中北京银行基于TiDB两地三中心架构图如下：

（图片来源：北京银行-于振华-TiDB在核心金融领域中的应用）

巨杉数据库同样是一个采用无共享分层架构设计的开源数据库，它以文档（BSON）格式存储数据，在协议级别完全兼容MySQL、PG和SparkSQL，同样支持多地多中心配置及水平扩展等。巨杉数据库主要包括编目节点、协调节点和数据节点三个核心组件，其系统架构图如下：

（图片来源：巨杉软件）

目前民生银行、恒丰银行的底层数据库云化转型升级采用了该数据库。下图是巨杉在某银行实施的两地三中心架构（目前仅上线了同城双活）：

（图片来源：巨杉软件）

GaussDB100是华为公司产品，同样采用无共享架构，该数据库在研发过程中与招行深度合作，以联合创新的形式开展合作，招行计划在2019年底前将17+个系统的数据库迁移到GaussDB100。

GaussDB100支持x86及ARM架构，并将人工智能技术融入了数据库的全生命周期，实现自运维、自管理、自调优、自诊断、自愈合五大功能。兼容主流数据库对象和语法，Oracle语法兼容性98%。GaussDB100主要由DN、OM、DM、CM、DT等多个组件构成，其系统架构图如下：

（图片来源：华为）

OBASE是丛云科技的原生分布式数据库产品，其前身是交通银行与华东师范大学的产学研项目，同样是一款采用无共享架构的数据库，支持水平扩展。兼容主流数据库DB2、oracle、MySQL大部分常用语法。OBASE主要包括CG、TG、MG、DG等多个组件，其系统架构图如下：

（图片来源：丛云科技）

交通银行在贷记卡预授权、网联支付系统、银联代收付系统、批量代发工资、供应链系统等多个系统中使用了该数据库，在某大型农信社中间业务平台也选用了该产品。

其它国产数据库还有达梦数据库、腾讯TDSQL、阿里的POLARDB等，本文不再一一枚举。它们一般都满足了银行业的基本要求，如强一致性事务、水平扩展、SQL协议兼容性、异地多活部署、混合分析与事务场景支持等。原生的分布式数据库代表着目前数据库的重要发展方向之一，目前此类产品的丰富性和成熟性已胜任应用要求，企业完全可以按照自己的需求选择适合自己的产品。

下图为常用的国产数据库：

五、结束语

综上，基于安全可控的要求，本文将数据库选型目标圈定在国产和开源数据库之中，针对目前的数据库发展状况和同业实施情况，探索总结了三种转型替代方案：一、针对部分单体应用可直接使用MySQL等开源数据库进行替代；二、以较为成熟的MySQL等开源数据库，配合分库分表国产中间件进行替代；三、直接使用新型的国产分布式NewSQL数据库进行替代。在实际数据库转型实施过程中，企业可根据自身情况，选择一种或多种来具体实施。

目前从db-engines网站公布的2019年8月份最新的数据库排行来看，关系型数据库Oracle的占有率依然第一，且自今年2月来就一直保持着上升的趋势。国产数据库中入榜的仅有TiDB和Sequoiadb且排名靠后，虽然这与网站的数据库产品选取、分类及调查对象选取存在一定关系，但是也从另一方面可以看出，我们在安全可控的数据库替代方案上仍然任重而道远，为了国家的大计划，未来技术不受制于他人，仍需要我们共同的奋斗。革命尚未成功，同志仍需努力！

（图片来源：db-engines.com）

文章最后发布于: 2019-09-19 09:11:13