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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 应用垂直拆分

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

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

  1. 中间件分库分表

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

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

  1. 原生分布式数据库

不同于中间件分库分表技术，原生分布式数据库从底层的存储引擎直接以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. 金融分布式数据库应用场景

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

  1. 联机交易系统

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

  1. 数据中台

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

  1. 内容管理平台

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

可以看到，作为离线分析类业务场景来说，分布式数据库在银行早已经得到了普遍应用。而针对联机业务来说，MPP数据仓库与大数据平台无论从可靠性、并发能力、与响应速度均无法满足需求。

小结

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

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

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

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

  1. 分布式数据库实战第一节 分布式数据库的前世今生

    开篇词 吃透分布式数据库,提升职场竞争力 你好,我是高洪涛,前华为云技术专家.前当当网系统架构师和 Oracle DBA,也是 Apache ShardingSphere PMC 成员.作为创始团队核 ...

  2. oracle分布式数据库搭建,ORACLE实现分布式数据库应用

    原文链接:http://user2005.blog.163.com/blog/static/137589500201123141041319/ 序 言 ORACLE分布式数据库系统是一个客户/服务器体 ...

  3. [分享]浅谈分布式数据库

    文章集中整理总结mysql分库分表开源产品,分布式数据库的设计,以及实际应用案例等相关内容,部分附上本文作者实际应用过程中的理解. 本文感谢sjdbc,mycat,姜承尧,林涛等文章提供的精彩介绍. ...

  4. 云原生数据库的幕后英雄：浅谈分布式数据库的计算和存储分离

    引言 分布式数据库替代传统商业数据库是近年最热门和最具争议的话题.理论上没有什么数据库不能被替代,现实却往往是代价大到难以承受.怎样才能更好的降低替代带来的代价呢?开源数据库TiDB创始人黄东旭在&l ...

  5. 【干货】浅谈分布式数据库中间件之分库分表

    分库分表,顾名思义就是把原本存储于一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上.那么关于分库分表,你了解多少呢?接下来,我们将从什么是数据分片及如何进行分片两方面对DDM ...

  6. 分布式SQL学习总结（1）——蚂蚁金服资深总监韩鸿源：像使用集中式数据库一样使用OceanBase分布式数据库

    很多人对蚂蚁金服的了解还仅仅停留在支付宝,其实今天的蚂蚁金服已经逐步成长为大型的金融集团,覆盖了很多范围的业务,这些业务中不仅包括超过8.7亿实名注册用户,日活2亿多的支付宝APP,还包括服务亿级免押 ...

  7. 助力金融业数字化转型，巨杉数据库获评金融级分布式数据库用户首选品牌

    日前,由国家工业信息安全发展研究中心指导,北京赛昇计世资讯科技有限公司主办,赛昇控股(北京)集团有限公司.产业互联网发展联盟和软件融合应用与测试验证工业和信息化部重点实验室等单位支持的"20 ...

  8. 【概念】为什么区块链被称为分布式数据库？举例讲解分布式数据库包会教程。区块链分布式数据库到底是什么？什么是分布式数据库？一千六百字讲清楚什么事分布式数据库。

    目录 前言 区块链是什么 为什么说是分布式数据库 去中心化 分布式网络 分布式数据库 前言 随着区块链慢慢走进大众视野,大家也能发现,网上许多教程都说区块链是分布式数据库,区块链技术是基于比特币应用提 ...

  9. 最火的HTAP数据库 京东云新一代分布式数据库TiDB架构揭秘

    作者丨京东智联云数据库团队 2020年伊始,一场突如其来的新冠疫情, 席卷了华夏大地.为了抵抗疫情,全国人民众志成城,共同抗疫.疫情期间,各行各业受到了巨大影响,多数线下服务和活动基本陷入了停滞状态. ...

最新文章

  1. Smart-linkmonitor-link配置注意事项
  2. CentOS（5.8/6.4）linux生产环境若干优化实战
  3. 中文输入法切换ubuntu_切换到 Linux 工作，体验暴增 100 倍！
  4. Windows XP 源代码泄露，微软终于回应了~
  5. qt的exe启动时隐藏图标_系统小技巧：Win10桌面图标问题多 常见3种这么解
  6. bzoj 2435: [Noi2011]道路修建 树上 dp
  7. 测试女生周期的软件名字,什么软件可以提醒生理期？适合女生可用的便签软件...
  8. Cpp 对象模型探索 / 对象访问成员变量的原理
  9. PHP之父评价Facebook的HipHop项目：别当作银弹
  10. IOS工程自动打包并发布脚本实现
  11. 防火墙firewalld
  12. 让apache解析html里的php代码,让Apache解析html文件中的php语句
  13. python Unable to find vcvarsall.bat 错误
  14. springboot 添加 lombok 报错更新 版本号
  15. 一个关于mahout0.5放置位置的错误，，，
  16. 7. 查看当前库状态
  17. 站内搜索引擎源代码 asp.net
  18. mock.js文档详解5及下载(Random中的Name,Web,Address种类函数)
  19. ARM Cortex-M3/M4/M7 Hardfault异常分析
  20. 动态SQL之choose

热门文章

  1. html实现银行卡中间四位显示为*号,用正则给银行卡号部分加*号显示。。vue中根据不同的值，渲染相应的内容。。...
  2. jira的基本配置和设置
  3. PC-DMIS 如何更改CAD模型的坐标系
  4. 开展5G物联网体系架构、关键技术与行业应用集成创新高级研修班
  5. 灵雀云陈恺：2020 云原生走向何处？｜CNBPS2020演讲实录
  6. 【数据结构】单链表逆置：头插法图解
  7. Linuix 服务器cat log查看，快速定位 bug 最实用(实战总结)
  8. （五）MkDocs学习——配置文件
  9. Tkinter编程应知应会(22)-Canvas控件
  10. 交流伺服电机及驱动器接线