负载均衡接入企业级多租户系统的核心是保障租户级sla，需在入口层前置租户识别（host/路径/请求头），透传x-tenant-id，拒绝匿名流量；按租户分级限流、保底资源、动态配额；后端实现unit资源隔离、租户感知数据源路由及中间件命名空间划分；域名路由强化边界，校验host与租户id一致性。
负载均衡接入企业级多租户系统，核心不是简单把流量“分出去”，而是让每个租户在共享基础设施上获得可预期的响应速度、资源保障和故障边界。关键在于：租户识别要早、隔离策略要细、调度逻辑要有优先级意识。
租户标识必须前置到入口层
所有后续隔离都依赖准确、稳定的租户身份。不能等到业务代码里才解析——那已经晚了。
- 推荐在反向代理（如 Nginx、API 网关）或 DNS 层就完成租户提取：通过 Host 头（tenant1.example.com）、URL 路径（/t/tenant23/api/search）或请求头（X-Tenant-ID: t-456）识别租户
- 提取后需透传给下游服务，避免重复解析；建议统一注入标准头（如 X-Tenant-ID），所有中间件和服务都按此约定处理
- 对未携带租户标识的请求，应直接拒绝或路由至默认沙箱租户，防止“匿名流量”冲击核心租户资源
按租户维度做流量分级与限流
不同租户的业务重要性、SLA 要求、调用量级差异很大，不能一视同仁地轮询或随机分发。
- 为高优先级租户（如付费 VIP、核心客户）配置独立的上游服务池，并设置最小实例保底数，避免被低优租户挤占
- 在网关层对每个租户设置 QPS、并发连接数、单次请求超时等硬性阈值；超出时返回 429 或降级响应，而非堆积等待
- 支持动态调整：可通过配置中心实时下发租户配额变更（例如大促期间临时提升某租户 CPU 配额 30%）
后端服务层实现逻辑资源单元隔离
光靠流量调度不够，必须让租户真正“跑在自己的资源片上”，避免噪声邻居干扰。
- 参考 OceanBase 的 Unit 模型：为每个租户分配若干个逻辑资源单元（含 CPU 核心、内存、IOPS 配额），这些 Unit 自动分散部署在不同物理节点上，天然实现负载分散
- 数据库访问层使用租户感知的数据源路由（如 Spring 的 AbstractRoutingDataSource），确保 SQL 请求只打到该租户专属 Schema 或库实例
- 搜索、缓存等有状态中间件，也需按租户划分命名空间（如 Redis key 前缀 t-789:user:1001，Elasticsearch index 名带租户前缀 tenant_abc_orders_v2）
域名与路由策略强化租户边界感
用户感知层面的隔离，是 SaaS 体验的重要一环，也能辅助技术侧做更精准的调度。
- 支持租户绑定独立子域名（hr.company-a.com）或泛域名（*.company-b.io），Nginx 或云厂商 WAF 可基于 Host 直接分流至对应后端集群
- 同一租户可配置多套环境路由规则，例如：dev.company-c.com → 测试集群，app.company-c.com → 生产集群
- 禁止跨租户域名混用：校验请求 Host 与租户 ID 是否匹配，不一致则拦截，防止恶意构造 Host 头越权访问
