SaaS 系统中的 tenant 到底是什么，理解这个概念才能真正看懂多租户

发表时间： 2026-09-25 16:00:02 人气：81 次

SaaS系统中的tenant到底是什么理解租户边界才能真正看懂多租户架构

第一次接触SaaS架构时，tenant这个词很容易让人产生误解。有人把tenant理解成一个用户，有人把它理解成一个公司，也有人认为只要给每个客户建立一个数据库就是多租户。实际上，这几个理解都只碰到了tenant的一部分。

在SaaS系统里，tenant更准确地说是一组共享同一个应用服务、但拥有独立业务上下文、数据边界、权限边界和配置空间的客户组织或业务实体。它可能对应一家企业、一个学校、一个机构、一个团队，甚至某些产品中的一个独立工作区。一个tenant下面通常还可以拥有多个user，因此tenant和user不是同一个概念。

理解这一点以后，很多SaaS架构设计就会变得容易理解。用户登录以后，系统真正需要解决的问题并不只是“这个人是谁”，还包括“这个人属于哪个tenant”“他在这个tenant里是什么角色”“这个请求能够访问哪些tenant的数据”，以及“这个tenant使用了什么套餐、配置和业务规则”。

tenant首先是业务边界，而不是数据库

假设一家企业SaaS平台有1000家公司注册。

公司A有50名员工，公司B有300名员工，公司C只有一个管理员。三家公司都使用同一个网站、同一套后端程序和同一套API，但它们的客户数据、员工账号、订单、文件、权限和配置不能混在一起。

这时候，公司A、B、C分别可以成为tenant。

每个tenant下面可以存在很多user。一个user可能属于一个tenant，也可能根据产品设计属于多个tenant。例如，一个咨询顾问可能同时被邀请进入多个企业工作区。

因此，典型的数据关系可能是：

tenant
├── users
├── roles
├── customers
├── orders
├── projects
└── settings

这里最重要的不是数据库里有没有一个叫tenant的表，而是系统中的每一个业务请求，都能够确定自己的tenant上下文，并且后续的数据访问始终受到这个上下文约束。

为什么SaaS特别需要tenant_id

最常见的多租户实现之一，就是多个tenant共享同一个数据库和表结构，在业务表中增加tenant_id。

例如：

orders
--------------------------------
id
tenant_id
customer_id
amount
status
created_at

假设订单1001属于tenant 15，订单1002属于tenant 28。

应用查询tenant 15的订单时，不能只写：

SELECT * FROM orders;

而应该让查询始终带有正确的租户条件，例如：

SELECT *
FROM orders
WHERE tenant_id = :tenant_id;

这个看起来非常简单，但它实际上是多租户系统最危险的地方之一。

如果某个API忘记加入tenant_id条件，一个客户就有可能查询到另一个客户的数据。

因此，多租户安全不能依赖程序员“记得每次都写tenant_id”。成熟系统会尽量把租户上下文、数据访问层、ORM作用域、数据库策略以及授权机制结合起来，让跨租户访问尽可能在架构层面变得困难。

tenant和user为什么不能混为一谈

一个典型的SaaS系统可能存在这样的结构：

Tenant A
Alice
Bob
Charlie

Tenant B
David
Emma

Tenant C
Frank

Alice、Bob和Charlie是用户，而Tenant A是他们共同工作的业务边界。

如果系统只设计user_id，而没有tenant概念，那么后面很多问题都会变得复杂。例如，同一个客户的管理员如何管理员工？同一个用户如何切换多个企业？不同企业能否拥有相同的用户名？一个用户在不同企业中是否可以拥有不同角色？

加入tenant之后，这些关系就清晰很多。

权限也通常需要同时考虑tenant和role。例如，一个人在Tenant A中可能是管理员，但进入Tenant B后可能只是普通成员。

所以真正的授权判断往往不是简单的“这个用户有没有权限”，而是“这个用户在当前tenant上下文中有没有执行这个操作的权限”。

多租户并不意味着每个客户一个数据库

这是理解SaaS架构时最常见的误区。

多租户系统大致可以采用几种不同的隔离模式。

第一种是共享数据库、共享表，通过tenant_id区分数据。这种模式通常具有较高的资源利用率，也比较容易统一部署和维护，但应用和数据库层面的租户隔离必须设计得非常严谨。

第二种是共享数据库、不同schema。不同tenant的数据拥有相对独立的schema边界，在隔离性和运营复杂度之间取得不同的平衡。

第三种是每个tenant独立数据库。这种方式能够提供更强的数据隔离，并且在某些企业客户、监管要求或者需要独立备份恢复的场景中非常有价值，但随着客户数量增长，数据库数量、升级、监控、备份和连接管理都会变得更加复杂。

因此，不能简单地说“真正的多租户必须一个客户一个数据库”。恰恰相反，大规模SaaS经常需要根据客户规模、合规要求、性能以及成本采用混合模式。

例如普通客户使用共享数据库，而大型企业客户使用独立数据库。这也是现实SaaS架构中非常常见的设计。

tenant隔离也不是简单的Docker隔离

原始理解中经常把tenant隔离直接和Docker、KVM、VLAN联系起来。

这些技术当然可以参与基础设施隔离，但它们并不是tenant概念的必要组成部分。

一套SaaS服务完全可以让1000个tenant运行在同一组应用服务器、同一套容器集群甚至相同的应用进程中。

系统依靠请求中的认证信息确定用户身份，再解析出tenant上下文，随后在应用、数据库、缓存、对象存储和权限系统中贯彻这个上下文。

这意味着，多租户的核心问题其实是“边界管理”。

数据库必须知道数据属于哪个tenant，缓存必须知道缓存键属于哪个tenant，对象存储必须知道文件属于哪个tenant，消息队列中的任务也应该携带正确的tenant上下文。

否则数据库虽然隔离了，缓存却可能把Tenant A的数据返回给Tenant B；数据库没有问题，对象存储权限却可能让其他客户下载文件。

缓存是多租户系统里非常容易出事故的地方

例如系统使用Redis缓存用户信息。

错误设计可能是：

user:10001

如果用户ID在整个系统中是全局唯一，这种设计可能没有问题。

但如果某些业务对象的ID只在tenant内部唯一，就必须考虑租户上下文。例如：

tenant:15:customer:1001
tenant:28:customer:1001

这两个customer_id虽然都是1001，但属于完全不同的tenant。

如果缓存键没有包含正确的租户边界，就可能出现严重的数据串租户问题。

类似问题还会出现在搜索索引、对象存储路径、临时文件、队列任务和后台Job中。

因此，多租户安全不能只检查SQL。

tenant上下文应该从哪里来

成熟SaaS系统通常会在用户完成认证之后建立租户上下文。

例如用户登录后，身份系统知道用户是谁以及他属于哪些tenant。用户访问某个企业工作区时，系统确定当前tenant_id，然后将这个上下文传递给后续业务逻辑。

一个请求可能包含：

user_id
tenant_id
role
permissions

但这里有一个非常重要的安全原则：tenant_id不能简单相信浏览器提交过来的值。

如果客户端直接发送：

tenant_id=28

服务器不能因为这个数字存在，就允许当前用户访问tenant 28。

服务器必须根据经过验证的身份、membership以及授权关系确认这个用户是否确实属于tenant 28。

否则，一个普通用户只需要把请求中的tenant_id从15改成16，就可能尝试访问另一个客户的数据。

这就是典型的跨租户授权漏洞。

业务规则也可能属于tenant

tenant不仅决定“看哪些数据”，还可能决定“这些数据应该怎样处理”。

例如一个企业SaaS产品允许不同客户设置自己的审批流程。

Tenant A规定采购订单超过5000美元必须经过经理审批。

Tenant B规定超过10000美元才需要审批。

那么业务逻辑就不能把5000美元写死在代码里，而应该根据当前tenant加载对应配置。

类似情况还包括税率、时区、货币、品牌Logo、邮件模板、用户权限、数据保留期限、功能开关以及套餐限制。

因此，tenant通常拥有自己的configuration。

这也是SaaS产品与普通网站最大的架构区别之一：同一套软件正在服务很多客户，但每个客户又拥有自己的业务环境。

套餐限制也是tenant的一部分

例如SaaS平台提供Basic、Professional和Enterprise三个套餐。

不同tenant可能拥有不同的用户数量限制、存储空间、API调用额度或者高级功能。

这时候系统判断的也不是简单的“这个user能不能使用某个功能”，而是当前tenant是否购买了相应能力。

因此，一个请求通常需要同时经过身份认证、tenant授权和产品能力检查。

例如：

用户身份
当前tenant
用户角色
tenant套餐
具体资源权限

这些条件共同决定最终是否允许操作。

这也是为什么成熟SaaS系统往往不会把权限简单写成数据库中的一个is_admin字段。随着产品复杂度增加，角色、权限、套餐、资源归属和tenant边界都会进入授权模型。

多租户真正困难的地方在于“所有地方都必须记住租户”

数据库查询需要tenant上下文。

Redis缓存需要tenant上下文。

文件存储需要tenant上下文。

搜索索引需要tenant上下文。

后台任务需要tenant上下文。

审计日志需要tenant上下文。

报表系统需要tenant上下文。

数据导出也需要tenant上下文。

甚至客服人员进入客户后台进行故障排查时，也需要明确记录当前正在访问哪个tenant。

因此，多租户并不是给数据库增加一个tenant_id字段就结束了。

它是一种贯穿整个系统生命周期的架构约束。

大型SaaS为什么经常采用混合隔离

随着客户数量增长，所有tenant都使用完全相同的数据库模式未必是最佳方案。

小型客户的数据量很小，可以共享数据库和表。

大型客户可能要求独立数据库。

某些监管严格的客户可能要求数据存储在特定区域。

还有一些客户可能要求独立加密密钥、独立备份策略或者更严格的访问审计。

因此，现代SaaS往往不会追求一种“所有客户都一样”的隔离方案，而是根据客户等级、数据敏感程度、性能需求和合规要求进行分层。

这也解释了为什么tenant概念比“数据库”更重要。

数据库只是承载数据的一种技术手段，而tenant才是业务上的边界。

多租户最危险的故障不是系统宕机，而是数据串租户

服务器宕机，用户通常知道系统出了问题。

但是如果一个API因为忘记tenant过滤条件，把A公司的客户名单返回给B公司，问题就严重得多，而且有时候很难立即被发现。

因此，多租户系统必须把跨租户访问作为重点安全测试对象。

测试人员应该主动测试修改tenant ID、修改资源ID、重复提交请求、直接调用内部API、访问其他租户的对象存储路径以及利用缓存键猜测其他客户数据等情况。

数据库层面的约束、应用层授权、API权限检查、缓存键设计、对象存储策略以及审计日志，都应该形成多层防护。

tenant这个概念真正值得工程师掌握的地方，不是记住一个英文单词，而是理解SaaS为什么必须建立“客户边界”。

一个user代表一个身份，一个role代表一组权限，而tenant代表一个独立的业务和数据上下文。多租户系统的核心工作，就是让同一套软件可以服务大量客户，同时保证每个客户看到的只是属于自己的数据、配置、资源和业务状态。

当你开始从tenant_id一路追踪到数据库查询、Redis key、文件路径、消息队列、后台Job、API授权和审计日志时，才算真正开始理解多租户架构。因为多租户从来不只是“数据库里多了一列tenant_id”，而是整个SaaS系统都必须始终知道：这个请求究竟属于谁。

分享 Facebook | X | Whatsapp | Linkedin

捐助（Paypal）: https://www.paypal.me/observeccp
订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP

责任编辑：雨轩来源：中国观察转载请注明作者、出处並保持完整。

今日热点:

更多新闻...

近期焦点:

推荐文章

FTC盯上YouTube封号机制平台可以管理内容却不能把规则变成一张任意伸缩的网

YouTube封禁一个账号，表面看只是平台与用户之间的一次纠纷；但当美国联邦贸易委员会开始调查这种封禁是否违反消费者保护法，事情的性质就发生了变化。美国政府...

2026年8月28日　 26175

阅读全文 →

印度首都为何突然封城式维稳选民名册争议正在考验莫迪政府的民主底线

新德里街头，警察和准军事部队提前封锁了集会地点，地铁站关闭，部分商业区的移动互联网服务中断，抗议者还没有走到指定广场，拘留行动就已经开始。2026年10...

2026年10月11日　 154635

阅读全文 →

川普总统向加拿大划出选举红线加美贸易战为何升级为政治冲突

发表：2026-10-23 12:45:55 | 更新：2026-10-23 12:45:55 人气: 3718

【中国观察北京时间2026年10月23日讯】美国与加拿大之间的冲突正在从关税、贸易谈判和国家主权争议，进一步延伸到美国选举政治。美国驻加拿大使馆近日公开列举加拿大政界人士的言论与行动，指责他们试图影响11月3日举行的美国国会中期选举。加拿大总理卡尼随即否认指控，称美方说法毫无根据。争议的核心，是川普总统政府是否准备把加拿大针对美国贸易政策的政治动员，视为触及美国民主制度底线的行为。

川普总统对加拿大的态度，一直带有鲜明的交易思维和强硬色彩。他反复强调美国在贸易谈判中拥有优势，10月23日又表示，加拿大正积极寻求与美国达成协议，美国掌握着“所有牌”。在川普看来，美国庞大的消费市场和经济实力是谈判筹码，加拿大不能一面依赖美国市场，一面通过关税反制、政治广告和公开施压，试图迫使华盛顿改变政策。对于习惯于依靠美国市场的加拿大来说，这种态度意味着，过去建立在盟友关系和长期贸易规则之上的政策空间，正在受到更直接的压力。

此次争议并非突然出现。2025年，安大略省政府投放了一则批评美国关税政策的广告，其中使用了美国前总统罗纳德·里根反对关税的讲话片段。广告在美国职业棒球世界大赛期间播出后，川普总统宣布中止与加拿大的贸易谈判。如今，美国使馆再次把这则广告列为加拿大试图影响美国政治的例证。美国政府还关注加拿大工业部长梅拉妮·乔利关于对美国特定州和企业施加经济压力的表态，以及她与美国民主党政治人物的接触。

美方的逻辑并不难理解。美国国会中期选举将决定共和党能否继续控制国会，关税政策也已成为美国国内政治的重要议题。如果加拿大政府有意识地挑选共和党执政州作为经济施压目标，并通过广告、政治接触或其他行动影响当地选民，那么这种做法就不只是普通的贸易谈判策略，还可能具有明确的选举政治目的。外国政府不应当因为自己与某个美国政党存在政策分歧，就把美国选民当作向华盛顿施压的工具。

不过，政治目的与违法行为之间仍然存在法律上的区别。美国驻加拿大使馆10月21日公布的材料，主要援引公开讲话、政府文件、政治广告和媒体报道。它还提到11名曾因涉嫌或涉及非法参与美国选举而受到起诉或判刑的加拿大人，但没有提供证据证明这些个人案件是加拿大政府组织或指使的行动。美方目前公开展示的材料，可以用来质疑加拿大政界人士是否试图影响美国政治，却不足以单独证明加拿大政府已经组织实施非法选举干预。

这一点不能因为支持川普总统的政治立场而被忽略。美国有充分理由保护本国选举不受外国政府操纵，但指控必须有相应证据支撑。加拿大官员公开批评川普的关税政策、游说美国政治人物，或者通过媒体表达对美国经济政策的看法，并不自动构成违法行为。若美国政府掌握外国政府秘密资助美国候选人、协调违法竞选支出、操纵投票程序或实施其他违反美国选举法的证据，就应当明确指出具体行为、法律依据和责任主体，而不是把所有不受欢迎的外国政治言论都归入非法干预。

加拿大总理卡尼10月23日回应称，美方的指控没有根据，并对美国驻加拿大大使彼得·霍克斯特拉提出这些指控表示失望。卡尼政府强调，加拿大官员与美国政治人物的接触旨在吸引投资、维护加拿大经济利益。加拿大方面也有理由指出，反制关税和维护本国企业，是贸易争端中的正常政策工具。然而，正常的政策反制并不意味着所有政治操作都天然合理。如果加拿大政界人士公开承认，某些措施的设计目的就是给共和党关键州制造政治压力，那么华盛顿要求他们解释政策目标与选举时间之间的关系，也不能简单视为川普总统的政治报复。

更值得注意的是，加拿大政府过去也曾反对外国干预本国选举。卡尼在谈及阿尔伯塔省公投等议题时，强调包括美国在内的外国政府不应介入加拿大选举。既然渥太华要求华盛顿尊重加拿大的民主程序，就应当接受同样原则的约束：加拿大政府可以批评美国政策，也可以通过外交渠道维护自身利益，但不应以秘密资金、违法竞选支持或其他非法方式左右美国选举。如果美方指控最终被证明只是把公开外交活动夸大为选举干预，加拿大也有权要求美国纠正；如果存在更严重的行为，则应当依据证据调查，而不是靠外交口水战解决。

这场争端还暴露出加美关系的根本变化。长期以来，两国共享北美供应链、安全合作和跨境贸易利益，双方即使发生分歧，通常也会努力把经济争端限制在谈判桌上。川普总统采取更强硬的关税政策后，加拿大开始寻求市场多元化，并尝试利用美国国内的政治和经济压力争取让步。华盛顿则越来越警惕，认为盟友可能利用美国内部的党派分歧来影响美国政策。双方都在把经济实力转化为政治筹码，结果是贸易争端逐渐演变为对彼此政治意图的猜疑。

川普总统政府现在面对的考验，是能否把强硬立场转化为经得起法律检验的行动。美国当然有权要求外国政府尊重美国选举，但最有力的回应不是把每一次外交批评都认定为干预，而是拿出具体证据，依法追究真正违法的行为。加拿大同样不能一方面强调国家主权，另一方面又把对美国国内政治施加压力视为没有边界的外交策略。民主制度的底线应当适用于所有国家，不因对方是盟友、贸易伙伴或政治对手而改变。川普总统要守住的红线，最终应当落在可证明的违法行为上，而不是停留在相互指责之中。

本文由中国观察編輯部原创。为了促进信息自由传播，本平台原创内容全面开放转载，无须申请授权，只需注明来源、保留原文链接，即可全文转载、引用、翻译。我们不追究版权，只在乎公正的传播。

捐助（Paypal）: https://www.paypal.me/observeccp
订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP

最近文章: