「产品矩阵平台」多租户与多应用设计

第五章 多租户与多应用设计

多租户设计的目标，不是简单给每张表加一个 tenant_id。真正的目标是：同一套平台能服务多个组织、多个产品、多个环境，同时保证数据隔离、配置独立、权限清晰和成本可控。

产品矩阵平台中，多租户和多应用是两个不同维度：

5.1 多租户隔离策略

常见隔离方式有三种：

平台可以采用混合策略：默认共享库共享表，大客户升级为独立库，审计、账单等平台公共数据仍保留在中心库。

5.2 Tenant、App 与 Namespace 模型

建议模型关系：

erDiagram
    TENANT ||--o{ APP : owns
    APP ||--o{ APP_ENV : has
    APP ||--o{ APP_CONFIG : configures
    TENANT ||--o{ MEMBERSHIP : has
    USER ||--o{ MEMBERSHIP : joins

核心字段：

AppID 和 AppSecret 不应直接等同于数据库主键。它们是对外凭证，应可轮换、可禁用、可审计。

5.3 租户上下文注入

租户上下文应在请求入口统一解析。

解析来源可以按优先级排列：

1. 自定义域名，如 acme.example.com；
2. Header，如 X-App-ID；
3. JWT Claims，如 tenant_id、app_id；
4. 路径前缀，如 /t/{tenant_slug}；
5. 开放平台签名参数。

解析完成后写入 context.Context，后续 Service、Repository、日志、审计都从上下文读取。

5.4 数据表 Schema 设计

共享表模式下，业务表至少要有：

索引不能只按业务字段建。例如内容表常见查询是“某租户某 App 下按状态分页”，索引应考虑：

CREATE INDEX idx_contents_tenant_app_status_time
ON contents (tenant_id, app_id, status, published_at);

缺少 tenant_id 前缀的索引，在多租户数据量变大后会非常昂贵。

5.5 应用注册与生命周期管理

App 不是一条配置记录，而是有生命周期的对象。

created -> configured -> verified -> active -> suspended -> archived

生命周期变化必须写审计日志，尤其是暂停、恢复、密钥轮换和删除。

5.6 App 配置分层

配置继承顺序建议为：

platform default
  -> tenant default
  -> app config
  -> namespace config
  -> runtime override

读取配置时要返回“最终值”和“来源”。运维排障时，知道某个开关为什么是 true，往往比值本身更重要。

5.7 SaaS 层级设计

平台可支持三种 SaaS 形态：

白标 SaaS 需要更强的主题、域名、邮件发件人、支付主体和备案支持，不能只换 Logo。

5.8 API 网关级多租户路由

网关应在转发前完成租户识别和基础校验。

生产环境优先推荐域名或 Header，路径模式适合开发、测试和内部工具。

5.9 常见风险

多租户不是一个功能点，而是贯穿身份、数据、配置、日志、计费和运维的系统约束。