元数据驱动架构的官方数据空间设计（下）

更多精彩内容，欢迎观看：

元数据驱动架构的官方数据空间设计（上）：

https://developer.aliyun.com/article/1263244?groupCode=taobaotech

整体技术架构

至此整个官方数据空间的基本形态和框架已经构建完成。以元数据管理为核心，向上提供租户模型管理、数据服务、数据分析等能力，并通过MySQL Proxy和数据空间SDK完成能力暴露。

具体的技术大图如下：

应用场景

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

▐  场景一 低代码搭建

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

1. 1 多租户数据模型：支持用户自定义搭建数据模型，模型和数据按租户隔离
   
2. 2 免运维：非开发者用户无数据库使用经验和运维能力，如何保证在各数据&流量模型下的稳定性可控
   
3. 3 通用存储协议：需支持业界通用数据库协议，以复用集团或开源报表搭建产品
   

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

1. 1 无感DDL：与物理模型解耦，业务模型的变更，只需对元数据层进行数据变更，而无需对数据库物理结构变更，即无运行时DDL操作
   
2. 2 弹性：使用ADB进行底层数据存储。ADB是分布式数据库，存储计算分离的架构天然具备弹性能力，且数据分散在各个shard上，shard会自动扩展，能够有效解决共3 享表模式下存在的数据膨胀问题
   
3. 3 报表搭建与查询分析：数据空间支持标准MySQL协议，可借助DeepInsight设计器进行报表制作，并加以数据、权限管控，可指定不同商家访问其权限内的数据
   
4. 4 运维成本低：平台托管大部分运维操作，用户无需感知数据库实例的存在
   

▐  场景二 推送云存储

推送服务历年在大促中中腰部及以下服务商 rds 性能难以管控，一方面存在单库挂载大流量多卖家，集中式的流量存在难以承载的情况，导致推送分组持续 堆积和推送延迟。另一方面，无法确保 rds 的稳定性，大促保障以及运维手段难、以触达，大促期间发生 rds 质量抖动或持续低下等问题屡见不鲜，导致推送延迟。
推送云存储产品是数据空间for推送服务提供的官方云存储空间，在该模式下，将服务商管控的数据库服务托管到平台侧，平台为其提供生态稳定性以及性能保障。相比传统RDS接入，具备更优的弹性能力及业务稳定性。

• 链路变化
  

推送服务可以选择订单数据推送到平台自建的推送共享云存储上，服务商从云存储中读取订单数据，进行打包、发货等处理，同时为其保证推送的实时性。

• 网络架构
  

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

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

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

• 流量控制
  

平台为了保证服务商线上推送写入服务质量，需要对服务商SQL进行治理，防止数据库被击穿，需要在Proxy侧进行流控，限制底层数据库连接。由于共享存储模式下，多个云存储实例连到一台数据库实例上，需要使用分布式并发度流控方案。虽然可以给每台应用服务器平均分配流控配额，把问题转换为单机流控，但如果碰到流量不均匀、机器宕机、临时扩缩容等场景，这种做法的效果不佳。
分布式环境下做流控的核心算法思路其实与单机流控是一致的，区别在于需要实现一种同步机制来保证全局配额。推送云存储采用ZK+Redis来实现。
详细流程如下：

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. 1 存储弹性。多租户数据库跨所有租户共享计算和存储资源，如何保证保证租户之间不受影响的情况下，进行弹性伸缩是我们需要解决的问题。
   
2. 2 协议适配。元数据存储模型为数据模型带来灵活多变的同时，如何开放给商家和生态合作伙伴无门槛使用是亟需解决的问题之一。目前数据空间针对二方开放一套简版 SDK，对于三方通过自建 Proxy 适配 MySQL 协议，让客户无感知连接平台数据库。协议适配工作量巨大，要完全和 MySQL 标准协议对其需要一个漫长的过程，但自建 Proxy 的好处是SQL可以完全控在我们自己手上，针对不支持的SQL或者平台不希望执行的 SQL可以进行拦截。
   
3. 3 业务稳定性治理。数据空间终极目标还是为上层各类业务服务的，如何针对不同类型业务定制不同的规则也是需要解决的一个难点。例如:针对推送服务，基于数据空间无感DDL的设计，开放自定义字段; 针对不规范SQL使用，使用隔离、限流、并发度控制等一系列手段治理; 还可以基于查询SQL优先级进行读取，同时平台管控SQL的另一大好处，可以为品牌商家生态全链路履约监控服务提供数据支持，帮助商家发现履约链路问题。
   

团队介绍

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

我们是一支技术能力雄厚，有着光荣历史传统的技术团队。在历年双十一战场上，团队都表现着优异的成绩。这里承载着每秒百万级的业务处理，90%的订单通过订单推送服务实时地推送到商家的ERP系统完成电商作业，通过奇门开放的ERP-WMS场景已经成为仓储行业标准。随着新零售业务的持续探索与快速发展，我们渴求各路高手加入，参与核心系统架构设计、性能调优，开放模式创新等富有技术挑战的工作。