共计 5242 个字符，预计需要花费 14 分钟才能阅读完成。
- 金融行业架构转型需求
随着移动化与互联网化的不断发展，我国金融行业的商业模式与技术体系已经逐渐走上了与西方世界完全不同的道路。众所周知，欧美国家的移动化普及率远远不如我国，同时人口基数也有着数量级的不同，这就使得国内外金融行业所面临的业务类型、数据量、并发量都存在巨大的差异，导致对整个 IT 基础设施的需求截然不同。
在最近的一两年中，国内部分科技领先的银行已经率先对微服务与分布式技术进行了探索，一些新建的互联网金融类业务也已经开始尝试使用微服务架构、分布式技术、DevOps 框架进行应用的开发与维护。甚至一些银行在规划下一代核心体系架构时，也会尝试适当引入分布式架构，以满足未来业务压力与数据量不断增长的需求。
与新一代分布式架构相比，中间件加数据库的传统“烟囱式”架构在面向海量数据、高并发、高响应速度的业务应用时存在诸多问题。
• 从业务部门和系统来看，复杂的业务导致企业中系统数量多、分散、数据之间完全隔离无法共享；
• 系统缺乏灵活的水平伸缩能力，性能瓶颈明显，很容易遇到硬件瓶颈，无法满足弹性扩张的业务需求
• 系统无法快速响应顺势爆发的海量请求，例如双十一期间、秒杀等业务导致的瞬时爆发性增长很难处理；
• 采购和运维成本高昂，小型机设备与软硬件分别采购独立运维，导致整体拥有成本高昂；
• 缺乏自主掌控能力，高度依赖国外的厂商，出了严重问题本地支持团队很难在短时间内解决问题，导致生产运营风险增加。
- 银行架构演进历程
在过去的近二十年间，我国银行的 IT 架构历经了几个阶段的变化。我国的第一代银行核心系统构建在大型机之上，采用的是典型的大集中架构。而随着 SOA 概念的提出，一些银行也开始逐渐进行了去大机化，将核心业务系统从主机或 400 下移到 UNIX 小型机。虚拟化技术的增强使得一些银行和金融机构在其基础架构中引入虚拟化机制，将开发环境以及一些生产环境的应用程序部署在虚拟机上。
如今，很多银行都已经基于分布式与 PC 服务器架构建设了大数据平台，而一些基于微服务体系的应用程序则更是将业务逻辑进行了容器化封装，结合后台的分布式存储与数据库技术，实现了端到端的分布式架构体系。
正如同很多银行的科技部门都经历过核心系统从大集中向 SOA 转型的艰辛，由当前的小型机体系向分布式架构转型同样面临巨大的挑战，例如技术堆栈的选择、应用程序的开发、与 DevOps 体系的搭建等。
应用开发从传统架构向分布式转型，最先面临改造的自然就是应用程序框架。如今的微服务框架已经非常成熟，其代表性架构往往包括协议处理、服务拼装、原子服务、以及底层持久化四层。业务逻辑从传统的单一中间件被拆解成众多微服务模块，每个微服务模块由完全对等的一系列容器构成，可以简单通过增加容器的方式实现对该服务吞吐处理能力的扩容。
但是微服务的拆分即意味着每个服务都拥有自己独立的执行逻辑与存储。从数据库的角度来看，微服务体系的拆分对数据库存储提出了极大的挑战。如果每个微服务依然将数据存放在传统的单点数据库中，其存储与处理能力均无法随着微服务容器数量的上升提供同样的扩展能力。在这种情况下，数据库将会成为微服务体系框架中性能与扩展性的最大制约瓶颈。
而如果每个微服务使用独立的数据库进行存放，整个企业 IT 的数据架构将会变得支离破碎。数据库的数量从过去的几百被拆分为上万个数据库，整个运维团队的管理成本与数据库采购成本面临几何级数的提升。
因此，分布式数据库的目标不仅仅作为传统 Oracle 或 DB2 的单一替代，将一个数据库存放不下的数据放到多个物理机存放。在实际环境中，大部分银行都有着较为完善的数据生命周期管理策略，一般不会在生产环境中堆积大量的历史数据，因此数据量一般来说不会是使用分布式数据库的最重要原因。
- 分布式数据库架构体系
分布式数据库的核心价值在于对分布式应用程序提供一个弹性可扩张的数据服务资源池，也可称之为 DBPaaS 平台。其主要能力在于为上层数以万计的来自不同开发商、不同业务类型、不同 SLA 安全级别、不同数据类型的微服务提供一个可弹性扩展、高响应速度、易维护的数据库服务平台，同时必须支持在不同微服务数据间进行高可用配置、容灾策略定义、多租户、业务数据逻辑物理隔离、交易分析混合模式隔离、冷热数据隔离等一系列数据隔离与治理机制。
一些采用微服务架构的互联网企业，20 余人的数据库运维团队可以支撑几十万个不同的数据库实例，最运维核心便是构建了企业统一的 DBPaaS 平台，通过分布式数据库的故障自愈、弹性扩展等机制大规模简化了运维人员对数据库的管理。
当前业界存在众多分布式数据库产品，主要分为三种架构体系。
应用垂直拆分
应用垂直拆分是一种最传统的分布式理念。其中一种实现方式是将应用拆解成多个独立的子服务，每个服务对应整体中的部分数据；另一种实现方式则是在一个服务中对接多个数据库连接，在应用内部根据业务规则选择数据源。例如，应用根据用户账户 ID 进行切分，ID 为一到一百万之内的用户存在数据库 A、从一百万零一到两百万存在数据库 B，以此类推。
该机制通过在应用程序内预设一个规则，每次进行数据访问首先要从规则库筛选出目标所在的数据库实例，然后再直接获取连接进行访问。使用这种机制，一方面跨数据库的事务极为难以实现，另一方面从应用程序来说，分布式能力的业务侵入性极强，需要非常多的定制化开发才能完成基本业务逻辑，同时每次扩容需要对应用逻辑做完整的端到端梳理，可能会存在大量的风险与二次开发工作。
中间件分库分表
随着需要分布式存储能力需求的普及，业界开始逐渐出现了另一类技术体系，称为中间件分库分表。这类技术体系的思路是在应用程序和数据库之间构建一个 SQL 解析器服务，将传统的 SQL 进行解析然后翻译成底层每个数据库所对应的子查询，然后将查询直接下发给底层的传统数据库进行执行。
该机制的优势在于数据存储能够继续基于传统关系型数据库不变，同时上层对于应用程序接口得到了一定程度的封装。但是，中间件分库分表的机制从整个行业来看，可以认为是从传统单点数据库向分布式数据库转型的过渡阶段。在新型基于 PC 服务器构建的分布式数据库普及之前，一些急需数据拆分的应用可以先通过该方式缓解业务与数据量暴涨的压力，但在未来原生分布式数据库成熟且得到验证后会其优势将很难继续保持。同时，该技术对于应用无法做到 100% 完全透明，一般来说需要在应用拼装 SQL 的时候指定一些参数或使用较独特的语法，很难做到对应用完全透明无感知。
原生分布式数据库
不同于中间件分库分表技术，原生分布式数据库从底层的存储引擎直接以 PC 服务器为基础进行重构，从数据存储结构、数据安全机制、分布式事务控制等多个领域针对分布式存储与执行进行优化。
原生分布式数据库是底层完全从零开始研发，完全抛弃小型机体系，基于 PC 服务器硬件架构设计的分布式数据库，将高可用、容灾、分布式等机制天然融入到数据存储体系的方方面面。譬如说，一些分布式数据库产品能够在做到与 MySQL 100% 兼容的前提下，实现对应用完全透明的分布式存储与执行能力。从开发者的角度看，用户完全不需要关注一个表存在几亿还是几十亿记录，只要在建表时配置好容量与最大物理资源消耗策略，数据会自动在集群的多个物理设备中进行均衡，从应用来看就像访问标准的表一样直接进行读写请求。
- 原生分布式数据库技术趋势
为了支撑未来 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 则是新技术前瞻性的几个重要衡量标准。
- 金融分布式数据库应用场景
当前金融行业中，分布式数据库在五大领域中得到应用：数据仓库、大数据平台、内容管理平台、数据中台、与联机交易。对于联机分布式数据库的使用，当前业界主要围绕着三类业务场景。
联机交易系统
联机交易系统是银行重要的生产运行环境。我国一些分布式技术探索走在前沿的银行，已经开始逐渐将核心业务流程系统从 IBM 和 Oracle 的大机与小机架构下移到分布式环境，做到集群可弹性扩张，满足随时爆发的业务增长需求。一些典型使用到分布式数据库的系统包括网贷核心、渠道整合、信用卡积分等。
数据中台
如今，很多企业提出了重中台、轻前台的 IT 架构。而数据中台作为企业 IT 数据整合的关键平台，为前台灵活多变的业务需求，与后台相对固定的数据模型相结合，起到了“数据汇聚、连接前后”的作用。譬如银行能够先以生产系统瘦身作为目标，从历史流水账单查询打印开始，逐渐扩展到用户画像、资产视图等准实时数据服务。
内容管理平台
传统的内容管理平台主要以后督与审计为目的进行建设，前端业务基本不会直接参与非结构化数据的使用。而随着自助设备与移动应用的普及，越来越多的流程处理需要非结构化数据的直接参与。因此，内容管理平台也在很多银行从过去的后端走向前端，大量对客应用直接连接到内容管理平台，一些开户、信贷、甚至自助设备大量流程都在高度依赖内容管理平台的实时交互能力，使得内容管理系统从传统的对内后台审计走向对外联机服务。
可以看到，作为离线分析类业务场景来说，分布式数据库在银行早已经得到了普遍应用。而针对联机业务来说，MPP 数据仓库与大数据平台无论从可靠性、并发能力、与响应速度均无法满足需求。
小结
如今一些对分布式技术研究较深的银行，已经开始针对分布式数据库进行试点应用。分布式数据库的核心价值不仅在于将传统数据库存放不下的数据分散到多个物理设备中存储，更重要的是针对未来微服务化的应用开发模型，面对来自不同开发商、不同 SLA 级别、不同高可用容灾特性、不同业务类型的数据，提供一个可弹性扩展、多模式接口的数据服务平台（DBPaaS）。
当前的科技人员经常问的一个问题：分布式数据库是否能够在未来取代 Oracle？这个问题的答案可以说非常直观。分布式应用框架与 PC 服务器集群化一定是未来 IT 发展的方向，而微服务取代烟囱式软件架构，一定需要将数据库从传统的“点”向平台的“面”进行转移。每个应用程序都存在相应的迭代周期，如今已经可以看到很多应用程序都开始将 MySQL 等开源数据库作为自身默认支持的数据库选项，未来必须使用 Oracle 的场景也将会越来越少。
因此，分布式数据库未来必将取代 Oracle 等传统单点数据库。银行的科技部门也应该尽早对分布式数据库技术进行前瞻性研究，以适应未来银行 IT 架构从烟囱式模式向微服务转型的趋势。
