# AliCloud Serverless Dataservice 支持方案 Design Review V2

## 目标

V2 的目标是支持 `AliCloud + Serverless(Starter/Essential)` 的 Dataservice regional 部署，并满足以下约束：

- regional 保留对 account service 的访问能力。
- regional 不依赖 DDB。
- regional 不依赖 Redis。
- 不新增任何 dataservice 业务接口。
- 不新增任何 account service 接口。
- 不修改现有 proto 与请求结构。

本方案与 `V1` 无关，按独立方案评审。

## 范围

V2 只覆盖 SQL 主链路：

- `CreateSession`
- `CloseSession`
- `ExecSqlDirectly`
- `ExecSqlWithSession`
- `GetDatabaseMeta`
- `GetClusterMeta`
- `ParseOneStmt`

不覆盖外部 Data API runtime、custom domain runtime、PrivateLink、dataapp log/download、dataapp metrics。

## 核心思路

### 1. 不改接口，复用现有 Credential 语义

global 继续按现有方式调用 regional `dataapi_gateway` 的 `/inner/dataservice/*` 接口。  
请求中继续使用现有 `Credential{Type, Key, AccountID}`，不增加 `ResolvedConnection` 等新字段。

这意味着：

- global 不负责下发 DB 用户名 / JWT。
- regional executor 继续在建连时自行访问 account service 获取 JWT / DB 用户。
- 现有 `AUTH0 / APIKEY / EMAIL / ACCOUNT` 凭据语义保持不变。

### 2. 用静态路由配置替代 DDB

AliCloud regional 不再从 DDB 读取 `user_cluster_info`。  
改为在 regional 配置中维护静态路由表，按 `project_id + cluster_id` 查找：

- `region`
- `cloud`
- `host`
- `port`
- `use_tls`

这份配置只解决“连到哪台 DB”的问题，不负责用户凭据。

### 3. regional 继续访问 account service

executor 建连时保留现有 `fillUserAccount -> JwtClient -> account ACL` 链路。  
也就是说，JWT 获取仍然发生在 regional，而不是 global。

这样可以：

- 复用现有 account service 接口
- 避免新增跨服务凭据下发协议
- 避免把 DB 凭据透传给 global

### 4. 用本地 session 替代 Redis

AliCloud regional executor 第一版假设每个 region 只有一个实例。  
因此 session 不再写 Redis，改为 executor 本地内存保存：

- `CreateSession` 写本地 session store
- `ExecSqlWithSession` 从本地读取
- `CloseSession` 删除本地 session

executor 重启后，旧 session 统一返回现有 `ErrInvalidSession`。

### 5. gateway 改成单 executor 分发

AliCloud regional gateway 不再依赖 Redis session lookup，也不再做跨 executor 转发。

行为收敛为：

- `CreateSession` 直接打默认 executor client
- `ExecSql / CloseSession` 不再使用 `WithEndpointAddr(...)`
- `WithLoadBalance(...)` 在 AliCloud 单实例模式下恒为 `false`
- `StartUnauthMetricsLoop()` 不启动，因为该逻辑依赖 Redis

### 6. Serverless regional 不部署 dataapi_control

对于 `AliCloud + Serverless`，regional 只需要部署 SQL 主链路服务：

- `dataapi_gateway`
- `dataapi_executor`

`dataapi_control` 不部署，因此也不需要为 Serverless 做任何代码改造。

这意味着：

- regional 不需要处理 control 的 AWS 依赖裁剪问题
- `privatelink / custom-domain / dataapp-log / dataapp-metrics` 这类能力统一在 global 收口为 `unsupported`
- V2 的 regional 改动范围只落在 `gateway + executor`

## global 改造原则

`AWS + Dedicated/Serverless` 全部保持原逻辑不变。  
`AliCloud + Shared(Serverless/Starter/Essential)` 走新的 provider-aware 调用逻辑。

global 只做两件事：

- 根据 `CloudProvider + DeployType` 选择 AliCloud strategy
- 把 regional URL 切换成带 `{provider}` 的 host，例如 `https://{provider}.{region}.inner-region.o11y.{env}.tidbcloud.com`

除此之外：

- 不改现有 SQL 接口语义
- 不新增凭据下发逻辑
- 不侵入 AWS 旧路径

## 风险与前提

### 前提

- `DeployType` 能稳定识别 AliCloud `Shared(Serverless/Starter/Essential)`
- regional executor 第一版每个 region 只有一个实例
- AliCloud 场景下，静态 route 配置可以被可靠分发
- regional 可以访问 account ACL / account provider
- regional path 保持 `/inner/dataservice/*` 不变，provider 只影响 global 侧 host 拼接

### 风险

- static route 配置错误会直接导致建连失败
- 单实例 executor 重启会导致 session 丢失
- regional 对 account service 的可用性会成为运行时依赖

## 建议

V2 建议作为正式实现方向。

原因很直接：

- 它满足“去掉 DDB / Redis”这两个核心目标
- 它不需要新增任何接口或 proto
- 它比 `V1` 更小、更稳、更容易回归 AWS 旧逻辑
- 它把变更限制在启动期装配、静态路由和 session 实现替换上，维护成本更低