multi-tenant 架构：可扩展 SaaS 的基石

如果你正在打造一个 SaaS，“multi-tenant”这个词很快就会出现，而且它绝非无关紧要的术语：它是决定你的产品如何扩展、运营成本多高，以及客户数据有多安全的关键抉择。我们来把它讲清楚。

什么是 multi-tenant

multi-tenant（多租户）意味着你的应用只用一个实例就同时服务众多客户（租户），同时保持每个客户的数据相互分离且私密。这就像一栋公寓楼：只有一座建筑，但每位租户都有自己封闭的空间。另一种选择 single-tenant，则是为每个客户准备一整份应用的副本：起初简单，但在规模上昂贵且难以管理。

为什么它如此重要

multi-tenant 正是让 SaaS 模式盈利的原因：你只维护一个系统，一次性为所有人推出改进，并高效利用基础设施。一个好的 multi-tenant 架构能让你从 10 个客户增长到 10,000 个客户而无需重写产品；一个糟糕的架构则会在你刚开始成长时迫使你进行痛苦的重写。

几种模型：如何隔离数据

隔离每个客户数据主要有三种方式，它们在成本、隔离度和复杂度之间各有不同的权衡：

• 共享数据库：所有客户在相同的表中，用一个标识符区分。最便宜也最高效；需要格外小心以免混淆数据。
• 按客户分 schema：同一个数据库里为每个客户分配单独的 schema。在隔离度和成本之间取得平衡。
• 按客户分库：每个客户拥有自己的数据库。隔离度最高（适合极敏感数据），但运营成本更高。

数据隔离与安全

multi-tenant SaaS 最大的风险是一个客户看到另一个客户的数据。因此隔离不是可选项：它要在数据层设计，并通过每次请求的访问控制来加固。一个好的 multi-tenant 设计能让一个租户在技术上根本不可能访问到另一个租户的信息，并会专门针对这一点进行测试。

可扩展性与成本

所选模型在多年里决定着你的基础设施账单。共享数据库以最低的单客户成本扩展，因此在大流量 SaaS 中最为常见。隔离度更高的模型单客户成本更高，但当你向监管行业（医疗、金融）销售、需要严格分离时，它才是正确的选择。

何时选择哪种模型

没有放之四海皆准的赢家。对于客户众多的 B2C 或中小企业 SaaS，共享数据库通常最合适。对于客户少而大、数据敏感的企业级 SaaS，按 schema 或按库隔离更划算。重要的是在一开始就决定，因为在有客户在生产环境时从一种模型迁移到另一种代价高昂。

设计 multi-tenant 时的常见错误

最昂贵的失误通常有两类：为了“以防万一”选择隔离度最高的模型，从而不必要地推高基础设施账单；或反过来，在共享数据库中混放数据却没有健壮的隔离，冒着客户间数据泄露的风险。另一个经典错误是把决策推到“以后再说”：在有客户在生产环境时更换模型，是世上最昂贵、最冒险的事情之一。请尽早决定，把你的客户类型和安全需求摆上桌面，并把隔离当作一项需求来设计，而不是事后的附加项。

在 AxiomTech，我们根据你的客户类型和安全需求设计你 SaaS 的 multi-tenant 架构，让它高效扩展，并让每个客户的数据始终保持隔离。