我们先站在巨人的肩膀上来看看业界有哪些通用的多租户存储模型。

数据空间采用类似Salesforce的大宽表模型设计，通过SAAS化的方式开放给开放业务使用。元数据对于平台而言，存储的是所有租户的数据。对于租户而言，每个租户/组织只能看到和定义按照自己租户OrgID隔离的它自己版本的元数据和数据， 而且只能执行自己租户OrgID所授权的行为，这样每个租户就拥有各自版本的SAAS方案。

▐  元数据驱动的多租户数据架构

1. 底层数据存储层：存储了租户底层数据结构以及对底层数据的对象和字段定义信息，支持多种存储类型
2. 存储引擎路由层：根据业务场景及租户定制，路由到不同的存储产品中执行
3. 元数据层：元数据模型主要由对象、字段以及底层数据表组成。元数据执行引擎是将业务逻辑模型映射到统一的元数据存储模型最核心的能力，我们常说的ORM功能也是其核心功能，但比其复杂的多
4. 平台接口层：对外提供数据空间SDK和标准MySQL协议两种调用方式。数据空间SDK中包含对象模型的创建、简化版的SQL执行等操作。标准MySQL协议通过自建MySQL代理层对外提供数据库服务
5. 业务场景层：数据空间对外服务的特色业务场景

▐  元数据存储模型

1. 对象元数据表：存放用户自定义和定制化的对象
2. 字段元数据表：对象下字段的定义，包括字段类型、字段映射在真实存储中的位置、是否需要索引、字段校验规则等
3. 数据表：存放用户真实业务数据，由灵活可扩展的弹性列组成，通过对象和字段的元数据定义映射到真实的存储

▐  元数据执行引擎

下面是一个简单的例子。

通用存储协议支持

▐  MySQL Proxy

在抽象的多租户元数据模型下，协议层开发的技术成本以及难度还是非常大的。数据空间选用开源中间件Sharing-Proxy作为MySQL代理对外提供数据库服务，隐藏底层元数据存储模型，用户不需要感知底层数据存储。Sharding-Proxy的定位是透明化的数据库代理，它封装了数据库二进制协议，用于完成对异构语言的支持，我们先来看下它原始的架构图。

Frontend层实现了MySQL协议的编解码。原始Sharing-Proxy 得到解码的MySQL命令后，开始调用Sharding-Core对SQL进行解析、路由、改写、结果归并等核心功能，在Backend层与真实数据库的交互。

数据空间由于有一套自定义的元数据模型，解耦了用户逻辑模型和底层物理模型，需要对Sharing-Proxy进行改造。

1. Frontend层：MySQL协议层编码/解码保持不变

2. Backend层：与真实数据库的交互并不需要，根据存储路由，存储到相应的物理库即可

3. Core-module层：得到解码的SQL命令后，需要解析语法树，对元数据进行映射，调用执行引擎执行

改造中最核心的部分在于Core Module层。在Sharding-Proxy的线程模型中，Frontend层使用IO多路复用处理客户端请求，后端使用HiKari连接池同步请求数据库，User Executor Group用于执行MySQL命令。

核心层（Core-module）的执行过程委托给CommandExecuteEngine完成，流程如下：

Sharding-Proxy获取SQL命令执行器的流程保持不变，我们主要对解析Statement语句和SQL解析执行引擎进行修改。

▐  SQL解析执行引擎

1. 解析器。ShardingSphere采用完全自研的antlr进行解析，通过测试发现非常耗时，数据空间改成Druid解析后性能提升5倍
2. 提取器。这里需要将AST节点进行深入解析，封装成数据空间简版SDK
3. 构建器。这里指构建查询请求包需要的字段定义信息，包含字段名、表名、字段类型、字段长度等基础参数，由元数据获取。
4. 执行器。交由数据空间元数据执行引擎执行

▐  引擎升级

1. 可扩展性差。每次适配新的SQL语句都需要修改提取器和底层元数据执行引擎，改造成本较大
2. 复杂SQL描述难。数据空间规定的协议格式对于简单SQL描述起来比较容易，但对于子查询、多表查询等复杂类SQL描述起来较为困难
3. 类型转换复杂。在执行参数准备以及结果返回参数过程中，都需要进行类型的转换，负担还是比较大的。对于MySQL支持的标准查询语法，转换逻辑需要考虑的非常全面

• 标识符改写

由于元数据底层真实存储其实是弹性列，业务侧表名和字段名都是逻辑上的概念，需要改写的标识符包括表名称、字段名称等。表名称改写是指解析AST，获取逻辑表名，并找到元数据定义，将其改写为真实表的过程。字段名称改写是指解析抽象语法树，将所有的字段列改写为真实字段列的过程。

• 补列

▐  标准协议层适配

对于协议层SQL需要进行单独适配。包括：

1. information_schema库

2. MySQL系统变量

3. set/commit语句等

比如，对于information_schema元数据库中的库表和字段元数据信息，我们需要查询元数据定义信息，并封装返回结果包返回，这里就不一一赘述。

官方数据空间在业务场景上的应用很多，目前低代码平台以及推送服务都在使用。接下来，我们以最近比较火热的低代码搭建以及推送服务来看下是如何使用的。

▐  场景一 低代码搭建

随着低代码&零代码热潮的来袭，非开发人员也可通过自由组装、拖拽式组件来 搭建应用，大大降低了商家在日常经营中的成本。在搭建平台中，商家通过智能表单承载商家数据存储、管理、分析等需求，低代码场景下对于存储的要求主要表现为以下方面。

1. 多租户数据模型：支持用户自定义搭建数据模型，模型和数据按租户隔离

2. 免运维：非开发者用户无数据库使用经验和运维能力，如何保证在各数据&流量模型下的稳定性可控

3. 通用存储协议：需支持业界通用数据库协议，以复用集团或开源报表搭建产品 

相比传统数据库存储产品，数据空间作为智能应用工作表存储目标的优势主要有以下几点。

1. 无感DDL：与物理模型解耦，业务模型的变更，只需对元数据层进行数据变更，而无需对数据库物理结构变更，即无运行时DDL操作

2. 弹性：使用ADB进行底层数据存储。ADB是分布式数据库，存储计算分离的架构天然具备弹性能力，且数据分散在各个shard上，shard会自动扩展，能够有效解决共享表模式下存在的数据膨胀问题

3. 报表搭建与查询分析：数据空间支持标准MySQL协议，可借助DeepInsight设计器进行报表制作，并加以数据、权限管控，可指定不同商家访问其权限内的数据

4. 运维成本低：平台托管大部分运维操作，用户无需感知数据库实例的存在

▐  场景二 推送云存储

• 链路变化

• 网络架构

数据空间弹内部署支撑低代码搭建。对于推送服务，数据空间单独部署一套服务 在聚石塔下生产网(部署二方业务组件或应用的网络区域)内。

云存储-Core 主要进行实例、账号、权限、连接串、表结构等管理。通过云通道调用数据空间服务。使用privatelink进行租户VPC和生产网的打通，部署在聚石塔内的推送客户端和服务商的转单服务通过分配的数据库逻辑实例连接串访问推送云存储服务。

该方案在网络上可行，但由于经过了多跳网络信息，协议侧已经丢失了连接地址信息，如何获取如何获取逻辑实例信息是一个难点。目前解决方案是开启 SLB TCP 四层监听的ProxyProtocol配置，通过Proxy Protocol协议携带客户端源地址到后端服务器, Proxy 代理侧 Netty 解析 HAProxy 协议，取出其中的终端节点信息进行用户身份识别后，再进行MySQL协议的解码。 

• 流量控制

1. 服务器启动时，将IP注册到Zookeeper上，动态监听上下线节点

2. MySQL连接建立成功，鉴权通过后，需要在Redis中向IP节点添加该云存储实例，连接销毁时，清除该IP节点下的实例

3. 执行真正的业务SQL前，尝试去获取令牌，SQL执行完，归还该令牌

4. 服务器下线时，清除该IP节点下的实例列表

获取令牌主要是在Redis中记录当前云存储实例在机器上的连接数，详细逻辑如下。

//获取令牌逻辑lock  int count = count (hvals instanceId)    if(count + 1 > limit)         ERROR(RATE_LIMIT)     else        hincrby instanceId IP 1    unlock
//释放令牌逻辑lock    //先获取一次，防止redis重启  int value = hget instanceId Ip    if value == false        return    else if value == "0"        return    else        hincrby instanceId IP -1unlock

目前数据空间初步技术架构雏形已经具备，作为官方存储已经在低代码平台和推送服务中使用，完成了阶段性里程碑，涉及的技术细节还比较多，当然数据空间适用的场景和业务还并不完善，毕竟需要像Salesforce一样使用自研的SOQL查 询语言也不太现实，适配完整的 MySQL 协议工作量也比较大，目前基础能力还有待完善，未来的规划和需要解决的问题是:

1. 存储弹性。多租户数据库跨所有租户共享计算和存储资源，如何保证保证租户之间不受影响的情况下，进行弹性伸缩是我们需要解决的问题。

2. 协议适配。元数据存储模型为数据模型带来灵活多变的同时，如何开放给商家和生态合作伙伴无门槛使用是亟需解决的问题之一。目前数据空间针对二方开放一套简版 SDK，对于三方通过自建 Proxy 适配 MySQL 协议，让客户无感知连接平台数据库。协议适配工作量巨大，要完全和 MySQL 标准协议对其需要一个漫长的过程，但自建 Proxy 的好处是SQL可以完全控在我们自己手上，针对不支持的SQL或者平台不希望执行的 SQL可以进行拦截。 

3. 业务稳定性治理。数据空间终极目标还是为上层各类业务服务的，如何针对不同类型业务定制不同的规则也是需要解决的一个难点。例如:针对推送服务，基于数据空间无感DDL的设计，开放自定义字段; 针对不规范SQL使用，使用隔离、限流、并发度控制等一系列手段治理; 还可以基于查询SQL优先级进行读取，同时平台管控SQL的另一大好处，可以为品牌商家生态全链路履约监控服务提供数据支持，帮助商家发现履约链路问题。

团队介绍

大淘宝技术开放平台，是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。