3. 多租户架构演进：从共享数据库到共享服务，隔离边界的逐步模糊化

多租户架构的演进并非一蹴而就，而是随着业务规模、成本压力和合规需求的变化，逐步从物理/逻辑隔离向服务级隔离过渡。这一过程中，租户之间的隔离边界从清晰的数据库/表边界，逐渐模糊为服务契约与策略控制边界。

3.1 隔离模式演进三阶段

下表总结了从“共享数据库”到“共享服务”的典型演进路径，以及各阶段的核心隔离特征与代价。

3.2 演进驱动力与代价分析

每一次隔离边界的模糊化，背后都是成本与安全的再平衡。以下从三个维度拆解演进驱动力：

• 成本压力： 独立数据库/独立实例模式在租户数量增长时，运维成本和资源碎片急剧上升。共享服务模式可将资源池化，提升整体利用率 30%~50%。
• 运维复杂度： 独立部署意味着每个租户需要独立的 CI/CD、监控、备份策略。共享服务通过统一发布和灰度能力，将运维负担从 N 个租户收敛为 1 套平台。
• 合规与爆炸半径： 共享服务模式虽然降低了物理隔离，但通过 Sidecar 代理、OPA 策略、请求级审计 等手段，可将单租户故障/攻击的爆炸半径控制在单个请求或单个服务实例内。

3.3 隔离边界模糊化的典型架构：共享服务模式

下图展示了从“独立数据库”演进到“共享服务”后的典型部署拓扑。注意：租户隔离不再依赖数据库实例，而是依赖服务网格中的策略执行点。

3.4 隔离边界模糊化的关键设计模式

在共享服务模式下，隔离边界不再依赖物理资源，而是通过以下三种设计模式实现：

1. 请求上下文透传（Context Propagation）： 每个服务调用必须携带 X-Tenant-ID、X-User-ID 等上下文。服务框架（如 gRPC 拦截器、Spring Cloud Gateway 过滤器）自动注入，避免业务代码显式处理。
2. 策略即代码（Policy as Code）： 使用 OPA（Open Policy Agent）或 Casbin 定义租户访问规则。策略与业务逻辑分离，可在不重启服务的情况下热更新。
3. 数据行级安全（Row-Level Security, RLS）： 数据库层面通过 tenant_id 列和强制谓词过滤，确保即使服务层绕过策略，数据层仍能兜底。

3.5 演进中的常见陷阱与应对

3.6 演进路线图：何时选择哪种模式？

以下决策树可帮助架构师根据当前阶段选择隔离模式：

• 租户数量 < 50，且预算有限： 优先选择 共享数据库 + 行级隔离。快速上线，后期可通过数据迁移工具逐步拆分。
• 租户数量 50~500，且合规要求中等： 选择 独立 Schema 或独立数据库。隔离清晰，运维复杂度可控。
• 租户数量 > 500，且需要弹性伸缩： 必须演进至 共享服务模式。此时隔离边界完全依赖策略引擎和服务网格，需要投入平台工程能力建设。