wanglaye
作者wanglaye2022-01-18 16:59
信息技术经理, 某大型金融机构

某金融机构分布式数据库设计与实践

字数 7504阅读 5402评论 6赞 11

文章摘要:

在现今云计算、大数据等新型技术推动下,金融科技迎来了新一轮创新浪潮,业界主流的应用架构,正由松耦合、集中式的SOA架构向解耦合、分布式的微服务架构发展。传统数据库在应用方面,存在并发能力不强、弹性不足、系统资源利用不均衡、更新迭代发布周期长等问题,难以适应业务高并发、负载波动大、新功能上线频繁等需求。同时,随着数据库规模的增大,对于管理成本和人力成本提出了很大挑战,缺乏统一的数据库分析和辅助决策,出现问题时往往各自为政,存在数据孤岛,管理时效性难以保证。近年来,为满足业务发展需求,我司顺应技术发展潮流,开展了分布式数据库的探索和应用。

一、背景

在现今云计算 、大数据等新型技术推动下,金融科技迎来了新一轮创新浪潮, 业界主流的应用架构 ,正由松耦合、集中式的SOA架构向解耦合、分布式的微服务架构发展。在“去IOE”、“自主可控”的技术和政策双重背景下,传统金融行业的业务系统所采用的数据库,正在从老牌厂商的 DB2 、 Oracle等 逐渐过渡至开源数据库或国产新兴的 分布式数据库 。

我司各类业务系统,均是典型 SOA系统架构 ,其 数据库均为主备部署模式,在应用方面存在并发能力不强、弹性不足、系统资源利用不均衡、更新迭代发布周期长等问题,难以适应业务高并发、负载波动大、新功能上线频繁等需求。同时, 作为一家传统金融企业,各业务系统仍然是纵向隔离的状态,在烟囱式系统架构中,每个业务系统都有其独立的数据库,随着业务系统数量越来越多、数据规模越来越大、交易复杂度不断提升,数据库的数量也越来越多,对于管理成本和人力成本提出了很大挑战。并且,由于数据库各自独立,无法对全部数据库的运行状况形成全局视图,缺乏统一的“数据库管理大脑”,无法进行统一的数据库分析和辅助决策, 出现问题时往往各自为政 ,存在数据孤岛,管理时效性难以保证。

近年来 , 为满足业务发展需求 , 我司顺应技术发展潮流 ,以微服务的理念,进行线上交易系统的微服务化设计。但我司现有的数据库架构,尚不能以平台化形式提供分布式数据库服务,难以满足业务系统未来的发展需求。基于以上原因,我司开展了分布式数据库的探索和应用。

二、目标与需求

我们在进行分布式数据库设计时 ,主要考虑达成几个目标,一是提高系统扩展能力,应对高并发访问;二是提高资源利用率,降低运营成本;三是提高系统可靠性,降低运行风险。

结合分布式数据库设计目标,以及分布式数据库应用和运维场景,我们进一步梳理了分布式数据库的需求,主要包括以下方面:

(1)通用需求:如支持标准SQL语法,支持x 86 ,支持各种数据类型、数据库对象、约束、字符集等。

(2)分布式功能需求:如支持分布式事务、MVCC多版本控制,支持高并发情况下的完善锁机制,具备不同隔离级别,支持分表分区分片,支持读写分离,支持在线弹性伸缩与平滑扩容,支持SQL优化器等。

(3)性能需求:要求系统集群采用高可用架构,性能满足QPS支持10w+、TPS支持5w+,以及连接数和并发数要求,且具备良好的数据副本同步性能。

(4)高可用需求:要求集群架构无任何服务单点,服务稳定可靠,具备各种层级的高可用能力等。

(5)备份与恢复需求:如支持在线全量备份、增量备份、差量备份等功能,支持任意时间点的备份还原等。

(6)灾备需求:支持多数据中心多活容灾。

(7)安全需求:如支持加密存储,支持多租户资源隔离,支持权限管理,支持黑白名单,支持防注入攻击等。

(8)运管监控需求:如具备可视化运维管理工具,支持数据库实时监控和历史回溯,支持数据库审计、SQL执行计划及优化提醒,支持统计分析等。

(9)运维需求:如支持不停业务的版本升级,支持灰度发布、滚动升级等,支持在线配置,支持在线扩缩容等。

(10)可移植性需求:如支持基于原数据库 的开发内容,实现平滑过渡 , 降低移植改造成本。

通过需求分析与选型测试 , 我们最终选定OceanBase分布式数据库产品 。

三、整体架构设计

1. 分布式数据库产品概览

OceanBase已经发展多年,大家或许已经非常熟悉,OceanBase 整个产品的结构非常清晰,计算层跟数据存储层分离,这是现代大部分分布式数据库通常都会倾向和考虑采用的架构 。下面引用一张OceanBase官方架构图,做个简要介绍:

OceanBase 数据库采用Shared-Nothing 架构,各个节点之间完全对等 ,这些节点均可运行于标准服务器之上。OceanBase采用了 可用区 (Zone) 的概念,Zone是个逻辑概念 , 每个Zone 是一个机房内的 1台或多台 服务器, 即 数据库服务器(OBServer)。每台 OBServer 包含 SQL 引擎、事务引擎和存储引擎,用户的 SQL 查询 经过 SQL 引擎解析优化后转化为事务引擎和存储引擎的内部调用。SQL 引擎是整个数据库的数据计算中枢 ,分为解析器、优化器、执行器三部分;存储引擎负责数据的存取和管理,将数据分为基线数据和增量数据。对于跨服务器操作, OceanBase 数据库还会执行强一致的分布式事务 。 此外 , 还有一个承担集群大脑角色的集中调度器,叫做 “总控服务”(RootService),其中每个 Zone 上都会存在一个总控服务,运行在某一个 OBServer上,整个集群中只存在一个主总控服务,其他的总控服务作为主总控服务的备用服务运行,总控服务负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能。 同时 整体架构中还会融合一些管理 工具,包括 OCP、 ODC 、 OBProxy等 。

OceanBase可实现 在线水平伸缩 、 强一致性的分布式事务 、 基于Paxos协议和多副本 机制,并且也满足我司对于高可用、高性能、高可扩展性的要求。OceanBase 部署简单,在线弹性扩容不影响业务,异地多活及自动故障恢复保障数据安全,同时兼容MySQL 协议,使迁移使用成本降到极低 。这篇文章将详细介绍OceanBase在我司的设计与实践。

2. 逻辑架构设计


图 1:总体逻辑

试读部分结束,继续阅读

此内容为“云原生应用创新实践联盟”用户的专属内容

云原生应用创新实践联盟用户组是基于联盟课题方向、集结各行业技术领域的企业用户的用户组织。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

11

添加新评论6 条评论

匿名用户
2022-06-15 11:13
目前金融行业主机下移,单元化、全密态是行业的趋势,在实践中发现还发现了,对于目前主机下移OceanBase的Paxos组集群还可以实现混合部署和灰度部署的功能,不仅在集群间实现混合部署,也可以在分片间实现混合部署,这个对于目前尝试国产化提供了极大的便利~
sky199sky199软件开发工程师, 软通动力
2022-02-23 22:36
看完很有帮助
sky199sky199软件开发工程师, 软通动力
2022-02-23 22:36
看完很有帮助
匿名用户
2022-02-10 21:17
本文作者详细介绍“去IOE”中“O”架构方案,并采用业界主流的应用架构,使用OBDB分布式数据库 。使用场景应该是同城双活数据中心,“O”通过一套OCP进行管理集群维护,每个数据中心都有OBServer主、从集群互为主从,每个OBServer集群部署为三个Zone(3副本),每个数据中心设置1台备份机。两中心之间的内部通信配置了万兆交换机,对外提供服务使用千兆交换机。在详细方案设计中,从高可用、容量、多住户、备份与恢复、运维、灾备、应用规范与迁移几个方面做了阐述。在去“IOE”中,不断踊跃出很多国产数据库厂商,数据库的分类也越来越细。
saltypsaltyp系统架构师, 某银行
2022-02-09 15:34
分享的不错,希望可以看到更多金融同行可以分享自己的实践经验和遇到的坑。
a5060963a5060963运维工程师, 民营500强企业
2022-02-09 15:12
该文章看完后又刷新对数据库的了解,本文引用的Ocean Base,蚂蚁公司开发的分布式数据库。 1、该文章中表述层次鲜明,说明常规数据库的使用瓶颈,请求量也一一列出,最后再进行架构讲解,运维方案、灾备方案等 2、特别适合用于金融企业的高请求量,高并发。而且在灾备中相对于传统数据库的冗余解决方案更优 3、希望以后也可以接触到此方案的结构,学习强大的数据库解决方案
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

分布式关系型数据库选型优先顺序调查

发表您的选型观点,参与即得50金币。

作者其他文章

相关文章

相关问题

相关资料