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