SaaS 系统如何处理“同样功能，不同租户差异化”的问题？

在构建多租户的 SaaS 系统时，最具挑战性的部分之一是：如何在保持代码复用、架构清晰的前提下，实现租户级别的功能差异化？
这种“同功能、差实现”的需求在实际交付中极其常见，常出现在促销策略、审批流程、计费规则、报表口径等场景中。本文将从工程角度深入探讨这一问题的常见解决方案与推荐实践。

一、问题背景

SaaS 系统强调“一个平台服务多个租户”，追求统一性。但随着客户规模扩大，不同租户往往会提出：

• 自定义审批流（A需要三级审批，B只要一次）

• 不同的定价策略（A根据数量阶梯价，B按客户等级定价）

• 报表统计口径不同（A按下单时间，B按发货时间）

• 特定业务限制（A禁止负库存销售，B允许超卖）

这些差异化需求如果处理不当，系统就会陷入**“if/else 地狱”、“代码难以维护”、“变更牵一发而动全身”**等困境。

二、常见差异化处理方式比较

三、推荐方案：统一服务 + 插拔式差异化机制

针对实际交付中差异化需求频繁、变动不可控的现实，我们推荐一种“基础服务 + 插拔式差异化逻辑”的设计模式：

✅ 1. 统一服务入口

所有逻辑入口保持统一，例如：

Result process(OrderContext ctx) {
    Strategy s = strategyRegistry.get(ctx.tenantId, "orderStrategy");
    return s.execute(ctx);
}

✅ 2. 差异化注册中心

使用注册中心维护各租户的差异实现绑定（可来源于数据库、配置中心或注册代码）：

{
  "tenantA": {
    "orderStrategy": "TenantAOrderStrategy"
  },
  "tenantB": {
    "orderStrategy": "DefaultOrderStrategy"
  }
}

✅ 3. 存储过程支持（可选）

当逻辑过重时，将计算/结算/统计类逻辑交由数据库中的 sp_tenant_xxx 存储过程处理，应用层仅做参数传递与结果封装。

CALL sp_tenantA_calc_order_discount(:orderId);

四、案例：订单金额计算差异化

可实现如下结构：

• 公共接口：OrderDiscountStrategy

• 实现类：

  • TenantAOrderDiscountStrategy

  • TenantBOrderDiscountStrategy

  • TenantCOrderDiscountStrategy

• 注册器：维护租户到实现类的映射

• 入口服务：通过租户ID选择策略类，执行优惠逻辑

对性能要求高的租户（如月结数据量大），还可配置：

• TenantB 使用 sp_tenant_b_discount_calc 存储过程计算优惠

五、维护与治理建议

六、结语

在 SaaS 系统中处理功能差异化，是架构设计中必须面对的复杂问题。没有放之四海而皆准的万能解法，关键在于：

• 统一的架构思想（统一入口、统一接口）

• 灵活的插件/策略机制

• 必要时引入存储过程或脚本引擎支持

统一中求差异，差异中保一致。
差异可扩展，统一可演进，才是一个真正可持续的SaaS架构。