4. 租户隔离策略工程

多租户配置中心一旦进入生产环境，隔离策略就不再是“要不要隔离”的问题，而是“隔离到什么粒度、隔离在哪一层、愿意为此付出多少成本”的工程决策。逻辑隔离、物理隔离与混合隔离，本质上是在资源复用率、故障爆炸半径、合规强度和运维复杂度四个维度上做取舍。理解这三者的实现方式与代价，才能为不同租户分层设计出可落地的隔离方案。

三种隔离策略的本质差异

逻辑隔离指多个租户共享同一套存储、计算与网络资源，通过数据字段（如 tenant_id）在应用层或数据库层做数据归属区分。它的核心特征是“共享基础设施，靠标识与权限切分数据”。典型实现包括：配置表中每行带 tenant_id 列，查询时强制拼接租户条件；缓存 key 加租户前缀；消息队列按租户打 tag 或使用独立 topic。

物理隔离指每个租户独占独立的数据库实例、命名空间、消息集群甚至独立部署单元。租户之间不共享任何运行时资源，数据在物理层面天然分离。它的核心特征是“资源独占，边界由基础设施保证”。

混合隔离则是分层组合：核心敏感数据走物理隔离，非敏感配置走逻辑隔离；或大客户独享实例，中小客户共享集群。它承认“一刀切”不经济，转而按租户等级、数据敏感度和负载特征做差异化编排。

选型依据：从四个维度做判断

选型不能只看“哪个更安全”，而应围绕以下四个维度建立判断框架。

第一，数据敏感度与合规要求。如果租户配置中包含密钥、连接串、个人身份信息或受行业监管的数据（如金融、医疗），逻辑隔离往往无法通过合规审计，必须走物理隔离或至少独立加密密钥。反之，仅包含功能开关、超时阈值等非敏感参数，逻辑隔离即可满足。

第二，租户规模与付费等级。大客户通常要求资源独占、性能可预期、故障不牵连。中小租户对成本敏感，愿意接受共享资源。因此常见做法是按付费等级分层：VIP 租户物理隔离，标准租户逻辑隔离。

第三，故障爆炸半径容忍度。逻辑隔离下，一个租户的异常查询或缓存击穿可能拖垮整个共享集群，影响所有租户。物理隔离将爆炸半径限制在单租户内。若业务对“一个租户故障不影响其他租户”有硬性要求，物理隔离是唯一选择。

第四，运维与交付成本。物理隔离意味着每新增一个租户就要创建数据库、配置网络、初始化 schema、纳入监控，交付周期从分钟级拉长到小时级甚至天级。逻辑隔离新增租户只需插入一条记录。混合隔离则需要在路由层、配置管理层和监控层都做额外设计。

实现方式：从数据面到控制面

逻辑隔离的实现重点在“强制过滤”。以配置查询为例，所有 SQL 必须携带租户条件，且不能依赖调用方自觉传入。推荐在数据访问层做统一拦截：

-- 逻辑隔离：查询配置项
SELECT config_key, config_value
FROM tenant_config
WHERE tenant_id = #{tenantId}
  AND config_key = #{key}
  AND status = 1;

-- 缓存 key 设计
config:{tenantId}:{env}:{configKey}

为防止漏加 tenant_id 导致越权，可在数据库层启用行级安全策略（如 PostgreSQL RLS），或在 ORM 层做强制条件注入。缓存侧则要确保 key 前缀包含租户标识，避免不同租户读到彼此的缓存。

物理隔离的实现重点在“资源编排”。每个租户对应一套独立的连接配置，配置中心需要维护租户到数据源的映射表。新增租户时，通过自动化脚本完成实例创建、schema 初始化、权限授予和监控接入。配置读取时，路由层根据 tenantId 选择对应数据源。

混合隔离的实现重点在“路由与分层”。通常引入租户元数据表，记录每个租户的隔离级别、数据源标识和敏感配置范围。读取配置时，先查元数据判断走共享集群还是独立实例；写入时，敏感配置强制写入物理隔离存储，普通配置写入共享存储。这种方案的关键是保证路由逻辑对所有读写路径一致，避免出现“读走共享、写走独立”导致的数据不一致。

成本权衡：算一笔可比较的账

假设一个配置中心服务 200 个租户，每租户平均 500 条配置，日均读取 100 万次。逻辑隔离下，一套 4 核 8G 数据库加一个 Redis 集群即可支撑，月成本约 3000 元。物理隔离下，若每个租户独立数据库，即使按最小规格 1 核 2G 计算，200 个实例的月成本也远超 10 万元，且运维人力成倍增加。混合隔离下，假设 10 个大客户物理隔离、190 个中小客户逻辑隔离，成本约为逻辑隔离的 1.5 到 2 倍，但能满足大客户的合规与性能要求。

落地建议：从逻辑隔离起步，按需演进

对大多数 SaaS 配置中心而言，推荐以逻辑隔离为默认策略，在数据访问层和缓存层建立强制的租户过滤机制，确保基础安全。当出现以下信号时，再向混合或物理隔离演进：大客户合同明确要求资源独占；合规审计指出共享存储不满足要求；某个租户的配置量或访问量已影响其他租户；故障复盘显示共享集群的爆炸半径不可接受。

演进过程中，租户元数据表和路由层要提前设计好，使隔离级别成为可配置属性，而不是写死在代码里。这样，同一个租户可以从逻辑隔离平滑迁移到物理隔离，只需修改元数据并迁移数据，无需改动业务代码。隔离策略的工程价值，最终体现在“能按租户灵活调整，且调整成本可控”上。