云数据库架构演进与实践

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

在企业架构“云化”的过程中，数据库的云化是最为重要也是难度较大的一个部分。数据库云平台（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等特性并不重点关注。

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