您正在构建一个从单一部署为多个客户提供服务的平台。每个客户都期望 isolated data、branded experiences 和 per-tenant billing — 但您无法为每个客户运行单独的 infrastructure。您需要共享 infrastructure 的经济性以及专用系统的 isolation guarantees。这是 SaaS architecture 的根本矛盾,早期隔离模型出错是平台开发中最昂贵的错误之一。
Explore more design patterns and system architectures
最佳选择取决于您的租户隔离要求和规模。MicrocosmWorks 通常为大多数 B2B SaaS 产品推荐共享数据库、独立 schema 的方法,因为它在成本效率和数据隔离之间取得了平衡,尽管对于医疗或金融等受监管行业的客户,如果强制要求严格的数据隔离,我们会实施每个租户一个数据库的方法。我们的架构师会在推荐正确的租户模型之前评估您的合规性需求、预期租户数量和查询模式。
MicrocosmWorks 实施租户感知的限速、带有每个租户配额的连接池以及计算层的资源隔离,以防止“吵闹邻居”问题。我们采用诸如加权公平排队和租户专属缓存层等技术,以确保一个客户的突然激增不会连锁导致其他客户的延迟。对于企业级租户,我们可以在保持共享控制平面完整的同时,提供专用计算分区。
MicrocosmWorks 提供架构设计和实施服务,咨询费率在 $15-$45/hr 之间,具体取决于所需的复杂性和团队资历。一个典型的多租户 SaaS 架构项目——涵盖数据库设计、租户隔离、身份验证和部署流水线——通常需要一个跨职能团队花费 8 到 16 周的时间。我们为每个项目都设置一个固定价格的探索阶段,这样在您承诺开始构建之前,就能对成本有全面的了解。
MicrocosmWorks 构建自动化的租户开通管道,在新用户注册后的几分钟内处理数据库 schema 创建、DNS 配置、功能标志初始化和种子数据部署。我们使用 Terraform 或 Pulumi 等基础设施即代码工具,结合事件驱动的工作流,使得每个新租户都能获得一个完全配置好的环境,无需手动干预。这种方法让我们的客户能够从 10 个租户扩展到 10,000 个,而无需改变入驻流程。
MicrocosmWorks 通过利用 feature flags、租户特定的元数据和插件架构,实现了一个配置驱动的定制层,从而允许每个租户拥有独立行为而无需代码分支。我们在 UI 主题、workflow engine 和集成层设计了扩展点,以便租户可以拥有独特的品牌形象、业务规则和第三方连接,所有这些都通过配置进行管理。这使得您的工程团队能够维护一个单一的代码库,同时支持多样化的客户需求。
Multi-tenant SaaS architecture 在租户之间提供逻辑或物理分离,同时共享底层 compute、storage 和 networking resources。该模式涵盖 tenant provisioning、data isolation、feature management、billing metering 和 white-label customization。核心设计决策是 isolation model:采用 row-level security 的 shared database、schema-per-tenant 或 database-per-tenant。每种模型都在 isolation strength、operational complexity 和 cost efficiency 之间进行权衡。
系统分为三层。tenant-aware gateway 处理 authentication、tenant resolution(通过 subdomain、JWT claim 或 API key)和 request routing。application layer 完全在 tenant context 中运行——每个 query、每个 cache key、每个 queue message 都限定于已解析的租户。data layer 通过 row-level security policies、每个租户的 connection pooling 和 encrypted-at-rest partitioning 在 storage level 强制执行 isolation。
核心组件:tenant_id 过滤每个 query 的 PostgreSQL policies。对于 schema-per-tenant:带有 connection pool management 的 dynamic connection routing。对于 database-per-tenant:使用 Terraform/Pulumi 进行 provisioning automationacme.yourapp.com) 对于 white-label products 更简洁,并允许 per-tenant TLS certificates。Path-based (yourapp.com/acme/) 更易于实现并避免 wildcard DNS complexity。MW 推荐 Subdomain resolution 用于有 white-label requirements 的 B2B SaaS,Path-based 用于 internal multi-tenant tools。
Shared Feature Flags vs. Per-Tenant Configuration。 我们使用两层 feature flag system:global flags 控制整个平台的 rollout,tenant-level overrides 允许您为特定客户 enable beta features 或为较低 tier plans 的租户 disable features。Edge Config 或 LaunchDarkly 以 sub-millisecond reads 支持这一点。
Tenant-Aware Caching。 每个 cache key 都必须 scoped to tenant_id。这听起来很明显,但跨租户的 cache key collisions 是最常见的 multi-tenant bug 之一。我们通过一个自动 prefixes tenant context 的 cache key factory 来 enforce this。| 层 | 技术 |
|---|---|
| 计算 | Node.js (NestJS), Python (FastAPI),在 ECS Fargate 或 Kubernetes 上 containerized |
| 数据 | 带 RLS 的 PostgreSQL,Redis (tenant-scoped),S3 (tenant-partitioned buckets) |
| 身份 | Clerk, Auth0, 或 Okta,带 tenant-scoped organizations |
| 计费 | Stripe Connect (marketplace model),Stripe Billing (metered subscriptions) |
| 可观测性 | 带 tenant-dimension tags 的 Datadog,以及每个 entry 带有 tenant_id 的 structured logging |
| 使用时机 | 避免时机 |
|---|---|
| 从 shared infrastructure 为 10+ 客户构建 B2B 平台时 | 每个客户需要 fully dedicated infrastructure (compliance/contractual) 时 |
| 需要 white-label branding、custom domains 和 per-tenant feature control 时 | 客户少于 3 个时——更简单的 per-customer deployment 可能就足够了 |
| Usage-based 或 tiered pricing 需要 per-tenant metering 时 | 产品是带有 user-level accounts 而非 organization-level tenants 的 consumer app 时 |
| 希望有一个 deployment pipeline、一个 monitoring stack、一个 on-call rotation 时 | 租户具有 fundamentally different schemas 或 business logic(而不仅仅是 configuration)时 |
MW 将 multi-tenancy 视为一个 cross-cutting concern,而非一个 feature。我们在 middleware level 实现 tenant context propagation,因此 application code 永远不会 manually filters by tenant —— 它由 framework 强制执行。我们的 RLS implementations 包括 automated test suites,用于在每次 CI run 运行时尝试 cross-tenant data access。我们已经构建了在 shared infrastructure 上服务 500 多个租户的 multi-tenant platforms,零 data leakage incidents,并且我们已经使用 strangler fig pattern 将 single-tenant monoliths 迁移到 multi-tenant architectures。
像应用程序代码一样进行版本控制、测试和部署的基础设施——因为您的平台的可靠性取决于其底层基础设施。