云数据库架构演进与实践

现在，大型企业如金融企业和银行等，在下一代的微服务架构转型要求下，须要基础软件和数据平台可以实现原生的云化，以知足微服务架构的需求。
微服务，也就是一种面向服务的，有特定边界的松散耦合的架构。
主要特色包括，每个微服务是一个独立的自治系统，能够不依赖外部组件独立运行；对应用只暴露接口，用户能够灵活的调整过每一个微服务的使用；业务粒度足够小。

在企业架构“云化”的过程当中，数据库的云化是最为重要也是难度较大的一个部分。数据库云平台（dbPaaS）是一类支持弹性扩张、多租户、自我管理、并可以运行在云服务提供商的基础设施（IaaS）之上的数据库管理系统（DBMS）或存储管理系统。

根据Gartner报告预测，数据库云平台市场份额将会在下一个五年中翻倍，而70%的用户将开始使用dbPaaS数据库云平台。所以，为了知足各种应用程序对数据库云平台的需求，同时为了减小私有云部署中对大量不一样类型数据存储产品的运维复杂性，数据库的架构演进将是将来十年数据库转型的主要方向之一。

云数据库的技术需求
在业务和应用进行“云化”的过程当中，云数据库由于在总体架构中的重要地位，在云化改造中的重要性不言而喻。云数据库的核心需求有一下几点，主要有：
弹性扩张能力：数据库容量须要根据业务弹性扩展，知足不一样业务的容量需求；
弹性部署与随需应变能力：除了数据库的存储，其余数据库功能也须要根据应用的需求，进行弹性的部署调整；
数据可靠性与服务持续能力：数据的可靠安全，全时在线是全部业务的必需要求；
计算存储分离：将计算和存储资源灵活配置，既能够选择多种计算方式也能够同时对应多种存储方式，知足更多业务需求；
多模式存储能力：结构化、非结构化、半结构化和图等多类型数据的存储；
自我管理能力：提供零停机维护、持续集成、以及滚动升级能力，提高开发人员效率；
自我监控以及问题修复能力：故障监控和问题修复，下降运维成本；
是否知足特定应用场景：针对特定场景的可插拔组件或工具；
监管与安全：知足监管的要求，保证数据的安全。

云数据库须要知足这些技术要求，除了在功能上的具体提高，在总体架构上更须要进行升级和“进化”。

云数据库架构方向
云数据库架构是其可否承载应用架构“云化”的关键点，随着技术和业务的发展，云数据库的架构出现了几个主要的发展方向：
在dbPaaS平台中，计算-存储层分离将会成为主流技术方向。经过将协议解析、计算等模块与底层存储解耦，数据库云平台将存储层进行分片以实现存储的弹性水平扩张，同时经过计算层的无状态设计容许计算层经过增长节点数量线性提高计算能力，已达到整个数据库云平台的弹性水平扩张。
多模架构成为主流趋势，Multi-model的架构在一个数据库平台就能够支持多种存储方式，大大减小运维和开发的成本。传统数据库中例如IBM、Oracle等早已经提供关系型、OO、甚至XML等存储引擎。而新一代数据库则更提供NewSQL、JSON、图、对象存储等多种类型数据存储引擎。
云数据库平台将会提供多种混合模式的数据服务 – 关系型与非关系型。该模式使用户可以在同一平台中结合不一样数据存储类型的特色，为新一代IT应用系统提供混合数据存储解决方案。
更符合微服务业务架构的要求，微服务要求各个服务模块之间尽可能松耦合和可独立扩展。所以对于数据库，也一样会针对不一样的业务，进行不一样侧重的配置，不管是传统的“读写分离”或者如今流行的HTAP都是围绕这个要求展开的。

针对这几个主要的发展方向，咱们就将详细来探讨云数据库的几个重要技术特色。

1）存储-SQL 分离
针对云数据库的需求和架构方向，一种新的数据库架构也在渐渐成为主流，也就是数据库的 “存储-SQL分离”架构。

存储-SQL分离架构，即指数据库的存储引擎和SQL引擎两部分互相松耦合独立工做的架构。一般这一架构，分为存储、SQL和元数据 三个部分。

存储层：即数据库的存储引擎，存储引擎负责处理数据的存储管理。同时包含路由及事务控制，保障数据的ACID特性。此外，存储层还应还具有索引、查询条件过滤、排序等一系列功能。
SQL层：SQL层主要负责处理SQL请求，上层直接面对应用程序，将应用程序的访问请求分发给存储层，而且接受存储层返回的数据结果。
元数据区：元数据区负责存储整个数据库的全部元数据信息。

典型的云数据库架构示意

对于这一架构，其实MySQL数据库当前的架构是有一些相似的。
MySQL数据库的SQL、存储分离的架构，在架构较为灵活，而其开源的生态也支持将不一样的产品、引擎和工具进行充分的对接。在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构能够根据业务的需求和实际须要选择合适的存储引擎。

MySQL数据库总体技术模块架构

如上图所示，MySQL 的存储引擎能够挂载多种不一样的产品，每一个引擎都能提供不一样的技术特性。其中包括InnoDB、MyISAM等架构。

存储与SQL分离的架构，目前在数据库业界十分流行，AWS的Aurora数据库在SQL访问上也采用了相似的架构。SequoiaDB 3.0 目前在MySQL兼容上，主要也是采起“SQL-存储分离“的架构。

SequoiaDB 3.0 MySQL 兼容逻辑架构

SequoiaDB 3.0使用了MySQL数据库原生的SQL解析器，自然支持MySQL协议并能够作到100%语法兼容。在该架构中，MySQL协议解析层做为SQL解析和分发的角色，直接面对应用程序，每个MySQL服务的接入节点都是一个独立支持读写操做的MySQL进程。而数据存储和管理层，则彻底由巨杉数据库的分布式数据库引擎实现。简单来讲，SequoiaDB 3.0做为MySQL的InnoDB替换引擎，在自然支持MySQL的所有语法和功能的同时，提供了数据库存储层弹性扩张的能力。

2）多模Multi-Model
企业使用云数据库对接的应用愈来愈多，需求多种多样，传统的作法是在dbPaaS里面提供十几个不一样的数据库产品分别应对各类需求，这样的方法在系统增长后，总体维护性和数据一致性管理成本很高，会影响到整个系统的使用。

云数据库的“多模”示意图

为了实现业务数据的统一管理和数据融合，新型数据库须要具有多模式（Multi-Model）数据管理和存储的能力。数据库多模Multi-Model是指同一个数据库支持多个存储引擎，能够同时知足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。

一般来讲，结构化数据特指表单类型的数据存储结构，典型应用包括银行核心交易等传统业务；而半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中获得大规模使用；非结构化数据则对应着海量的的图片、视频、和文档处理等业务，在金融科技的发展下增加迅速。

多模式数据管理能力，使得金融级数据库可以进行跨部门、跨业务的数据统一存储与管理，实现多业务数据融合，支撑多样化的金融服务。

在架构上，刚刚提到的多模Multi-model也是针对云数据库需求的，则使得数据库使用一套数据管理体系能够支撑多种数据类型，所以支持多种业务模式，大大下降使用和运维的成本。

3）灾备和多活
对于应用程序来讲，开发人员并不但愿在设计应用的过程中花费大量的精力来考虑底层数据高可用、灾备与多活时应用的切换逻辑。通常来讲，一个成熟的dbPaaS层应当尽量将底层的数据多副本同步、灾难切换、高可用接管等一系列操做进行封装，对于应用程序作到彻底透明。

在传统的应用程序开发中，开发者使用中间件容器对数据源进行配置，底层使用F5或其余虚拟IP地址对多个数据源进行封装。可是，在云化的演变过程当中，底层的数据库从单一节点向分布式节点过渡，对于上层的应用程序一方面但愿尽量减小应用程序设计时对分库分表的依赖，另外一方面更但愿在数据节点切换，甚至数据中心灾难接管的过程中作到应用透明无感知。

SequoiaDB 3.0则引入了异地多活的架构，应用程序能够从任意接入节点以读写的方式访问本地数据库。在数据读写的过程中，巨杉数据库可以从底层有效地进行数据一致性控制，对多个地区本地写入的数据进行远程复制，确保多个站点所读写的数据彻底一致。

另外，灾难发生时巨杉数据库提供对应用程序透明的数据切换与接管机制，动态调整底层数据分布拓扑逻辑，可以动态有效地排除故障数据中心内的节点，作到其余站点无感知地继续提供数据服务。

多活相比于传统的高可用来讲，不只在性能和安全性上实现了更大的提高，而这一架构也能在多活数据中心中充分的应用软硬件设备，减小冗余。

云数据库架构优点
在技术驱动的需求下，云数据库架构具有了几项主要的业务价值：
无需分库分表：此前，一种数据库分布式改造的方向是关系型数据库往分布式架构改造，MySQL分库分表就是其中一种方案。现在，存储-SQL分离的架构，在数据存储层已经实现原生分步实施，就避免了复杂冗长的“分库分表”方案。
灵活支撑业务需求：存储和SQL层均可以实现服务、存储的弹性调整，灵活地支撑业务的需求。
多存储引擎兼容：因为SQL和存储层的分离，在保持SQL接口不变的状况下，底层存储引擎能够支撑多个不一样引擎，实现多种数据引擎的同时兼容。
彻底兼容已有应用：因为SQL层更多使用已有的标准SQL解析器，所以对于原有应用在SQL上能够实现彻底的兼容，没有任何应用改造的投入。
数据安全可用：分布式的存储和松耦合的架构，数据拥有安全的多副本，松耦合则大大加强了整个系统的容错性。相比传统单点架构，能够很好的实现数据双活甚至多活的架构，知足“两地三中心”“三地五中心”的合规监管安全要求。

云数据库应用场景
在新架构驱动下，云数据库目前在多个场景下已经开始实现落地应用。

传统交易服务
在传统中心化交易型业务中，高性能、高吞吐量的数据存储与处理能力，ACID以及安全都是很是重要的特性。例如，在一个典型的银行业务中，为了知足高峰时期的在线交易量，交易型数据库须要在亿级记录条数的数据库中每秒处理上千比交易。同时，为了知足生产系统的健壮性与可靠性，传统交易服务对于底层数据存储的安全性、高可用性、两地三中心部署能力都有着很是明确的要求。

所以云数据库既须要将传统交易型业务逐渐转移至云平台，同时也须要在知足安全性和合规监管方面，为用户提供更好的支持。

历史数据服务
近年来，随着IT技术与大数据的不断发展，愈来愈多的企业将数据做为自身宝贵的资产进行长期保留。这使得一些传统应用程序的历史数据包袱愈来愈重，最终数据库不堪重负致使应用总体性能低下。另外一方面，随着大数据需求的不断增长，曾经已经归档的数据须要从新在线以知足在线化、实时化使用、查询和分析等等要求，这就要求将原有庞大的离线数据进行“在线化”。这些需求使得历史数据管理成为必须。
对于历史数据服务来讲，因为对外提供应用程序的直接访问，其健壮性、可靠性、可配置一致性策略、性能与并发能力都是极为值得关注的。同时，相对传统交易服务来讲，强一致和ACID反倒并非最关注的点。鉴于一些企业直接将部分报表和自助查询运行在历史服务平台上，HTAP的能力也是值得关注的特性。

云数据库在扩展性和性能上经过分布式的架构知足了这些需求，将历史数据很好的管理起来。

实时在线服务
当前大部分企业的生产业务系统与后台的数据加工、分析与查询系统都是经过T+1的方式进行数据ETL。而最近随着流处理技术的兴起，愈来愈多的企业开始基于流处理技术构建T+0的数据总线，以实现不一样业务流程之间实时数据对接。譬如说，用户资产视图就能够利用流处理技术，在提供用户全资产视图查询的优秀用户体验的同时，大幅度减轻其对后台生产系统形成的查询压力。
对于实时在线服务来讲，数据库的层面最为关注性能、吞吐量、可靠性、与可用性。而对于强一致、ACID、与HTAP来讲并不构成其最重要的特性。
在线业务的数据多样化和性能都须要云架构的数据库提供更灵活高效的支持。

影像存储服务
不少行业在业务运营中会产生大量纸质凭证，在信息化处理和监管要求下，这些纸质的凭证都须要扫描成影像文件并长期保存。随着互联网技术以及集中做业中心等理念的深刻推广，大量行业广泛须要建设统一的影像管理平台。
对于典型的影像平台来讲，其存储的数据整体量极大，使用传统存储的单位成本很高，须要进行生命周期管理时对运维又很是复杂。所以，对于逐年递增的海量影像数据来讲，大部分企业都存在查询难、管理难、扩容难的几大痛点。
同时，因为影像存储服务已经成为不少流程的一部分，其稳定性、可靠性与健壮性与核心交易系统处于同一级别。所以，影像存储服务最关注的层面在于可靠性、一致性、可扩展性、吞吐量、以及非结构化存储的多模特性。而其对于交易的ACID、HTAP等特性并不重点关注。

小结云数据库是将来数据库发展的一个重要方向，云数据库架构随着云化要求也须要进行相应的迭代，将来在云数据库架构的演进还会随着需求的变化而持续发展。其中对于多模数据引擎、计算存储分离等将是云数据库技术演进的重点方向。巨杉也会持续关注架构的迭代演进，同时也在技术和架构上针对云架构进行更多的创新。