跨越数据库发展鸿沟，谈分布式数据库技术趋势

一、金融行业架构转型需求

随着移动化与互联网化的不断发展，我国金融行业的商业模式与技术体系已经逐渐走上了与西方世界完全不同的道路。众所周知，欧美国家的移动化普及率远远不如我国，同时人口基数也有着数量级的不同。这就使得国内外金融行业所面临的业务类型、数据量、并发量都存在巨大的差异，导致对整个IT基础设施的需求截然不同。

在最近的一两年中，国内部分科技领先的银行已经率先对微服务与分布式技术进行了探索，一些新建的互联网金融类业务也已经开始尝试使用微服务架构、分布式技术、DevOps框架进行应用的开发与维护。甚至一些银行在规划下一代核心体系架构时，也会尝试适当引入分布式架构，以满足未来业务压力与数据量不断增长的需求。

与新一代分布式架构相比，中间件加数据库的传统“烟囱式”架构在面向海量数据、高并发、高响应速度的业务应用时存在诸多问题。

• 从业务部门和系统来看，复杂的业务导致企业中系统数量多、分散、数据之间完全隔离无法共享;
• 系统缺乏灵活的水平伸缩能力，性能瓶颈明显，很容易遇到硬件瓶颈，无法满足弹性扩张的业务需求;
• 系统无法快速响应顺势爆发的海量请求，例如双十一期间、秒杀等业务导致的瞬时爆发性增长很难处理;
• 采购和运维成本高昂，小型机设备与软硬件分别采购独立运维，导致整体拥有成本高昂;
• 缺乏自主掌控能力，高度依赖国外的厂商，出了严重问题本地支持团队很难在短时间内解决问题，导致生产运营风险增加。

二、银行架构演进历程

在过去的近二十年间，我国银行的IT架构历经了几个阶段的变化。我国的第一代银行核心系统构建在大型机之上，采用的是典型的大集中架构。

而随着SOA概念的提出，一些银行也开始逐渐进行了去大机化，将核心业务系统从主机或400下移到UNIX小型机。虚拟化技术的增强使得一些银行和金融机构在其基础架构中引入虚拟化机制，将开发环境以及一些生产环境的应用程序部署在虚拟机上。

如今，很多银行都已经基于分布式与PC服务器架构建设了大数据平台，而一些基于微服务体系的应用程序则更是将业务逻辑进行了容器化封装，结合后台的分布式存储与数据库技术，实现了端到端的分布式架构体系。

正如同很多银行的科技部门都经历过核心系统从大集中向SOA转型的艰辛，由当前的小型机体系向分布式架构转型同样面临巨大的挑战，例如技术堆栈的选择、应用程序的开发、与DevOps体系的搭建等。

应用开发从传统架构向分布式转型，最先面临改造的自然就是应用程序框架。如今的微服务框架已经非常成熟，其代表性架构往往包括协议处理、服务拼装、原子服务、以及底层持久化四层。业务逻辑从传统的单一中间件被拆解成众多微服务模块，每个微服务模块由完全对等的一系列容器构成，可以简单通过增加容器的方式实现对该服务吞吐处理能力的扩容。

但是微服务的拆分即意味着每个服务都拥有自己独立的执行逻辑与存储。从数据库的角度来看，微服务体系的拆分对数据库存储提出了极大的挑战。如果每个微服务依然将数据存放在传统的单点数据库中，其存储与处理能力均无法随着微服务容器数量的上升提供同样的扩展能力。在这种情况下，数据库将会成为微服务体系框架中性能与扩展性的最大制约瓶颈。

而如果每个微服务使用独立的数据库进行存放，整个企业IT的数据架构将会变得支离破碎。数据库的数量从过去的几百被拆分为上万个数据库，整个运维团队的管理成本与数据库采购成本面临几何级数的提升。

因此，分布式数据库的目标不仅仅作为传统Oracle或DB2的单一替代，将一个数据库存放不下的数据放到多个物理机存放。在实际环境中，大部分银行都有着较为完善的数据生命周期管理策略，一般不会在生产环境中堆积大量的历史数据，因此数据量一般来说不会是使用分布式数据库的最重要原因。

三、分布式数据库架构体系

分布式数据库的核心价值在于对分布式应用程序提供一个弹性可扩张的数据服务资源池，也可称之为DBPaaS平台。

其主要能力在于为上层数以万计的来自不同开发商、不同业务类型、不同SLA安全级别、不同数据类型的微服务提供一个可弹性扩展、高响应速度、易维护的数据库服务平台，同时必须支持在不同微服务数据间进行高可用配置、容灾策略定义、多租户、业务数据逻辑物理隔离、交易分析混合模式隔离、冷热数据隔离等一系列数据隔离与治理机制。

一些采用微服务架构的互联网企业，20余人的数据库运维团队可以支撑几十万个不同的数据库实例，运维最核心便是构建了企业统一的DBPaaS平台，通过分布式数据库的故障自愈、弹性扩展等机制大规模简化了运维人员对数据库的管理。

当前业界存在众多分布式数据库产品，主要分为三种架构体系。

1、应用垂直拆分

应用垂直拆分是一种最传统的分布式理念。其中一种实现方式是将应用拆解成多个独立的子服务，每个服务对应整体中的部分数据;另一种实现方式则是在一个服务中对接多个数据库连接，在应用内部根据业务规则选择数据源。例如，应用根据用户账户ID进行切分，ID为一到一百万之内的用户存在数据库A、从一百万零一到两百万存在数据库B，以此类推。

该机制通过在应用程序内预设一个规则，每次进行数据访问首先要从规则库筛选出目标所在的数据库实例，然后再直接获取连接进行访问。

使用这种机制，一方面跨数据库的事务极为难以实现，另一方面从应用程序来说，分布式能力的业务侵入性极强，需要非常多的定制化开发才能完成基本业务逻辑，同时每次扩容需要对应用逻辑做完整的端到端梳理，可能会存在大量的风险与二次开发工作。

2、中间件分库分表

随着需要分布式存储能力需求的普及，业界开始逐渐出现了另一类技术体系，称为中间件分库分表。这类技术体系的思路是在应用程序和数据库之间构建一个SQL解析器服务，将传统的SQL进行解析然后翻译成底层每个数据库所对应的子查询，然后将查询直接下发给底层的传统数据库进行执行。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!