基于Envoy的多租户流量隔离与故障域演练实战 - 第1节
1.1 多租户架构概述
多租户（Multi-Tenancy）是云原生时代最核心的架构模式之一。它允许一个软件实例同时服务多个相互隔离的租户（Tenant），每个租户拥有独立的业务视图、配置空间和资源配额，但在物理或虚拟层面共享底层基础设施。
在 Kubernetes 和 Service Mesh 环境中，多租户的粒度可以跨越集群、命名空间、服务账户甚至请求 Header 级别。下表总结了常见的多租户分层模型：
| 租户层级 | 隔离范围 | 典型场景 | Envoy 介入点 |
|---|---|---|---|
| 集群级 | 物理/虚拟集群 | 金融核心与非核心业务 | 集群间路由策略 |
| 命名空间级 | K8s Namespace | 开发/测试/生产环境隔离 | Sidecar 注入与 RBAC |
| 服务级 | Service + 版本 | 蓝绿部署、金丝雀发布 | 流量权重与 Header 匹配 |
| 请求级 | JWT / Header 字段 | SaaS 多租户（租户 ID） | L7 路由、速率限制、认证 |
关键认知： 多租户不是简单的“多用户”，而是要求租户之间在数据面（流量、配置、可观测性）和控制面（策略、配额、审计）上实现硬隔离或软隔离。Envoy 作为数据面代理，天然适合在请求路径上执行租户感知策略。
1.2 流量隔离的核心挑战
实现多租户流量隔离并非简单的网络 ACL 配置。在微服务架构中，流量可能跨越数十个服务，每个服务都可能成为租户数据泄露或性能干扰的薄弱点。以下是四个核心挑战：
- 租户感知路由：如何让 Envoy 在不解密业务 payload 的前提下，准确识别请求属于哪个租户？常见方案包括 Header 透传、JWT 声明提取、TLS 证书 SNI 区分。
- 资源争抢与公平调度：一个租户的突发流量可能耗尽连接池、线程或 CPU，导致其他租户的请求被饿死。Envoy 需要支持租户级连接池隔离和请求速率限制。
- 故障域爆炸半径控制：当某个租户的后端服务出现慢连接或熔断时，如何防止故障扩散到共享同一 Envoy 实例的其他租户？这要求 Envoy 具备按租户划分的熔断器和异常点检测能力。
- 可观测性维度爆炸：传统监控按服务聚合指标，多租户场景下需要按租户 + 服务 + 状态码组合下钻。Envoy 的 Access Log 和 Stats 必须支持动态 Tag 注入。
常见误区： 很多团队只在网关层做租户隔离，认为内部服务间流量不需要隔离。实际上，内部服务间的 Sidecar 流量同样需要租户上下文传递和熔断隔离，否则一个租户的故障会通过共享中间件（如 Redis、数据库连接池）传染给其他租户。
1.3 Envoy 在云原生中的角色
Envoy 是 CNCF 毕业的顶级项目，作为高性能 L3/L4/L7 代理，它在云原生架构中承担了三个关键角色：
- 数据面统一网关：替代 Nginx / HAProxy，提供动态路由、负载均衡、TLS 终止、限流熔断。
- 服务网格 Sidecar：与 Istio / Consul 集成，实现无侵入的流量劫持、可观测性和安全策略。
- 多协议适配器：原生支持 HTTP/1.1、HTTP/2、gRPC、TCP、MongoDB、Redis 等协议，适合异构系统。
下图展示了 Envoy 在多租户流量隔离中的核心位置：
Envoy 之所以成为多租户流量隔离的首选数据面，是因为它提供了以下原生能力：
| 能力维度 | Envoy 实现机制 | 多租户价值 |
|---|---|---|
| 动态路由 | 基于 Header / Metadata 的 VirtualHost 匹配 | 按租户 ID 分发到不同后端集群 |
| 速率限制 | 全局/本地限流 + 按描述符分区 | 防止单个租户打爆共享资源 |
| 熔断器 | 按集群配置连接池、最大请求、熔断阈值 | 租户级故障域隔离 |
| 可观测性 | 动态 Tag 注入到 Access Log / Metrics | 按租户维度监控和告警 |
| 安全策略 | RBAC + JWT 认证 + 外部授权 | 租户间数据访问控制 |