多租户架构实践：从单点到规模化

当产品从服务单个团队走向服务多家企业，多租户就成了绕不开的课题。本文记录我们在这一路上的取舍。

隔离方案怎么选

三种主流方案各有代价，选择取决于客户的合规要求与规模，没有一个方案能同时满足所有情况，关键是先想清楚自己的客户结构。方案一旦确定，迁移成本往往很高，需要提前权衡。 我们的做法是允许两种方案并存：中小客户走共享库，强合规客户走独立库，通过统一的接入层屏蔽差异，业务代码无需关心底层部署形态。

• 共享库共享表：成本最低，隔离最弱，适合中小客户
• 共享库独立表：折中方案，迁移成本适中
• 独立库：隔离最强，运维成本最高，适合强合规客户

租户级配置

功能开关、品牌信息与配额都需要按租户覆盖。我们把配置分成"平台默认、租户覆盖"两层，避免每个租户都写一份完整配置。配置读取有统一入口，业务代码不直接依赖存储细节。 这样做的另一个好处是升级方便：新增配置项时只需给平台默认值，未覆盖的租户会自动继承，不必逐个修改。默认值的改动也要有记录，方便回溯某项行为的变更来源。

灰度发布

新版本先对内部租户开放，再按比例放量。发布系统支持按租户 ID 精确指定，出问题时可以只回滚受影响的部分，而不影响全局。 每次灰度都会记录租户列表与观察指标，达到稳定标准后再进入下一批，把风险控制在尽可能小的范围内。若某批出现异常，可以单独回滚而无需影响已稳定的租户。

监控与告警

多租户环境下，监控必须能按租户维度下钻，否则一个客户的异常很容易被整体指标掩盖。我们在每个关键路径上都带上了租户标识，出现问题可以直接定位到具体客户。 除了技术指标，我们也关注租户维度的业务指标，比如平均登录人数与流程执行量。当某个客户的活跃度突然下降，往往意味着上线遇到了阻力，值得提前介入。 这套监控体系也反过来影响了架构决策。因为能按租户观察到真实负载，我们在做容量规划时更有依据，不必为了个别大客户长期预留大量闲置资源，成本也因此更可控。

多租户的难点不在隔离技术，而在隔离之后还能不能统一升级。