Java微服务多租户架构中，网关层负责租户识别与上下文透传，数据库层按独立库、独立Schema或共享表三种模式隔离数据，二者需通过租户上下文绑定、动态数据源路由和ORM强制过滤协同工作。
Java 微服务多租户架构中，网关层负责请求的统一入口与租户识别，数据库层则需隔离或区分不同租户的数据。关键不在于“是否支持多租户”，而在于选择适合业务规模和安全要求的隔离策略，并让网关与数据库协同工作。
网关层：识别租户并透传上下文
网关（如 Spring Cloud Gateway 或自研网关）是租户识别的第一道关卡。它不处理业务逻辑，但必须可靠地提取租户标识，并将其安全传递给下游微服务。
-
租户标识来源常见方式：HTTP Header（如
X-Tenant-ID）、子域名（tenant1.api.example.com）、请求路径前缀（/t/tenant1/users）或 JWT Claim（在认证后解析 token 中的tenant_id字段） - 验证与过滤：网关应校验租户 ID 是否合法、是否启用、是否有访问当前服务的权限；非法租户请求直接拦截，返回 403
-
透传方式：将租户 ID 注入到下游请求头（如保留
X-Tenant-ID），或通过 ThreadLocal + MDC 在内部链路中传递（适用于 Feign 调用或 Dubbo 泛化调用等场景） - 注意点：避免在 URL 参数中传递租户 ID（易被篡改、日志泄露风险高）；Header 名称应统一且不可被客户端覆盖（网关需清理原始请求中的可疑 header）
数据库层：按租户隔离数据的三种主流模式
数据库设计决定多租户的安全性、扩展性和运维成本。Java 微服务中常用以下三种方式，可单独使用，也可组合（如核心租户表分库，日志类表共享）：
-
独立数据库（Database-per-Tenant）：每个租户独占一个物理库（如
tenant_a_db,tenant_b_db）。适合强隔离、合规要求高（如金融、医疗）的场景。网关识别租户后，服务需动态切换数据源（通过 AbstractRoutingDataSource 或 ShardingSphere 的多数据源路由） -
共享数据库，独立 Schema（Schema-per-Tenant）：所有租户共用一个数据库实例，但各自拥有独立 schema（如 PostgreSQL 的 schema，MySQL 8.0+ 的 schema 模拟）。隔离性好于共享表，管理比独立库轻量。JDBC 连接 URL 或初始化时指定 schema，MyBatis 可配合
@SelectProvider动态拼接schema.table -
共享数据库 & 共享表（Shared Database and Shared Schema）：所有租户数据存在同一套表中，靠
tenant_id字段做逻辑隔离。最省资源，但依赖开发规范和框架约束（如 MyBatis-Plus 的多租户插件自动追加 WHERE 条件）。必须全局开启 SQL 审计，禁止手写原生 SQL 绕过 tenant_id 过滤
网关与数据库联动的关键实践
光有网关识别和数据库隔离还不够，需建立贯穿请求生命周期的信任链和执行约束：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
租户上下文绑定线程：网关解析出
tenantId后，通过 Filter 或 GlobalFilter 写入TenantContextHolder（基于 InheritableThreadLocal），后续所有 DB 操作、缓存 key、日志 trace 都能获取该值 -
数据源路由自动化：结合 Spring 的
AbstractRoutingDataSource，重写determineCurrentLookupKey()方法，从上下文中读取租户 ID，匹配预配置的数据源名（如 “ds-tenant-a”） -
ORM 层强制租户过滤：使用 MyBatis Plus 多租户插件时，配置
tenantLineInnerInterceptor，指定哪些表需要自动添加tenant_id = ?条件；对忽略插件的 XML SQL，可通过自定义StatementHandler插件二次校验 - 连接池与租户绑定（可选）：HikariCP 本身不支持租户级连接池，但可通过包装 DataSource 实现“租户连接池池化”，避免高频切换导致连接创建开销过大（适用于租户数中等、QPS 高的场景）
补充：租户元数据与动态配置
租户不是静态常量，其数据库地址、加密密钥、功能开关等可能动态变化。建议引入租户元数据中心（如 Nacos 配置中心 + MySQL 租户表）：
- 网关启动时加载租户白名单及基础策略
- 服务启动时订阅租户配置变更事件（如租户停用、DB 迁移），触发本地数据源刷新
- 数据库连接信息（URL、username）不应硬编码，而是根据租户 ID 从元数据中心实时拉取或缓存
不复杂但容易忽略的是租户上下文的清理——异步线程、定时任务、Dubbo 回调等场景下，ThreadLocal 可能残留旧租户 ID，导致数据错乱。务必在请求结束或线程复用前显式清除。
