多租户服务需在入口层提取租户ID并注入context.Context，数据层通过tenant_id字段与自动WHERE条件实现行级隔离，K8s中用Namespace+ResourceQuota做资源隔离，密钥则通过租户专属Secret与Vault动态分发。
租户标识与请求上下文注入
多租户服务的起点是准确识别当前请求属于哪个租户。推荐在入口层（如API网关或HTTP中间件）从请求头（X-Tenant-ID）、子域名（tenant1.example.com）或JWT声明中提取租户ID，并将其注入到请求上下文（context.Context）中。避免全局变量或单例存储租户信息，防止goroutine间污染。例如：
- 定义
ctx = context.WithValue(ctx, tenantKey{}, tenantID)传递租户上下文 - 所有数据库查询、缓存操作、日志打点都应基于该上下文获取租户ID
- 使用结构化上下文键（非字符串）避免类型冲突，如
type tenantKey struct{}
数据层租户隔离：共享数据库 + 行级隔离
云原生场景下，通常采用“单数据库多租户”模式兼顾成本与运维效率，关键在于严格行级隔离。GORM、sqlc 或 pgx 等主流库均可支持：
- 为每张核心业务表添加
tenant_id字段，并建立复合索引（如(tenant_id, id)）提升查询性能 - 封装通用查询构造器，在生成SQL时自动注入
WHERE tenant_id = ?条件，杜绝手写SQL遗漏 - 敏感操作（如DELETE、UPDATE）必须校验租户上下文，可借助GORM的
Scopes或自定义QueryHook统一拦截 - 禁用跨租户的
SELECT *裸查，强制通过租户感知的服务层方法访问数据
运行时资源隔离：命名空间与配额控制
在Kubernetes环境中，租户逻辑隔离应映射到底层资源隔离。不建议为每个租户部署独立集群，而应利用命名空间（Namespace）+ RBAC + ResourceQuota 实现轻量级隔离：
- 为每个租户动态创建独立Namespace，服务发现、配置、密钥均限定在该空间内
- 通过Operator或Controller监听租户CRD（CustomResource），自动创建对应Namespace、ServiceAccount和NetworkPolicy
- 绑定
ResourceQuota限制CPU、内存、Pod数等，防止单个租户耗尽集群资源 - Golang后端可通过client-go调用K8s API，实现租户生命周期与基础设施联动（如租户注销时自动清理Namespace）
密钥与凭证的租户级安全分发
租户专属配置（如数据库密码、第三方API密钥）绝不能硬编码或共用Secret。
需结合K8s Secret + 外部密钥管理服务（如HashiCorp Vault、AWS Secrets Manager）：
- 每个租户对应一个独立Secret对象，名称含租户标识（如
tenant-a-db-creds），挂载到对应Pod的指定路径 - 启动时通过
os.Getenv("TENANT_ID")或上下文动态加载租户专属Vault token，按路径读取secret/tenant/{id}/db - 禁止将密钥以明文形式记录日志或返回API响应；使用
zap.String("tenant_id", tid)替代敏感字段打点 - 定期轮换密钥时，由租户管理服务触发事件，更新Secret并滚动重启相关Workload
