SaaS 稳定性保障与模块化架构研究

基于 Zenoti / Boulevard / Vagaro / Fresha 等沙龙管理 SaaS 行业实践 · 2026-02-06

1. 运行稳定性保障策略

1.1 分层防御体系

SaaS 系统的稳定性不是靠单一手段，而是靠多层防御叠加实现的。每一层独立发挥作用，即使某一层失效，其他层仍能兜底。

Circuit Breaker（熔断器）

熔断器有三个状态：Closed（正常通过）→ Open（全部拒绝，快速失败）→ Half-Open（试探恢复）。

// 概念示例（非实际代码）
// 当 CodePay 连续失败 5 次 → 熔断 30 秒
// 30 秒后允许 1 个请求试探
// 试探成功 → 恢复；失败 → 继续熔断

CircuitBreaker 配置:
  - failureThreshold: 5        // 连续失败 5 次触发
  - resetTimeout: 30000        // 熔断 30 秒
  - monitorInterval: 10000     // 每 10 秒检查

Graceful Degradation（优雅降级）

核心思想：核心功能永远可用，非核心功能可以临时关闭。

Backpressure（背压控制）

当系统负载超过处理能力时，不是无限接收请求直到崩溃，而是主动拒绝多余请求。

• Connection Pool 限制：PostgreSQL 连接池 max=20，超过排队等待
• Worker Queue 限制：报表导出、邮件发送等后台任务队列设置上限
• Per-tenant Rate Limit：防止单个大租户的请求影响其他租户

1.2 可观测性三支柱

2. 测试策略 — 发现边缘情况的方法论

2.1 Testing Trophy vs Testing Pyramid

传统的测试金字塔（大量单元测试 + 少量集成 + 极少 E2E）适合库和框架。但对 业务逻辑重 的 SaaS 应用，Kent C. Dodds 提出的 Testing Trophy 更合适：

2.2 发现边缘情况的具体方法

2.3 测试之外的质量保障手段

2.4 覆盖率的真相

// 这个测试覆盖率 100%，但没有验证任何东西
test('getAppointments', async () => {
  const result = await getAppointments(storeId);
  // 没有 expect/assert！
  // 覆盖率工具认为代码都跑过了 ✅
  // 但实际上什么都没检查 ❌
});

3. 模块间兼容性 — 高内聚低耦合

3.1 当前的耦合问题

问题：每添加一个新功能，都要修改已有模块。比如以后要在预约创建后"自动发送调查问卷"，就得改 appointments.js，违反了开闭原则。

3.2 目标架构：事件驱动解耦

3.3 依赖方向规则

平级 Service 间的通信有两种正确方式：

1. 事件总线（异步）：Service A 发出事件，Service B 监听并响应
2. 编排层（同步）：由上层 Orchestrator/UseCase 协调多个 Service 的调用

3.4 模块边界定义

3.5 接口契约化

每个模块暴露的接口需要显式定义和强制验证：

// 模块的公共接口应该是稳定的契约
// 内部实现可以随时变，但接口不能随意改

// ✅ 好的做法：模块通过 index.js 暴露有限的公共 API
// appointment-module/index.js
module.exports = {
  createAppointment,    // 公共 API
  getAppointment,       // 公共 API
  updateStatus,         // 公共 API
  // 内部函数不导出
};

// ❌ 坏的做法：外部模块直接 require 内部文件
const { validateTimeSlot } = require('../appointment-module/internal/validator');

4. Celoria 项目具体行动计划

按优先级排序

5. 行业对标：竞品是怎么做的