Arch Day 101: 多租户架构 — SaaS的基石

日期: 2026-07-09 (Day 101) 阶段: 第四阶段 - 高阶融合 标签: #多租户 #SaaS #数据隔离 #NoisyNeighbor #租户定制化 #计费

---

核心概念

多租户是SaaS的基石——但设计错了就是噩梦

多租户架构（Multi-Tenant Architecture）是SaaS产品的核心架构决策之一。简单来说，就是用一套系统服务多个客户（租户），每个租户感觉自己在使用独立的系统。

为什么多租户如此重要？

单租户 vs 多租户的经济对比:
├── 单租户: 每个客户独立部署
│   ├── 运维成本: O(N) — N个客户需要维护N套系统
│   ├── 更新成本: 逐个升级，版本碎片化
│   └── 资源利用率: 低（每套系统都有闲置资源）
│
└── 多租户: 所有客户共享一套系统
    ├── 运维成本: O(1) — 维护一套系统
    ├── 更新成本: 一次更新，所有租户同时生效
    └── 资源利用率: 高（动态共享，削峰填谷）

但多租户的挑战也很大：

---

知识点详解

一、多租户隔离模型

AWS SaaS Lens定义了三种核心隔离模型：Silo（筒仓）、Pool（池化）和Bridge（桥接）。

1. Silo模型（完全隔离）

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Tenant A    │  │  Tenant B    │  │  Tenant C    │
│ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │
│ │  App    │ │  │ │  App    │ │  │ │  App    │ │
│ │ Server  │ │  │ │ Server  │ │  │ │ Server  │ │
│ └─────────┘ │  │ └─────────┘ │  │ └─────────┘ │
│ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │
│ │Database │ │  │ │Database │ │  │ │Database │ │
│ └─────────┘ │  │ └─────────┘ │  │ └─────────┘ │
│ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │
│ │  Cache  │ │  │ │  Cache  │ │  │ │  Cache  │ │
│ └─────────┘ │  │ └─────────┘ │  │ └─────────┘ │
└─────────────┘  └─────────────┘  └─────────────┘

适用场景：大型企业客户、金融/医疗等强合规行业、对延迟极敏感的客户

2. Pool模型（完全共享）

┌──────────────────────────────────────┐
│           共享基础设施                  │
│ ┌──────────────────────────────────┐ │
│ │        共享应用服务器               │ │
│ │  ┌──────┐ ┌──────┐ ┌──────┐    │ │
│ │  │Pod 1 │ │Pod 2 │ │Pod 3 │    │ │
│ │  └──────┘ └──────┘ └──────┘    │ │
│ └──────────────────────────────────┘ │
│ ┌──────────────────────────────────┐ │
│ │        共享数据库                   │ │
│ │  tenant_id = A | B | C | ...    │ │
│ └──────────────────────────────────┘ │
│ ┌──────────────────────────────────┐ │
│ │        共享缓存                    │ │
│ │  prefix: tenantA:* | tenantB:*  │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────┘

适用场景：中小型客户、对成本敏感的SaaS、低风险场景

3. Bridge模型（混合模式）

┌──────────────────────────────────────────────┐
│                  混合架构                       │
│                                              │
│  ┌────────────────────────────┐              │
│  │     共享应用层              │              │
│  │  (所有租户共享计算资源)      │              │
│  └──────────────┬─────────────┘              │
│                 │                             │
│        ┌────────┼────────┐                   │
│        ▼        ▼        ▼                   │
│  ┌──────────┐ ┌──────────────────────┐       │
│  │ Premium  │ │   Standard Tenants   │       │
│  │ Tenant   │ │ ┌──────────────────┐ │       │
│  │ (独立DB) │ │ │   共享数据库      │ │       │
│  └──────────┘ │ │ tenant_id filter  │ │       │
│               │ └──────────────────┘ │       │
│               └──────────────────────┘       │
└──────────────────────────────────────────────┘

Bridge模型的关键思想：不同租户层级（Tier）使用不同的隔离策略：

这是AWS推荐的最佳实践——根据租户的付费等级和需求，为不同租户提供不同级别的隔离。

二、数据隔离策略

数据隔离是多租户架构中最关键的设计决策：

策略1：独立数据库（Database per Tenant）

Tenant A → Database_A (PostgreSQL实例1)
Tenant B → Database_B (PostgreSQL实例2)
Tenant C → Database_C (PostgreSQL实例3)

-- 连接路由（应用层）
function getConnection(tenantId) {
  return connectionPool.get(
    tenantConfig[tenantId].databaseUrl
  );
}

策略2：共享数据库，独立Schema（Schema per Tenant）

共享PostgreSQL实例
├── schema_tenant_a
│   ├── users
│   ├── orders
│   └── payments
├── schema_tenant_b
│   ├── users
│   ├── orders
│   └── payments
└── schema_tenant_c
    ├── users
    ├── orders
    └── payments

-- Schema切换
SET search_path TO schema_tenant_a;
SELECT * FROM users WHERE id = 123;

策略3：共享表（Shared Table with tenant_id）

-- 所有租户共享同一张表，通过tenant_id区分
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  tenant_id VARCHAR(50) NOT NULL,  -- 租户标识
  user_id BIGINT NOT NULL,
  amount DECIMAL(18,2),
  status VARCHAR(20),
  created_at TIMESTAMP,

  -- 租户ID参与索引
  INDEX idx_tenant_user (tenant_id, user_id),
  INDEX idx_tenant_status (tenant_id, status)
);

-- 查询时必须带tenant_id
SELECT * FROM orders
WHERE tenant_id = 'TENANT_A'
  AND status = 'PENDING';

关键安全措施：

-- PostgreSQL Row Level Security (RLS)
-- 数据库层面强制租户隔离，即使应用层遗漏也不会泄露
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.current_tenant'));

-- 应用层设置当前租户
SET app.current_tenant = 'TENANT_A';
SELECT * FROM orders;  -- 自动只返回TENANT_A的数据

数据隔离决策矩阵

是否有强制数据物理隔离的合规要求？
├── 是 → 独立数据库
└── 否 → 租户数量多吗？
    ├── 少（<100）→ 独立Schema
    └── 多（>100）→ 共享表 + RLS
        └── 但有高级租户需要物理隔离？
            └── 是 → Bridge模型（高级独立DB + 普通共享表）

三、租户级定制化

不同租户往往需要不同的业务逻辑、UI和工作流。如何在共享架构上支持定制化？

1. 配置化（Configuration-driven）

{
  "tenant_id": "TENANT_A",
  "config": {
    "branding": {
      "logo_url": "/assets/tenant-a/logo.png",
      "primary_color": "#FF6B00",
      "app_name": "TenantA Finance"
    },
    "features": {
      "enable_crypto_payment": true,
      "enable_installment": false,
      "max_transaction_amount": 100000,
      "require_2fa": true
    },
    "workflow": {
      "approval_levels": 2,
      "auto_approve_below": 1000,
      "notification_channels": ["email", "sms"]
    },
    "integrations": {
      "crm": "salesforce",
      "accounting": "quickbooks"
    }
  }
}

适用范围：UI定制、功能开关、参数调整（80%的定制化需求）

2. 插件化（Plugin-based）

┌──────────────────────────────────┐
│          核心平台（不可变）         │
│  ┌──────────┐   ┌────────────┐  │
│  │ 订单管理  │   │  用户管理   │  │
│  └──────────┘   └────────────┘  │
│                                  │
│  ┌──────────────────────────────┐│
│  │       插件接口（Extension    ││
│  │       Points）               ││
│  │  ├── beforeOrderCreate()    ││
│  │  ├── afterPaymentComplete() ││
│  │  ├── customValidation()     ││
│  │  └── reportGenerator()      ││
│  └──────────────────────────────┘│
└──────────────────────────────────┘
        │           │           │
   ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
   │Plugin A │ │Plugin B │ │Plugin C │
   │(Tenant1)│ │(Tenant2)│ │(Tenant3)│
   │自定义   │ │自定义    │ │默认     │
   │风控规则 │ │审批流程  │ │(无插件) │
   └─────────┘ └─────────┘ └─────────┘

适用范围：业务逻辑定制、自定义流程（15%的定制化需求）

3. 模板化（Template-based）

预定义行业模板:
├── 零售行业模板 → 商品管理+订单+库存+门店
├── 金融行业模板 → 客户管理+风控+合规+报表
├── 医疗行业模板 → 患者管理+预约+病历+处方
└── 教育行业模板 → 学员管理+课程+考试+证书

租户选择模板 → 基于模板定制配置 → 必要时添加插件

四、租户计费与配额

计费模型对比

计费系统架构

┌──────────────────────────────────────┐
│           计量系统 (Metering)          │
│  ┌─────────┐  ┌─────────┐  ┌──────┐ │
│  │API调用   │  │存储使用  │  │用户数│ │
│  │计数器    │  │计量器    │  │计数器│ │
│  └─────────┘  └─────────┘  └──────┘ │
└──────────────────┬───────────────────┘
                   │ 事件流
                   ▼
┌──────────────────────────────────────┐
│          聚合引擎 (Aggregation)       │
│  按租户+按维度+按时间窗口聚合          │
└──────────────────┬───────────────────┘
                   │
                   ▼
┌──────────────────────────────────────┐
│          计费引擎 (Billing)           │
│  ├── 定价规则（阶梯/线性/自定义）      │
│  ├── 折扣计算（促销/批量/合同）        │
│  ├── 账单生成                        │
│  └── 发票/收款                       │
└──────────────────────────────────────┘

配额管理

tenant_quotas:
  basic:
    api_calls_per_month: 10000
    storage_gb: 5
    users: 5
    support: "community"

  professional:
    api_calls_per_month: 100000
    storage_gb: 50
    users: 50
    support: "email (24h response)"

  enterprise:
    api_calls_per_month: unlimited
    storage_gb: 500
    users: unlimited
    support: "dedicated (1h response)"

quota_enforcement:
  soft_limit: "80% → 发送警告通知"
  hard_limit: "100% → 拒绝请求 + HTTP 429"
  grace_period: "超限后24小时宽限期"

五、Noisy Neighbor问题

什么是Noisy Neighbor？

"吵闹的邻居"是多租户架构中最头疼的问题之一——一个租户的异常负载影响了其他租户的体验。

场景:
Tenant A: 正常负载 100 QPS
Tenant B: 突发负载 10,000 QPS（导入大量数据）
Tenant C: 正常负载 200 QPS

共享数据库连接池: 最大1000连接
→ Tenant B占用了800连接
→ Tenant A和C只剩200连接，响应变慢
→ Tenant A和C的用户体验严重下降

解决方案层次

1. 资源配额（Resource Quotas）

# Kubernetes ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

2. 限流（Rate Limiting）

租户级限流:
├── API调用: 每租户独立的QPS限制
├── 数据库: 每租户独立的连接池（或连接数上限）
├── 消息队列: 每租户独立的Topic/分区
└── 存储: 每租户的IOPS限制

实现:
tenant_rate_limits = {
  "tenant_a": { "qps": 500, "burst": 750 },
  "tenant_b": { "qps": 200, "burst": 300 },
  "tenant_c": { "qps": 1000, "burst": 1500 }
}

3. 队列隔离（Queue Isolation）

方案1: 租户级队列
├── queue_tenant_a → Consumer_A
├── queue_tenant_b → Consumer_B
└── queue_tenant_c → Consumer_C

方案2: 优先级队列
├── high_priority_queue → Premium租户消息
├── medium_priority_queue → Standard租户消息
└── low_priority_queue → Basic租户消息

4. 计算隔离（Compute Isolation）

方案1: Namespace隔离（Kubernetes）
├── namespace: tenant-premium-a → 独立节点池
├── namespace: tenant-standard → 共享节点池
└── namespace: tenant-basic → 共享节点池（限制资源）

方案2: Serverless隔离（AWS Lambda）
├── 每租户独立的Lambda函数（并发限制独立）
└── 或每租户独立的provisioned concurrency配额

5. 监控与告警

核心监控指标:
├── per_tenant_latency_p99: 每租户的P99延迟
├── per_tenant_error_rate: 每租户的错误率
├── per_tenant_cpu_usage: 每租户的CPU使用
├── per_tenant_db_connections: 每租户的DB连接数
└── per_tenant_queue_depth: 每租户的队列深度

告警规则:
IF any_tenant_latency_p99 > 2 * global_baseline
THEN alert("Potential Noisy Neighbor detected")

六、合规租户隔离

金融和医疗行业对多租户隔离有特殊的合规要求：

金融行业合规要求

数据隔离要求:
├── PCI-DSS: 持卡人数据必须隔离，加密存储
├── SOC2: 需要证明租户间数据不可互访
├── GDPR/PIPL: 个人数据跨境传输需审批
├── 金融监管: 不同地区的数据需要在该地区存储

实现策略:
├── 加密隔离: 每租户独立的加密密钥（Key per Tenant）
│   └── AWS KMS / Azure Key Vault 每租户独立Key
├── 网络隔离: 高级租户独立VPC + PrivateLink
├── 访问控制: 零信任 + 最小权限
│   └── 运维人员也需要按租户授权
└── 审计: 所有跨租户数据访问必须记录和审计

数据驻留（Data Residency）

场景: 中国客户的数据必须存储在中国大陆

架构策略:
├── 地域部署: 每个合规区域独立部署
│   ├── cn-region: 中国大陆客户
│   ├── eu-region: 欧盟客户（GDPR）
│   └── us-region: 美国客户
│
├── 路由层: 根据租户的合规区域路由请求
│   └── tenant_config.data_residency_region → 路由到对应区域
│
└── 同步策略: 非敏感数据（产品目录等）可跨区域同步
    └── 敏感数据严禁跨区域传输

---

对比分析

三种隔离模型综合对比

AWS SaaS参考架构的推荐

AWS Well-Architected SaaS Lens的核心建议：对每个资源单独评估其noisy neighbor和安全风险，然后选择合适的隔离级别。不要对所有组件使用统一的隔离策略。

组件级隔离决策:
├── 计算层: Pool（无状态，易扩展）
├── 数据库: 取决于合规要求
│   ├── 金融数据 → Silo
│   └── 非敏感数据 → Pool + RLS
├── 缓存: Pool + Key前缀隔离
├── 消息队列: Pool + 租户级Topic
├── 文件存储: Pool + 前缀隔离 + IAM
└── 网络: 取决于安全要求
    ├── 高安全 → Silo (VPC隔离)
    └── 一般 → Pool (Security Group)

---

架构设计实操：设计"零售SaaS平台"多租户架构

场景

一个面向零售行业的SaaS平台，提供库存管理、订单处理、会员系统等功能。需要服务从小型店铺到大型连锁品牌的不同客户。

租户分层设计

┌─────────────────────────────────────────────────────┐
│                  统一入口层                           │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐    │
│  │ API Gateway│  │ Tenant     │  │ Auth       │    │
│  │ (Kong)     │  │ Router     │  │ Service    │    │
│  └────────────┘  └────────────┘  └────────────┘    │
└──────────────────────┬──────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
┌──────────────┐ ┌───────────┐ ┌───────────────────┐
│  Enterprise  │ │Professional│ │     Basic         │
│  (独立部署)   │ │(混合模式)  │ │  (完全共享)        │
│              │ │            │ │                   │
│ 独立K8s      │ │ 共享计算   │ │ 共享计算           │
│ Namespace    │ │ 独立数据库  │ │ 共享数据库(RLS)    │
│ 独立数据库   │ │ 共享缓存   │ │ 共享缓存           │
│ 独立缓存     │ │ 独立消息队列│ │ 共享消息队列       │
│ 独立域名     │ │ 子域名     │ │ 统一域名           │
│              │ │            │ │                   │
│ 价格:$2000/月│ │ 价格:$500/月│ │ 价格:$50/月       │
└──────────────┘ └───────────┘ └───────────────────┘

数据隔离设计

-- Basic租户: 共享表 + RLS
CREATE TABLE retail.orders (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id VARCHAR(50) NOT NULL,
  store_id BIGINT NOT NULL,
  customer_id BIGINT,
  total_amount DECIMAL(18,2),
  status VARCHAR(20),
  created_at TIMESTAMP DEFAULT NOW(),

  -- 分区键（按租户分区提升查询性能）
  PARTITION BY LIST (tenant_id)
);

-- RLS策略
ALTER TABLE retail.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON retail.orders
  USING (tenant_id = current_setting('app.tenant_id'));

-- Professional租户: 独立数据库
-- 通过连接路由实现
-- tenant_db_map: { "pro_tenant_1": "postgresql://db-pro-1:5432/retail" }

-- Enterprise租户: 完全独立的基础设施
-- 通过Kubernetes Namespace + 独立数据库实例实现

定制化设计

{
  "tenant_id": "chain_store_001",
  "tier": "enterprise",
  "customization": {
    "branding": {
      "theme": "custom",
      "logo": "https://cdn.example.com/chain001/logo.svg",
      "domain": "erp.chainstore001.com"
    },
    "features": {
      "multi_store": true,
      "franchise_management": true,
      "custom_reports": true,
      "api_access": true
    },
    "workflow": {
      "order_approval": {
        "enabled": true,
        "levels": [
          { "amount_below": 5000, "approver": "store_manager" },
          { "amount_below": 50000, "approver": "area_manager" },
          { "amount_above": 50000, "approver": "cfo" }
        ]
      }
    },
    "plugins": [
      { "id": "custom-loyalty", "version": "2.1.0" },
      { "id": "erp-sync-sap", "version": "1.5.0" }
    ],
    "integrations": {
      "erp": { "type": "SAP", "endpoint": "https://sap.chainstore001.com/api" },
      "pos": { "type": "custom", "protocol": "tcp" }
    }
  }
}

计费设计

billing:
  basic:
    model: "subscription"
    base_price: 50
    currency: "USD"
    period: "monthly"
    includes:
      stores: 1
      users: 3
      orders_per_month: 1000
      storage_gb: 1
    overage:
      extra_order: 0.05  # $0.05/单
      extra_storage_gb: 2  # $2/GB

  professional:
    model: "hybrid"
    base_price: 500
    includes:
      stores: 10
      users: 50
      orders_per_month: 50000
      storage_gb: 50
      api_calls: 100000
    overage:
      extra_store: 30
      extra_order: 0.02
      extra_api_call: 0.001

  enterprise:
    model: "custom_contract"
    negotiated: true
    sla: "99.95%"
    dedicated_support: true
    custom_pricing: true

性能隔离设计

noisy_neighbor_protection:
  api_layer:
    rate_limiting:
      basic: { qps: 50, burst: 100 }
      professional: { qps: 500, burst: 1000 }
      enterprise: { qps: 5000, burst: 10000 }

  database_layer:
    connection_pooling:
      basic_shared_pool: { max_connections: 200, per_tenant_max: 10 }
      professional: { per_tenant_pool: 50 }
      enterprise: { dedicated_instance: true }
    query_timeout:
      basic: "5s"
      professional: "15s"
      enterprise: "60s"

  queue_layer:
    basic: { shared_topic: true, consumer_priority: "low" }
    professional: { dedicated_topic: true, consumer_priority: "medium" }
    enterprise: { dedicated_cluster: true, consumer_priority: "high" }

  monitoring:
    per_tenant_metrics: true
    alert_on:
      - "tenant_p99_latency > 2x_baseline"
      - "tenant_error_rate > 1%"
      - "tenant_resource_usage > 80%_quota"

---

AI增强

AI在多租户架构中的应用

1. 智能资源分配：

   • AI分析各租户的使用模式，预测资源需求
   • 动态调整租户配额（弹性配额 vs 固定配额）
   • 在Noisy Neighbor发生前主动扩容

2. 异常检测：

   • 识别异常的租户行为模式（可能的攻击/滥用）
   • 预测租户可能触发的资源瓶颈
   • 自动触发隔离升级（从Pool临时升级到Silo）

3. 智能计费：

   • AI推荐最优计费方案（基于租户使用模式）
   • 预测租户的增长趋势，提前规划资源
   • 识别有流失风险的租户

4. 定制化推荐：

   • 根据租户行为自动推荐功能配置
   • AI驱动的行业模板匹配
   • 智能插件推荐

---

Web3关联

区块链作为"终极多租户"平台

公链（如以太坊）本质上就是一个超大规模的多租户平台：

• 每个DApp都是一个"租户"
• Gas机制就是"按使用量计费"
• 区块Gas Limit就是"全局资源配额"
• EIP-1559的Base Fee就是"动态限流"

但区块链的Noisy Neighbor问题更严重：

• 一个热门NFT Mint可以让整条链的Gas费飙升10倍
• 所有用户都受影响，无法通过"升级套餐"解决

这也是Layer 2存在的意义之一——通过将不同应用迁移到不同的L2，实现"应用级隔离"。

SaaS + Web3的融合趋势

• 使用链上身份（DID）作为租户身份
• 基于Token的访问控制（持有特定NFT = Premium租户）
• 透明的计费（使用量和费用上链可验证）

---

今日思考

多租户架构的核心挑战是在"共享效率"和"隔离安全"之间找到平衡。完全隔离最安全但最贵，完全共享最便宜但风险最高。

AWS的Bridge模型给出了最实用的答案——不同租户层级、不同组件使用不同的隔离策略。这需要架构师对每个组件的noisy neighbor风险和安全要求有清晰的认识。

2025-2026年的新趋势：Serverless（Lambda/Fargate）正在简化多租户的计算隔离——每个租户的请求在独立的执行环境中运行，天然实现了计算级隔离。但数据隔离仍然是需要仔细设计的核心问题。

---

面试题

Q1: 多租户数据隔离如何选择？

30秒回答：三种策略按隔离强度排序：独立数据库>独立Schema>共享表+tenant_id。选择取决于合规要求、租户数量和成本预算。实践中推荐Bridge模型——高级租户独立数据库，普通租户共享表+RLS。

2分钟详细回答：

选择维度：

1. 合规要求：金融/医疗等强监管行业可能强制要求物理隔离 → 独立数据库
2. 租户数量：<100租户可以用独立Schema；>1000租户必须用共享表
3. 安全风险：数据泄露的后果有多严重？越严重 → 隔离级别越高
4. 成本预算：独立数据库成本最高，共享表最低

最佳实践（Bridge模型）：

• 将租户分为不同等级（Basic/Professional/Enterprise）
• Basic：共享表+PostgreSQL RLS强制隔离
• Professional：独立Schema或独立数据库
• Enterprise：完全独立的数据库实例，可能独立VPC
• 同时使用加密隔离——每租户独立加密密钥

追问准备：

• 共享表模式如何防止数据泄露？→ 数据库RLS + 应用层middleware + 定期审计
• Schema迁移如何处理？→ 共享表一次迁移；独立Schema需要逐个迁移（可并行）

Q2: Noisy Neighbor如何解决？

30秒回答：多层防御：API层限流（per-tenant QPS限制）+ 数据库层连接池隔离 + 计算层资源配额（K8s ResourceQuota）+ 队列层优先级隔离 + 全面的per-tenant监控告警。

2分钟详细回答：

Noisy Neighbor的本质是共享资源的竞争。解决方案需要在每一层资源上做隔离：

1. API入口层：per-tenant限流，超限返回429。使用令牌桶算法允许适度突发
2. 计算层：K8s ResourceQuota限制CPU/Memory。Serverless天然隔离
3. 数据库层：per-tenant连接池上限，防止一个租户耗尽连接。查询超时设置
4. 缓存层：per-tenant内存配额，或使用Redis Cluster的slot分配
5. 队列层：per-tenant Topic或优先级队列，确保高优租户消息优先处理
6. 监控层：实时监控每租户的资源使用，告警阈值设为基线的2倍

更高级的策略：自动弹性隔离——当检测到某租户负载异常时，自动将其从Pool模式临时升级到Silo模式。

---

学习资源

• AWS SaaS Lens - Silo/Pool/Bridge Models — AWS多租户参考架构
• AWS Tenant Isolation Strategies — AWS租户隔离白皮书
• Noisy Neighbor - AWS SaaS Lens — Noisy Neighbor问题
• Neon: Noisy Neighbor in Multi-tenant Architectures — Noisy Neighbor深度分析
• ElasticScale: AWS Multi-Tenant SaaS — 多租户SaaS架构实践
• Building Multi-Tenant SaaS with AWS Serverless — Serverless多租户

---

明日预告

明天我们将进行案例分析(12)：云厂商金融行业参考架构。我们将深入对比AWS、Azure、阿里云三家的金融云方案，分析云原生核心银行系统（Thought Machine/Temenos），并探讨混合云在金融行业的应用策略。