您正在构建一个从单一部署为多个客户提供服务的平台。每个客户都期望 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 之间,具体取决于所需的复杂性和团队资历。一个典型的多租户 SaaS 架构项目——涵盖数据库设计、租户隔离、身份验证和部署管道——由一个跨职能团队在 8-16 周内完成。我们为每个项目都设定了固定价格的探索阶段,因此在承诺构建之前,您将对成本有充分的可见性。
MicrocosmWorks 构建自动化租户配置管道,在新用户注册后几分钟内处理 schema 创建、DNS 配置、功能标志初始化和种子数据部署。我们使用 Terraform 或 Pulumi 等基础设施即代码工具结合事件驱动的工作流,确保每个新租户都能获得一个完全配置的环境,无需手动干预。这种方法让我们的客户无需更改入驻流程即可从 10 个租户扩展到 10,000 个。
MicrocosmWorks 实施了一个配置驱动的定制层,利用功能标志、租户专属元数据和插件架构,实现在不进行代码分支的情况下提供每个租户的行为。我们在 UI 主题、工作流引擎和集成层设计了扩展点,以便租户可以通过配置管理独特的品牌、业务规则和第三方连接。这使得您的工程团队能够维护单一代码库,同时支持多样化的客户需求。
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。
像应用程序代码一样进行版本控制、测试和部署的基础设施——因为您的平台的可靠性取决于其底层基础设施。