当前位置：首页 > news >正文

SaaS产品的技术架构陷阱：多租户、计费与隔离

news 2026/7/9 9:38:53

SaaS产品的技术架构陷阱：多租户、计费与隔离

一、SaaS架构的本质风险：被低估的工程复杂度

大多数技术创始人对SaaS的第一印象是"不就是个多租户的CRUD应用吗"。这个认知在MVP阶段是正确的——一个共享数据库、一个JWT鉴权、一个简单的按年计费就够用了。但当客户从10个增长到1000个，这个"简单架构"会逐个暴露出设计层面的结构性缺陷。

SaaS架构与其他Web应用的本质差异在于三点：数据要隔离（租户间不能互相看到数据）、资源要计量（按量或按时计费需要精确的使用量统计）、安全等级要按需（不同客户可能有不同的合规要求）。这三点的实现深度远超常规业务开发。

我见过的一个真实案例：某SaaS产品在客户100+时爆出数据泄漏——原因是某个报表SQL的WHERE tenant_id = ?条件在特殊情况下被ORM的N+1查询跳过，导致客户A看到了客户B的部分统计数据。修复这个问题的根因不是加一条WHERE条件，而是需要引入行级安全策略让数据库层兜底。

flowchart TD A[SaaS架构三大支柱] --> B[多租户隔离<br/>数据/性能/安全] A --> C[计费系统<br/>计量/定价/账单] A --> D[安全合规<br/>认证/审计/加密] B --> B1{隔离方案} B1 --> B2[共享数据库<br/>tenant_id隔离] B1 --> B3[独立Schema<br/>中等隔离] B1 --> B4[独立数据库<br/>完全隔离] C --> C1{计费模式} C1 --> C2[订阅制<br/>按月/年固定收费] C1 --> C3[用量制<br/>按API调用/存储计量] C1 --> C4[混合制<br/>基础订阅+超额用量] D --> D1[认证与SSO] D --> D2[审计日志] D --> D3[数据加密] D --> D4[合规认证] style B2 fill:#4CAF50,color:#fff style B3 fill:#FF9800,color:#fff style B4 fill:#2196F3,color:#fff

二、多租户隔离：三种方案的工程代价与选择

方案A：共享数据库+tenant_id列是MVP阶段的标准选择。所有租户的数据放在同一套表中，通过tenant_id列区分。优势是运维最简单（只需要一套数据库实例）、成本最低。风险是两个：SQL层面的tenant_id漏写（开发阶段容易失误），和"吵闹邻居"问题（一个大租户的慢查询拖慢所有其他租户）。

对于SQL层面的隔离，我们最终建立了双重保障机制：

第一重：ORM层自动注入tenant_id。所有Repository基础类中统一从当前请求上下文中获取tenant_id并注入查询条件。

@MappedSuperclass public abstract class TenantAwareEntity { @Column(name = "tenant_id", nullable = false) private String tenantId; @PrePersist @PreUpdate private void setTenantId() { if (this.tenantId == null) { this.tenantId = TenantContext.getCurrentTenant(); } } } // MyBatis拦截器自动注入tenant_id @Intercepts(@Signature(type = Executor.class, method = "query", args = {...})) public class TenantInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { // 自动为所有查询SQL添加 tenant_id 过滤条件 MappedStatement ms = (MappedStatement) invocation.getArgs()[0]; Object parameter = invocation.getArgs()[1]; // 检查是否已包含tenant_id，避免重复注入 addTenantCondition(ms, parameter); return invocation.proceed(); } }

第二重：数据库层行级安全策略（Row-Level Security）。PostgreSQL原生支持，MySQL可以通过视图+触发器模拟。

-- PostgreSQL 行级安全策略：数据库层兜底 ALTER TABLE orders ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.current_tenant')); -- 应用启动时设置当前租户 SELECT set_config('app.current_tenant', 'tenant-abc', false); -- 之后所有查询自动被 tenant_isolation 策略过滤

方案B：独立Schema是平衡隔离性与运维成本的选择。每个租户在同一个数据库实例中拥有独立的Schema（MySQL中的Database、PostgreSQL中的Schema）。优势是数据完全物理隔离（不会出现SQL漏写导致的泄漏），多租户之间不会相互影响索引和查询计划缓存。代价是Schema数量增长后的DDL变更管理变得复杂——对1000个Schema执行Alter Table需要工具体系支持。

方案C：独立数据库是最高隔离级别的方案，通常是为企业客户提供私有化部署或金融/医疗等强合规场景。每个租户拥有独立的数据库实例（或独立RDS实例），完全物理隔离，资源独占不共享。代价是运维成本随租户数量线性增长。

flowchart LR subgraph 演进路径 A[阶段1<br/>共享DB+tenant_id<br/>1-100租户] --> B[阶段2<br/>共享DB+独立Schema<br/>100-1000租户] B --> C[阶段3<br/>混合模式<br/>标准租户共享+大客户独立DB<br/>1000+租户] end A --> A1[实现:RDB行级安全<br/>+ORM拦截器] B --> B1[实现:Schema路由中间件<br/>+DDL变更工具] C --> C1[实现:租户路由网关<br/>+元数据中心] style A fill:#4CAF50,color:#fff style C fill:#2196F3,color:#fff

选择不是二元的。成熟的SaaS架构通常是混合模式：95%的标准客户使用共享数据库+独立Schema，5%的大型企业客户使用独立数据库（按需）。通过租户元数据中心（Tenant Metadata Store）统一管理租户与数据源的映射关系，路由网关根据当前租户自动选择目标数据库。

三、计费系统：从SaaS产品到SaaS生意的桥梁

计费是SaaS架构中最容易被技术团队低估的模块。它看起来只是"记录一下用户用了多少，月底扣钱"，但真实世界的计费逻辑远比这复杂。

一个完整的计费系统需要处理：多维度计量（API调用次数、存储空间、活跃用户数、功能模块数）、多种定价模型（订阅制、用量制、阶梯定价、承诺消费折扣）、账单生成与同步、支付对接、发票管理、欠费处理、试用转付费。

# 用量采集与聚合的典型架构 class UsageCollector: def record_usage(self, tenant_id: str, metric: str, quantity: float): # 1. 写入Redis时间窗口计数器（实时聚合） hour_key = f"usage:{tenant_id}:{metric}:{current_hour()}" redis.hincrbyfloat(hour_key, "quantity", quantity) redis.expire(hour_key, 7200) # 保留2小时 # 2. 异步写入Kafka（用于离线聚合和账单计算） kafka.send("usage-events", key=tenant_id, value={ "tenant_id": tenant_id, "metric": metric, "quantity": quantity, "timestamp": time.time() }) def aggregate_hourly(self): # 3. 每小时从Kafka消费，聚合并写入时序数据库 for event in kafka.consume("usage-events"): influx.write("usage_hourly", tags={ "tenant": event.tenant_id, "metric": event.metric }, fields={"quantity": event.quantity}) # 账单生成时的计量计算 class BillingEngine: def calculate_bill(self, tenant_id, billing_cycle): # 从时序库查询本期用量 usage = self.query_usage(tenant_id, billing_cycle) # 获取租户的定价方案 plan = self.get_tenant_plan(tenant_id) # 按定价规则计算费用（考虑阶梯定价、免费额度、折扣） base_fee = plan.base_price for metric, quantity in usage.items(): tier = plan.get_tier(metric, quantity) overage = max(0, quantity - tier.free_quota) base_fee += overage * tier.unit_price * tier.discount return Bill(tenant_id, billing_cycle, base_fee, usage)

计费系统的架构设计有两个核心原则：

幂等性：计费数据是钱，重复计费是不可接受的。用量采集、聚合、账单生成的每一个环节都必须支持幂等。通过唯一事件ID去重、数据库唯一约束、乐观锁版本号多重保障。

审计可追溯性：每一笔费用的计算过程都必须可追溯。当客户质疑"这个月为什么扣了这么多"，你能逐项展示从原始用量事件到聚合值到计费公式的完整链路。这不是技术选做项，而是商业上的必需品。

-- 计费事件幂等表设计 CREATE TABLE billing_events ( event_id VARCHAR(64) PRIMARY KEY, -- 唯一事件ID，天然幂等 tenant_id VARCHAR(64) NOT NULL, event_type VARCHAR(32) NOT NULL, quantity DECIMAL(20,4) NOT NULL, event_time TIMESTAMP NOT NULL, processed BOOLEAN DEFAULT FALSE, bill_id VARCHAR(64), -- 关联到生成的账单 created_at TIMESTAMP DEFAULT NOW() ); -- 账单聚合表：字段级可审计 CREATE TABLE bills ( bill_id VARCHAR(64) PRIMARY KEY, tenant_id VARCHAR(64) NOT NULL, cycle_start DATE NOT NULL, cycle_end DATE NOT NULL, subtotal_base DECIMAL(12,2) NOT NULL, -- 基础费用 subtotal_api DECIMAL(12,2) NOT NULL, -- API调用费用 subtotal_storage DECIMAL(12,2) NOT NULL, -- 存储费用 discount DECIMAL(12,2) NOT NULL DEFAULT 0, total DECIMAL(12,2) NOT NULL, -- 每个子项目的计费明细以JSON存储，保持计算逻辑可见 calculation_detail JSONB NOT NULL, UNIQUE(tenant_id, cycle_start) );

四、安全与合规：从功能到信任基础设施的跨越

SaaS产品的安全问题不在于"会不会被攻击"，而在于"对客户的数据有没有制度化的保护机制"。当一个SaaS产品从小客户走向中大型企业客户时，安全审查是合同签署前的必过关卡。SOC 2、ISO 27001、GDPR——这些不再只是大厂的事。

数据加密的三层模型：

传输层加密（TLS 1.3）是基础要求，今天几乎没有SaaS产品会不启用HTTPS。但存储层加密（at-rest encryption）经常被忽视。云厂商的RDS/对象存储通常提供了透明的存储加密（TDE），开启步骤通常在一页控制台上。问题在于密钥管理——使用云厂商托管的密钥让加密变得简单，但密钥的所有权在云厂商手中。对于金融级客户，需要引入自持密钥（BYOK）或HSM。

应用层加密是针对最高敏感数据（如支付信息、个人可识别信息）的加密策略。在数据写入数据库前，应用层使用AES-256-GCM加密，密钥存储在独立于数据库的KMS中。即使数据库完全泄漏，没有KMS密钥也无法解密核心数据。

审计日志是一个经常被做成"有就行"但其实是合规基石的系统。一个合格的审计日志应该回答三个问题：谁（哪个租户的哪个用户）、在什么时候、做了什么操作（包括操作前后的数据快照）。

@Aspect @Component public class AuditAspect { @Around("@annotation(auditable)") public Object audit(ProceedingJoinPoint pjp, Auditable auditable) { AuditLog log = new AuditLog(); log.setTenantId(TenantContext.getCurrentTenant()); log.setUserId(SecurityContext.getCurrentUser()); log.setAction(auditable.action()); log.setResourceType(auditable.resource()); log.setTimestamp(Instant.now()); // 捕获操作前的数据状态 if (auditable.captureSnapshot()) { log.setBeforeSnapshot(captureState(pjp.getArgs())); } Object result = pjp.proceed(); // 捕获操作后的数据状态 if (auditable.captureSnapshot()) { log.setAfterSnapshot(captureResult(result)); } // 异步写入审计日志（不可影响业务性能） auditLogService.writeAsync(log); return result; } }

审计日志的存储策略需要考虑保留期限（通常≥90天，金融行业可能要求7年）和查询性能。高频写入→Kafka缓冲→批量写入ClickHouse/Elasticsearch是一种工业级的方案。