多租户 SaaS 架构图：筒仓、池与桥接模型

如果像大多数团队画任何系统那样去画一个多租户 SaaS 产品，它看起来会和单租户系统一模一样：一个网关、几个服务、一个数据库。系统最重要的属性，也就是哪个客户的数据可能落到哪里，在图上根本看不到。可恰恰是这个属性决定了最难的那些决策：租户如何隔离、大客户如何服务、租户入驻（onboarding）如何运作，以及一个嘈杂邻居（noisy neighbor）可能破坏什么。

本文介绍如何在架构图上把多租户特性画出来：相关术语、图上必须表达的内容、筒仓（silo）、池（pool）与桥接（bridge）模型，以及一个同时包含共享资源和专用资源的示例。

术语

下面这些术语在 SaaS 架构相关的文章中很常见，AWS 的 SaaS 指南中也在使用：

• 租户（tenant）。 一个客户组织，拥有自己的用户和数据。
• 控制平面（control plane）。 负责管理租户、而不是直接提供产品功能的服务：租户入驻、租户注册表（tenant registry）、身份、计量和计费。
• 应用平面（application plane）。 产品本身：租户每天使用的服务和数据存储。
• 租户上下文（tenant context）。 随每个请求一起传递的租户 ID，通常作为访问令牌中的一个声明（claim）。
• 筒仓。 专属于单个租户的资源，例如一个独立的数据库或一整套技术栈。
• 池。 由多个租户共享的资源，通过策略和租户 ID 相互隔开。
• 桥接。 两者的混合：例如计算资源共享，同时为部分租户提供专用数据库。

图上必须表达的内容

1. 租户上下文从哪里来。 身份提供商，以及携带租户 ID 的令牌声明。
2. 隔离在哪里强制执行。 不是“在代码里”，而是在一个具体的位置：行级安全（row-level security）策略、每个租户一个 schema、独立的数据库、IAM 策略。
3. 哪些资源共享，哪些资源专用。 把每个数据存储和服务都标注为池化或筒仓。
4. 请求如何找到它的资源。 把租户路由到正确数据库或技术栈的路由或查找逻辑。
5. 租户如何创建。 写入注册表、并预置所需专用资源的入驻流程。

筒仓、池与桥接

模型	共享什么	优势	代价
筒仓	应用平面中什么都不共享	隔离强，可按租户调优，合规问题更容易回答	每个租户的成本更高，需要运维的部署更多
池	计算和数据，按租户 ID 隔开	每个租户的成本低，只有一套部署	隔离依赖每一条查询和每一条策略；嘈杂邻居
桥接	部分层共享，部分层专用	把隔离投入用在关键之处	要构建、测试和绘制两条路径

很多产品一开始采用池模型，之后再把最大或监管最严格的客户迁到筒仓中，系统也就变成了桥接模型。架构图应该把这种划分表达得一目了然。

示例：池化租户加一个企业筒仓

一个 B2B 分析产品有数百个标准租户，还有一个要求使用独立数据库的企业客户 Globex：

• 用户通过一个支持多租户的身份提供商登录。他们的访问令牌中带有 tenant_id。
• API 网关验证令牌，并把租户上下文传给分析 API。
• 分析 API 在租户注册表中查找租户的等级（tier）和数据库。
• 标准租户共享一个池化 PostgreSQL 数据库，行级安全会按 tenant_id 过滤每一条查询。
• Globex 拥有一个专用数据库，它在创建该租户时由入驻服务预置。

两个框把控制平面和应用平面分开，数据存储上的标签说明了适用哪种隔离模型。现在，评审者就能提出正确的问题：注册表宕机了会怎样？谁可以修改租户的等级？

多租户架构图的规则

画等级，而不是画租户

永远不要为每个客户画一个方框。为每个等级或部署模型画一条路径；如果有帮助，可以像上面的 Globex 那样标出一个示例租户。

在连线上标注租户上下文

写清楚每一跳上租户是如何识别的：JWT tenant_id、header X-Tenant-Id set by the gateway、tenant_id in the message。后台任务和事件消费者同样需要租户上下文，而它们恰恰是租户上下文最容易丢失的地方。

把强制隔离的位置画到图上

“按租户 ID 隔离”只是一个承诺；行级安全策略、每个租户一个 schema 或独立的账户才是机制。把机制标注在数据存储上，或者在旁边添加一个策略节点。

标出每个租户的限制

按租户设置的速率限制、配额和并发限制，是池化系统让租户之间互不干扰的手段。在网关上以及执行这些限制的服务上注明它们。

把计量和计费放在控制平面

每个租户的用量事件会流入计量和计费。把它们画在控制平面中，让应用平面专注于处理请求。

常见错误

• 没有控制平面。 租户入驻、租户注册表和身份是核心架构，而不是管理工具。
• 靠约定实现隔离。 一张写着“每个查询都按租户过滤”的便签算不上控制措施。要画出强制执行它的策略。
• 看不见的路由。 如果部分租户使用不同的资源，就把做出这个决定的查找画出来。
• 被遗忘的异步路径。 丢失租户 ID 的队列、定时任务和分析导出，是典型的数据泄露来源。
• 一张巨大的图。 把数据驻留（区域）、部署和逻辑视图分别画在不同的图上。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 从基础节点包中添加两个框架节点：Control plane 和 Application plane。
3. 从基础节点包中添加两个方框节点，分别表示标准用户和 Globex 用户；再添加安全节点包中的身份提供商、云节点包中的 API 网关，以及 C4 模型节点包中的容器节点，分别表示入驻服务和分析 API。
4. 从数据节点包中添加 Postgres 节点，分别表示租户注册表、池化数据库和专用数据库，并在标签中写明隔离模型。
5. 在连线上标注租户上下文，并把预置连线设为虚线。

这个示例使用 11 个图表节点，Free 套餐即可满足。关于下层的云和网络层，请参阅 AWS VPC 架构图 和 云架构使用场景页面。

常见问题

应该选择哪种隔离模型？ 从客户的需求和每个租户的成本出发。池模型运行成本最低，筒仓模型最容易向安全评审者解释，桥接模型则让你两者都能提供。把选择的理由写在图上。

如何表示数百个租户？ 不用表示。每个等级或部署模型只画一次，租户列表就留在它该在的注册表里。

每个租户都需要一张自己的图吗？ 不需要。每个架构一张图，在图上画出各个等级。如果某个筒仓式的企业租户运行在独立的账户或区域中，可以为它单独画一张部署图。

如何表示数据驻留？ 在单独的部署图上用区域框表示，每个框中放入必须留在该区域的租户的技术栈或数据库。

每个租户的加密密钥放在哪里？ 放在它们所保护的数据存储旁边，用安全节点包中的节点或便签表示，并画出保管这些密钥的密钥管理服务。

免费开始 — 1 个席位，无需信用卡。