多租户架构基础：租户隔离模型与签名链路上下文
多租户（Multi-Tenancy）是 SaaS 签名平台的核心架构模式。一个签名链路项目往往同时服务数十到数千个企业客户（租户），每个租户的数据必须严格隔离，同时签名请求在流转过程中需要准确识别当前操作所属的租户。本章从隔离模型、上下文传递和配置管理三个维度展开。
2.1 三种租户隔离模型对比
隔离模型决定了数据存储层如何划分租户边界。主流方案有三种：行级隔离、Schema 隔离和数据库隔离。下表从隔离强度、运维成本和签名链路适配难度三个关键维度进行对比。
| 隔离模型 | 隔离强度 | 运维成本 | 签名链路适配难度 | 典型场景 |
|---|---|---|---|---|
| 行级隔离 | 低（逻辑隔离） | 低 | 低（仅需 tenant_id 字段） | 中小规模、租户数 > 1000 |
| Schema 隔离 | 中（结构隔离） | 中 | 中（需动态切换 schema） | 中型租户、定制化需求 |
| 数据库隔离 | 高（物理隔离） | 高 | 高（多数据源路由） | 金融、政务等高合规场景 |
架构建议：签名链路项目通常采用混合隔离策略——核心签名记录使用行级隔离保证扩展性，而租户的个性化签名模板、印章配置使用 Schema 隔离，避免全局表膨胀。
2.2 签名链路中的租户上下文传递
在签名链路中，一个请求从 API 网关进入，经过认证、签名参数组装、签署流程编排、文件存储、审计日志等多个微服务。租户上下文必须在整个调用链中无中断传递，否则会导致数据泄露或签名失败。
下图展示了签名链路中租户上下文的传递路径与关键节点。
上下文传递关键原则：
- 入口处提取：API 网关或认证服务从 JWT 或 中解析出 tenant_id。
- 透传不修改：中间服务不得篡改 tenant_id，仅做转发。
- 异步消息继承：使用消息队列时，将 tenant_id 写入消息头，消费者消费时恢复上下文。
- 日志染色：在日志 MDC 中注入 tenant_id，便于链路追踪和审计。
2.3 租户配置管理
每个租户在签名链路中拥有独立的配置项，包括签名策略、印章权限、通知模板、存储配额等。配置管理需要支持动态加载和租户级覆盖，避免因配置变更导致服务重启。
下图展示了租户配置的分层结构与动态加载机制。
2.4 配置管理的工程实践
在签名链路项目中，租户配置管理需要关注以下工程要点：
- 配置版本化：每次配置变更记录版本号，支持回滚到指定版本。
- 配置校验：租户配置写入前进行合法性校验（如签名有效期不能为负数、印章大小限制等）。
- 缓存与失效：本地缓存配置，配置中心推送变更时主动失效缓存，避免长时间不一致。
- 配置审计：记录谁在什么时间修改了哪个租户的哪项配置，满足合规要求。
常见陷阱：不要将租户配置硬编码在代码或环境变量中。签名链路中租户数量可能快速增长，硬编码会导致每次新增租户都需要修改代码并重新部署，违背多租户架构的弹性原则。
2.5 隔离模型与配置管理的协同
隔离模型的选择直接影响配置管理的实现方式：
| 隔离模型 | 配置存储位置 | 配置加载方式 | 典型配置项 |
|---|---|---|---|
| 行级隔离 | 共享配置表 + tenant_id 字段 | SQL WHERE tenant_id = ? | 签名有效期、通知模板 |
| Schema 隔离 | 每个 Schema 独立配置表 | 动态切换 Schema 后查询 | 印章样式、审批流程 |
| 数据库隔离 | 独立数据库配置表 | 多数据源路由 | 存储配额、加密密钥 |
无论采用哪种隔离模型，配置管理都应遵循分层覆盖和动态推送的原则，确保签名链路在租户数量增长和配置变更时保持稳定与可追溯。