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

1. 金融行业架构转型需求

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

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

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

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

1. 银行架构演进历程

在过去的近二十年间，我国银行的IT架构历经了几个阶段的变化。我国的第一代银行核心系统构建在大型机之上，采用的是典型的大集中架构。而随着SOA概念的提出，一些银行也开始逐渐进行了去大机化，将核心业务系统从主机或400下移到UNIX小型机。虚拟化技术的加强使得一些银行和金融机构在其基础架构中引入虚拟化机制，将开发环境以及一些生产环境的应用程序部署在虚拟机上。

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

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

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

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

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

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

1. 分布式数据库架构体系

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

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

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

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

该机制经过在应用程序内预设一个规则，每次进行数据访问首先要从规则库筛选出目标所在的数据库实例，而后再直接获取链接进行访问。使用这种机制，一方面跨数据库的事务极为难以实现，另外一方面从应用程序来讲，分布式能力的业务侵入性极强，须要很是多的定制化开发才能完成基本业务逻辑，同时每次扩容须要对应用逻辑作完整的端到端梳理，可能会存在大量的风险与二次开发工做。

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

该机制的优点在于数据存储可以继续基于传统关系型数据库不变，同时上层对于应用程序接口获得了必定程度的封装。可是，中间件分库分表的机制从整个行业来看，能够认为是从传统单点数据库向分布式数据库转型的过渡阶段。在新型基于PC服务器构建的分布式数据库普及以前，一些急需数据拆分的应用能够先经过该方式缓解业务与数据量暴涨的压力，但在将来原生分布式数据库成熟且获得验证后会其优点将很难继续保持。同时，该技术对于应用没法作到100%彻底透明，通常来讲须要在应用拼装SQL的时候指定一些参数或使用较独特的语法，很难作到对应用彻底透明无感知。

 原生分布式数据库
不一样于中间件分库分表技术，原生分布式数据库从底层的存储引擎直接以PC服务器为基础进行重构，从数据存储结构、数据安全机制、分布式事务控制等多个领域针对分布式存储与执行进行优化。

原生分布式数据库是底层彻底从零开始研发，彻底抛弃小型机体系，基于PC服务器硬件架构设计的分布式数据库，将高可用、容灾、分布式等机制自然融入到数据存储体系的方方面面。譬如说，一些分布式数据库产品可以在作到与MySQL 100%兼容的前提下，实现对应用彻底透明的分布式存储与执行能力。从开发者的角度看，用户彻底不须要关注一个表存在几亿仍是几十亿记录，只要在建表时配置好容量与最大物理资源消耗策略，数据会自动在集群的多个物理设备中进行均衡，从应用来看就像访问标准的表同样直接进行读写请求。

1. 原生分布式数据库技术趋势

为了支撑将来IT微服务框架，分布式交易型数据库的引入须要从传统技术兼容性、以及新技术前瞻性两个维度进行评估。

ACID的支持与SQL完整性的支持是评估一款新型分布式数据库是否可以提供与传统数据库技术兼容的两大关键指标。

• ACID的支持
从安全性上来看，不论采用新技术或传统技术，数据不错不丢是全部数据库的必备基础。在分布式数据库业界中，一些针对互联网技术设计的产品以分布式（Partition Tolerance）加高可用（Availability）做为目标，在安全一致性（Consistence）上没法保证数据的正确，很难在金融业务中被普遍使用。所以，银行所关注的新型分布式数据库必须首先保证数据的安全和一致性，其中分布式事务、分布式锁、四种隔离级别的支持等都是该指标中的关键技术点。

• SQL完整性支持
SQL完整性指的是新型分布式数据库与传统关系型数据库的开发友好性。越是成熟的分布式数据库，其SQL语法越能作到与传统关系型数据库兼容，同时其数据切分对应用程序则愈加透明。现在大部分分布式数据库技术都号称支持MySQL语法，而主流新型应用程序也都将MySQL做为其默认支持的数据库选项。所以，对MySQL语法协议支持的强弱则成为分布式数据库SQL完整性支持的评判关键。

新技术前瞻性指的是分布式数据库与将来开发方式和IT架构是否吻合。

• 分布式与弹性扩展能力
做为数据服务资源池，分布式数据库必须作到可弹性扩张，才能在服务于上层不断增长微服务类型与数量。同时对于每一个微服务来讲，其数据存放在一台物理设备仍是多台物理设备，必须对其中的应用代码彻底透明。

• 多模式引擎
服务于上层来自不一样开发商、不一样业务场景、不一样数据类型的微服务，分布式数据库必然须要支持多种SQL协议与计算引擎。从存储引擎来看，结构化与半结构化数据均可能将会在应用中同时使用。所以，新一代分布式数据库须要从访问接口到存储结构均支持多模（Multi-Model）引擎。

• HTAP（Hybrid Transactional/Analytical Processing）
HTAP即混合交易分析处理能力。在传统银行IT架构中，联机交易与统计分析系统每每采用不一样的技术与物理设备，经过按期执行的ETL将联机交易数据向分析系统中迁移。而做为数据服务资源池，同一份数据可能被不一样类型的微服务共享访问。当一些联机交易与审计类业务针对同一份数据同时运行时，必须保证请求在彻底隔离的物理环境中执行，作到交易分析业务无干扰。

整体来讲，分布式数据库技术趋势须要从传统技术兼容性以及新技术前瞻性两个维度进行评判，其中ACID数据安全与SQL完整性是传统技术兼容性的重要指标，而弹性扩展能力、多模式引擎、以及HTAP则是新技术前瞻性的几个重要衡量标准。

1. 金融分布式数据库应用场景

当前金融行业中，分布式数据库在五大领域中获得应用：数据仓库、大数据平台、内容管理平台、数据中台、与联机交易。对于联机分布式数据库的使用，当前业界主要围绕着三类业务场景。

 联机交易系统
联机交易系统是银行重要的生产运行环境。我国一些分布式技术探索走在前沿的银行，已经开始逐渐将核心业务流程系统从IBM和Oracle的大机与小机架构下移到分布式环境，作到集群可弹性扩张，知足随时爆发的业务增加需求。一些典型使用到分布式数据库的系统包括网贷核心、渠道整合、信用卡积分等。

 数据中台
现在，不少企业提出了重中台、轻前台的IT架构。而数据中台做为企业IT数据整合的关键平台，为前台灵活多变的业务需求，与后台相对固定的数据模型相结合，起到了“数据汇聚、链接先后”的做用。譬如银行可以先以生产系统瘦身做为目标，从历史流水帐单查询打印开始，逐渐扩展到用户画像、资产视图等准实时数据服务。

 内容管理平台
传统的内容管理平台主要之后督与审计为目的进行建设，前端业务基本不会直接参与非结构化数据的使用。而随着自助设备与移动应用的普及，愈来愈多的流程处理须要非结构化数据的直接参与。所以，内容管理平台也在不少银行从过去的后端走向前端，大量对客应用直接链接到内容管理平台，一些开户、信贷、甚至自助设备大量流程都在高度依赖内容管理平台的实时交互能力，使得内容管理系统从传统的对内后台审计走向对外联机服务。

能够看到，做为离线分析类业务场景来讲，分布式数据库在银行早已经获得了广泛应用。而针对联机业务来讲，MPP数据仓库与大数据平台不管从可靠性、并发能力、与响应速度均没法知足需求。

小结
现在一些对分布式技术研究较深的银行，已经开始针对分布式数据库进行试点应用。分布式数据库的核心价值不只在于将传统数据库存放不下的数据分散到多个物理设备中存储，更重要的是针对将来微服务化的应用开发模型，面对来自不一样开发商、不一样SLA级别、不一样高可用容灾特性、不一样业务类型的数据，提供一个可弹性扩展、多模式接口的数据服务平台（DBPaaS）。

当前的科技人员常常问的一个问题：分布式数据库是否可以在将来取代Oracle？这个问题的答案能够说很是直观。分布式应用框架与PC服务器集群化必定是将来IT发展的方向，而微服务取代烟囱式软件架构，必定须要将数据库从传统的“点”向平台的“面”进行转移。每一个应用程序都存在相应的迭代周期，现在已经能够看到不少应用程序都开始将MySQL等开源数据库做为自身默认支持的数据库选项，将来必须使用Oracle的场景也将会愈来愈少。

所以，分布式数据库将来必将取代Oracle等传统单点数据库。银行的科技部门也应该尽早对分布式数据库技术进行前瞻性研究，以适应将来银行IT架构从烟囱式模式向微服务转型的趋势。