下载 Markdown

云数据库代理网关技术架构（生产级多租户 v4）

版本：v4.0
日期：2026-02-15
适用仓库：/Users/Zhuanz/work-space/cloud-data-proxy

1. 目标与硬指标

1.1 业务目标

1. 统一接入多个应用（首年 20 个应用）。
2. 应用侧去除数据库直连配置（不再保存 DB host/user/password/db）。
3. 应用间强隔离（身份、权限、资源、审计四层隔离）。
4. 运维操作通过 Web 控制台完成（注册、开通、轮换、禁用、审计查询）。

1.2 生产硬指标（SLO）

1. 可用性：99.99%（月故障预算约 4 分 23 秒）。
2. 吞吐：分阶段从 10万 QPS 扩展到 100万 QPS。
3. 延迟预算（代理附加开销）：P99 <= 2ms，P99.9 <= 5ms（同地域同机房）。
4. 隔离：任意跨应用访问必须失败并留痕（拒绝率 100%）。

2. 现状与差距（基于当前仓库）

3. 总体架构（目标态）

flowchart LR
  subgraph APP[应用层]
    A[应用A]
    B[应用B]
    C[应用C]
    D[应用D]
  end

  subgraph CP[控制面]
    W[Web Console]
    API[Admin API]
    JOB[Provision/Rotate Job]
  end

  subgraph DP[数据面集群]
    G1[Gateway Pod 1]
    G2[Gateway Pod 2]
    GN[Gateway Pod N]
    RP[Redis: Token/Policy Cache]
  end

  subgraph STATE[状态与审计]
    META[(Metadata DB)]
    AUD[(Audit Store)]
    MQ[(Kafka/NATS)]
  end

  subgraph DB[数据库层]
    RW[(MySQL Primary)]
    RO[(MySQL Read Replicas)]
  end

  APP -->|API Key / mTLS| DP
  W --> API
  API --> META
  API --> JOB
  JOB --> DB
  DP --> RP
  DP --> META
  DP --> MQ
  MQ --> AUD
  DP --> RW
  DP --> RO

3.1 关键设计原则

1. 控制面和数据面分离：配置变更与查询执行解耦。
2. 数据面无状态：可水平扩展，实例可随时替换。
3. 隔离以数据库权限为主、SQL 护栏为辅：避免仅靠正则拦截。
4. 读写分离与连接池配额：防止单租户噪声放大。
5. 审计异步化：避免审计写入拖慢业务路径。

4. 多租户隔离模型

4.1 身份隔离

1. 每应用独立 api_key（支持轮换、失效、禁用）。
2. 数据库侧每应用独立 db_user，仅授权自身 db_name。
3. 控制面管理员 token 与应用 token 严格分离。

4.2 权限隔离

1. 应用用户只授予本库最小权限（按读写/DDL能力模板）。
2. 禁止数据面回落使用 admin 账号执行 SQL。
3. 支持按应用配置能力集（read/write/ddl/tx）。

4.3 资源隔离

1. 每应用独立 QPS 配额。
2. 每应用独立并发上限（inflight）。
3. 每应用连接池上限（避免占满 MySQL 连接）。

4.4 审计隔离

1. 审计记录必须包含 tenant_id/app_id/request_id。
2. 审计查询默认按租户过滤，跨租户查询仅管理员允许。

5. 数据库能力支持策略（“全功能”目标）

结论：若目标是“数据库全功能支持 + 高并发 + 多语言驱动兼容”，最终应演进到 MySQL 协议代理路径；仅 HTTP SQL 很难完全覆盖。

5.1 三阶段能力路线

1. 阶段 A（当前增强）：HTTP SQL 模式增强，覆盖 DQL/DML/DDL + 审计 + 限流。
2. 阶段 B（过渡）：引入事务会话 API（begin/commit/rollback + session token）。
3. 阶段 C（目标）：引入 MySQL 协议代理数据面（推荐 ProxySQL/Vitess 思路），实现驱动侧近似透明接入。

5.2 兼容性要求

1. 必须支持预编译参数化查询。
2. 必须支持事务与隔离级别配置。
3. 必须支持大结果集受控传输（流式/分页）。
4. 必须支持 DDL 变更审计与风险护栏。

6. 高并发与扩展设计（10万~100万 QPS）

6.1 容量分解（建议）

1. 10万 QPS：网关 8~12 实例（按压测修正），单实例 8C16G 起步。
2. 50万 QPS：网关 30+ 实例，读流量优先走只读副本。
3. 100万 QPS：需网关集群 + 协议代理层 + 高命中缓存 + 数据分层策略。

6.2 关键技术点

1. 认证与策略走内存/Redis 缓存，减少元数据库热点。
2. 连接池分层：全局上限 + 租户上限 + 读写分池。
3. 慢 SQL 与大事务保护：阈值告警 + 熔断。
4. 热租户治理：自动限速、熔断、降级。

7. 99.99 可用性设计

7.1 单点消除

1. 网关至少 2 实例 + 负载均衡健康检查。
2. 元数据存储采用高可用主从/多副本。
3. 审计与指标链路异步化，避免主路径硬依赖。

7.2 发布与回滚

1. 蓝绿或金丝雀发布，按租户灰度。
2. 每次发布必须有自动回滚开关。
3. 变更窗口必须绑定 Runbook 与值班负责人。

8. 安全设计

1. API Key 仅存 hash，不存明文。
2. 应用 DB 密码必须加密存储（AES-GCM/KMS）。
3. 管理会话防 CSRF、防重放。
4. 敏感字段日志脱敏（token/password/sql 原文可配置关闭）。
5. 支持 mTLS/IP allowlist（生产建议）。

9. 监控与告警

9.1 必备指标

1. 网关：QPS、错误率、P95/P99/P99.9、inflight、429 比例。
2. 租户：每 app 的 QPS、错误率、慢 SQL 数、拒绝数。
3. MySQL：连接数、主从延迟、行锁等待、死锁、慢查询。

9.2 告警门槛（建议初版）

1. 5 分钟错误率 > 1% 告警。
2. 5 分钟 P99 > 目标上限 2 倍告警。
3. 单租户拒绝率异常飙升告警。
4. 审计写入堆积超过阈值告警。

10. 落地决策（ADR）

1. ADR-001：隔离边界以数据库权限为主，不依赖 SQL 文本规则。
2. ADR-002：控制面保留 HTTP；数据面长期演进到 MySQL 协议代理。
3. ADR-003：元数据从 SQLite 迁移到高可用数据库（MySQL/PostgreSQL）。
4. ADR-004：审计链路异步化，主路径仅写轻量事件。

11. 验收标准

1. 隔离验收：20 应用互相越权访问 100% 拒绝。
2. 性能验收：分阶段达到 10万/50万/100万 QPS 目标。
3. 稳定性验收：连续压测 72 小时无 P0 故障。
4. 可用性验收：上线后月度达到 99.99%。