多租户架构详解：一个数据库服务1000个客户

多租户架构，说白了就是多个客户共用一个数据库，但每个客户只能看到自己的数据。一个独立创始人正是靠它，用同一个应用服务1,000家组织而无需重建任何东西——而它之所以成立，靠的是从第一天起每张表都必须有的一列：organization_id。

如果你在用AI构建SaaS，这是为数不多、事后无法低成本修正的架构决策之一。下面讲清楚多租户是什么、选错为什么要花上几个月，以及要给AI的确切规则，让它把这件事做对。

多租户架构：公寓楼的类比

把你的SaaS想象成一栋楼。每个客户都是一个租户。你有两个选择。

你可以为每个客户单独盖一栋房子。每栋房子都需要自己的地基、水管和维护。十个客户，十栋房子。一千个客户，一千栋房子——而当你想升级厨房时，就得翻新一千个厨房。

或者你盖一栋公寓楼。一个地基，一套水管，一支维护队伍。每个租户有自己的公寓、自己的锁、自己的钥匙。没人能走进邻居的家，而你只需维护一栋楼。

多租户就是那栋公寓楼。一个应用、一个数据库、一次部署——服务每一个客户，而每个客户只看到自己的数据。几乎所有你用过的SaaS产品都采用这种标准架构，也正是它让单人规模的SaaS经济模型成为可能。

服务1,000个客户的三种方式

技术上有三种做法。对独立创始人来说，只有一种说得通：

第三种是整个行业最终收敛到的方案，也是本文的主题。只需维护一个数据库。改进某处时只需执行一次变更。只有一份备份。而且你可以从1个客户扩展到10,000个客户，无需改动结构。

每张表都需要的那一列

黄金法则是：每一张存储客户数据的表，都必须有organization_id列。不是“应该有”。不是“以后可以加”。必须有，从第一天起。

你不需要会写代码也能理解。从概念上说，数据库里的每一行都会被贴上一个标签，说明它属于哪个客户。在任务管理器的任务表里，“设计首页”带着Acme的标签；“审阅Q3数字”带着TechStart的标签。应用每次读取数据时，只请求带有当前客户标签的行。每次写入数据时，都给新行盖上那个标签。Acme看到Acme的任务，TechStart看到TechStart的任务。标签就是公寓的钥匙。

这看起来很繁琐。但它也是让其他一切运转起来的基础——包括在数据库层面自动强制执行它的安全层，那值得（也确实有）单独一篇文章。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

“但我现在只有一个客户”

我经常听到这句话。跳过多租户时，会上演这样一部电影：

• 第1天：你为一个客户构建。一切正常。不需要标签——反正所有数据都属于他们。
• 第30天：你拿下第二个客户。现在两个客户能看到彼此的数据。惊慌失措。把标签补到每张表上，大约意味着三周的工作、生产环境停机和愤怒的客户。
• 另一部电影：你从第1天起就带着organization_id构建。第30天，第二个客户直接就能用。第300天，你有了100个客户，数据库零改动。

我有个朋友做SaaS时没做多租户。当他的客户到第10个时，他花了三个月重建整个数据库。三个月没有任何新功能，客户在等。别成为那样的人。

这也是我一再强调在写提示词之前先设计数据库的原因：第一天很便宜的决定——一列、一个习惯——到了第300天会变得极其昂贵。

让它又快又安全的三条规则

规则1：每张表都贴标签，没有例外。只要有一张表缺少organization_id，这张表就是一个等待发生的数据泄露。给AI下达指令时，把这条定为常驻指令，而不是单次任务的请求——这正是属于你作为架构师所做决策的那类规则，因为你不坚持的话，AI会很乐意跳过它。

规则2：给标签建索引。索引就是数据库的电话簿——它让数据库直接跳到某个客户的行，而不是读取每一行去核对标签。这个差别不是纸上谈兵：在1,000个组织、共100万行的情况下，没有索引的查询约需2,000毫秒；有索引的同一查询只需约5毫秒。让你的AI为它创建的每张表都在organization_id上加索引。

规则3：永远不要相信浏览器会说出请求者是谁。客户的身份必须来自服务器上的登录会话，绝不能来自浏览器发送的任何东西。如果恶意用户能告诉你的应用“我是组织X”，他们就能读取组织X的数据。服务器知道谁登录了；那是唯一的事实来源。

三条规则。一列。这就是演示品与可以卖给第二个、第十个、第一千个客户的产品之间的差别。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

用简单的话说，多租户是什么意思？

多个客户（租户）共用一个应用和一个数据库，但每个客户只能看到自己的数据。就像公寓楼：一栋建筑，许多私人公寓，每个租户一把钥匙。这是SaaS产品的标准架构。

如果我只有一个客户，还需要多租户吗？

需要——恰恰这时才便宜。第一天加一个organization_id列，不花你一分钱。等第二个客户到来之后再补，要花几周；我认识的一位创始人在第十个客户时花了三个月重建。从第一张表就把它做进去。

如果我不会写代码，AI能帮我设置多租户吗？

能，只要你明确给出规则：“每张存储客户数据的表都必须有organization_id列，并带索引，每个查询都必须按它过滤。”AI工具在被指示时会可靠地遵循这个模式——没被指示时则会不可预测地跳过。规则由你提供，实现由AI完成。

一个共享数据库，对客户数据来说足够安全吗？

足够，只要做得正确。organization_id标签加上数据库层面的安全（行级安全，会在每次查询时自动强制执行该标签），是几乎所有现代SaaS处理隔离的方式——同样的做法支撑着拥有数千个组织的产品。不安全的是做了一半的版本：共享数据库，没有标签，没有强制执行。