构建 SaaS 产品的多租户架构：数据隔离模式及选择方法

许多 SaaS 产品都源于最初为一家公司开发的应用。系统运行良好，随后另一家公司想使用，接着又来了一家。这时产品负责人就要面对一个影响长达数年的技术决策：如何用一个应用服务众多客户，既不让数据混在一起，又不让服务器成本失控，也不让团队在每次更新时疲于奔命。

解决这一需求的模式称为多租户架构。每个客户，即租户，使用同一个应用，但其数据在逻辑上或物理上相互隔离。本文介绍三种常见的数据隔离模式、各自的优势与风险、定制化和计费等常被遗忘的问题，以及如何根据业务阶段选择合适的模式。

摘要

• 多租户是指一个应用服务多个客户，每个客户的数据彼此隔离
• 三种主要模式是带租户字段的共享表、每租户一个模式（schema）以及每租户一个数据库
• 共享表最省成本、最易更新，但需要多层防护以防止租户之间的数据泄露
• 每租户一个数据库为大型或受监管客户提供最强隔离，但运维成本更高
• 混合模式往往是成熟的选择：小租户共享资源，企业租户拥有独立数据库

单租户还是多租户？

在单租户架构中，每个客户都有一套独立的应用和数据库。这种方式起初简单，也让人感觉安全，但每增加一个客户，就要多部署、监控、备份和更新一台服务器。十个客户尚可应付；到了一百个客户，团队会把大部分时间花在一遍遍发布同一个版本上，而且各客户往往运行着不同的版本。

多租户则扭转了这种局面。一套代码、一次发布流程、资源共享，因此每个客户的成本随之下降。挑战转移到了隔离上：确保 A 公司的用户永远看不到 B 公司的数据，并且某个非常活跃的客户不会拖慢其他所有人。两者之间的选择与您希望采用的订阅商业模式密切相关，因为 SaaS 的利润高度依赖于服务每个客户的成本。

三种数据隔离模式

1. 带租户字段的共享表

所有客户的数据存储在同一组表中，每一行都带有租户标识字段。这是最经济的模式：一个数据库、一套模式，结构迁移只需运行一次。适合拥有大量中小客户的产品。

风险也显而易见：只要有一条查询忘记按租户过滤，就可能显示其他客户的数据。因此，防护措施不能只依赖程序员的自律。PostgreSQL 等现代数据库提供行级安全（row-level security），即在数据库层面根据当前租户自动限制可读取的行。再结合应用中始终带上租户条件的数据访问层，以及刻意尝试读取其他租户数据的自动化测试。

2. 每租户一个模式

每个客户在同一个数据库中拥有一个独立模式，相当于一块单独的空间。由于表确实是分开的，隔离性更强，单独备份或恢复某个客户也更容易。缺点在客户增多时显现：每次结构变更都要在数百个模式上执行，一次中途失败的迁移会导致模式版本不一致。这种模式适合租户数量中等、隔离要求较高的情况。

3. 每租户一个数据库

每个客户拥有自己的数据库，而应用代码仍然只有一套。这种模式隔离最强，支持按客户设置加密密钥、按客户进行时间点恢复，还可以把大客户迁移到独立服务器或特定区域以满足数据驻留要求。代价在于运维：每个数据库都需要单独的迁移、备份、监控和连接。如果缺乏良好的自动化，这种模式又会变得像单租户一样繁琐。

适合成长型产品的混合模式

许多成熟的 SaaS 产品采用组合方式。基础套餐客户共享表，而付费更多或有监管要求的企业客户则获得独立数据库。应用通过租户目录，即记录每个客户数据所在位置的清单，把每个请求路由到正确的数据库。这样，额外的隔离可以作为定价套餐的一部分出售，而不必成为所有客户的负担。

吵闹邻居问题

在共享系统中，某个客户导入数百万行数据或运行大型报表，可能会拖慢所有人的应用。这通常被称为吵闹邻居（noisy neighbor）问题。应对方法包括按租户限制请求频率、把导入和报表等繁重工作移到后台队列、按套餐设置存储配额，以及按租户监控资源使用。数据库性能优化技巧，例如以租户字段开头的索引，也非常有帮助。

常被遗忘的事项

• 按客户定制：提供可配置的设置、附加字段和流程，而不是为每个客户分叉代码
• 身份与访问：一个用户可能属于多个租户，企业客户常常要求通过公司 SSO 登录
• 计费：从一开始就按租户记录用量，因为定价套餐几乎总会随着产品成长而变化
• 数据导出与删除：客户有权取回自己的数据，并在退订时要求删除
• 按租户的审计记录：谁在何时做了什么，对接受审计的客户尤为重要
• 测试环境：大客户常常要求提供沙箱，以便在新功能上线前进行测试

企业登录需求在SSO 与身份管理一文中有更详细的说明，而每个租户内部的用户角色设置则遵循设计用户访问权限的原则。

B2B 客户要求的安全与合规

一旦 SaaS 产品开始向中大型企业销售，客户的采购团队几乎总会发来一份安全问卷。常见问题包括：不同客户的数据如何隔离、存储在哪里、存储和传输时是否加密、备份保留多久、您团队中有哪些人可以访问客户数据，以及如何通报安全事件。清晰且有文档支撑的回答能加快成交。

• 用非技术团队也能理解的语言，记录租户隔离模式及其多层防护措施
• 限制并记录内部员工对客户数据的访问，例如只允许通过已批准的支持请求访问
• 准备按租户的恢复计划，包括恢复单个客户数据所需的时间
• 遵守客户所在国家的个人数据保护规定，包括发生泄露时的通知义务

在不打扰客户的情况下发布与更新

多租户的主要优势在于所有客户共用一次发布流程，但前提是发布必须安全。借助自动化测试与 CI/CD，确保每次变更在发布前都经过测试；采用向后兼容的数据库迁移，让新旧版本可以短暂并行运行；使用功能开关逐步启用新功能，例如先对内部租户开放，再对部分客户开放，最后全面上线。

还要按租户监控系统健康状况，而不仅仅看平均值。良好的平均响应时间可能掩盖某个大客户正经历严重卡顿。记录租户标识的可观测性与日志能让这类问题迅速暴露。

如何根据业务阶段选择模式

1. 01估算未来两到三年的客户数量以及每个客户的平均数据量
2. 02找出受法规或合同约束、要求物理隔离或特定数据位置的客户
3. 03对于大多数 B2B 产品，除非有充分理由，否则从共享表加行级安全开始
4. 04把租户解析逻辑集中在一层，以便日后为特定客户增加独立数据库
5. 05实现新租户开通的自动化，从注册到初始数据，不依赖人工操作
6. 06在第一个大客户到来之前，设置用量上限和按租户的监控

如果您正在把内部应用改造成 SaaS 产品，这一决策应与单体还是微服务等其他架构选择一并考虑。对于大多数早期产品而言，一个结构清晰、租户隔离严密的单体应用，远比几十个小服务更容易管理。

常见问题

多租户比单租户更不安全吗？不一定。采用多层防护设计的多租户系统可以非常安全，而且一套始终保持更新的代码，往往比数百个版本落后的独立安装更安全。不过，某些客户仍可能要求物理隔离。

现有的单租户应用能改造成多租户吗？可以，但需要规划：为数据添加租户标识、调整所有查询、合并多个安装的数据，并测试隔离效果。这一过程类似于遗留系统现代化，最好分阶段进行。

客户要求特殊功能怎么办？优先考虑可以通过设置或套餐启用的功能，从而保持一套代码。为单个客户建立专用代码分支，会让多租户失去主要优势。

构建多租户 SaaS 产品需要多少成本？这取决于功能、集成数量和隔离级别。良好的隔离会增加前期工作量，但远比在产品被大量使用后修复数据泄露或迁移隔离模式便宜。

结论

多租户架构是 SaaS 产品的经济基础：一套代码、一次发布，每个客户的成本随规模增长而下降。关键在于选择符合客户和法规要求的数据隔离模式、以多层方式维护隔离、控制吵闹邻居，并及早为定制化、计费和数据导出等常被遗忘的需求做好准备。一开始做出正确的决策，产品就能在不重建的情况下服务十个乃至一万个客户。