小陈是一家SaaS公司的技术总监他们做的是中小企业CRM系统。创业初期产品功能单一客户需求也趋同。但随着客户越来越多问题就来了制造业客户说“我们的客户分级逻辑和你们默认的不一样要按年采购额而不是最近活跃度。”金融客户说“我们的审批流程需要四级会签而且每个人的权限要动态计算。”零售客户说“我们的促销规则很复杂除了满减还有满赠、换购、积分翻倍。”为了拿下这些客户小陈的团队疲于奔命。每个大客户都要单独fork代码分支在分支上做定制开发。随着分支越来越多合并代码变成了一场噩梦。这就是SaaS厂商规模化扩张中普遍面临的困境。一、租户隔离模式下的个性化挑战1.个性化需求的三个层次层次示例实现难度参数配置修改阈值、开关功能低流程调整增加/删除审批节点中逻辑重构改变算法、业务规则高前两个层次通过传统的配置系统可以解决最麻烦的是第三个层次——业务逻辑的变化。2. 传统做法的局限性做法一为每个大客户单独fork代码分支问题未来无法合并维护成本随客户数线性增长做法二在代码中写满if-tenantId问题代码可读性急剧下降改动一个地方需要测试所有租户做法三把所有逻辑都参数化问题参数数量爆炸租户配置页面变得极其复杂3. 更优的思路将“业务规则”作为一等公民和租户绑定。核心思想是规则不再是系统代码的一部分而是租户的可配置资产。系统提供规则的定义能力和执行环境租户在自己的空间内配置规则执行时根据租户ID加载对应的规则集二、多租户规则管理的核心设计1.变量的分层设计规则中使用的变量来自不同层级系统级变量定义所有租户共享、不可修改示例当前时间、请求来源IP、设备类型租户级变量定义租户可以自定义的业务概念示例“高价值客户”的定义消费5000且活跃30天应用级变量定义单次请求传入的临时数据示例当前用户ID、申请金额、商品ID规则编写时可以引用任何层级的变量。系统自动解析依赖关系在运行时注入正确的值。2.规则的租户隔离每个租户都有自己的规则空间租户A的规则只能被租户A的请求触发修改租户A的规则不影响租户B规则执行时使用的变量、数据源都是租户隔离的存储设计每条规则记录都包含tenant_id字段。SQL查询时自动带上租户过滤条件防止越权。3.规则的继承与覆盖这是降低配置成本的关键机制。基础规则集由SaaS厂商维护是所有租户的默认配置包含通用的业务规则模板租户覆盖租户可以“继承”基础规则集然后选择覆盖其中部分规则未被覆盖的规则仍然沿用基础规则这种设计的好处新租户入驻时默认拥有完整的基础规则开箱即用需要个性化时只修改差异部分不需要重头配置基础规则集升级时未覆盖的租户自动获得更新4.规则的灰度发布在多租户环境下规则变更的风险被放大了,一个规则bug可能影响所有租户。灰度发布流程在测试环境验证新规则发布到生产环境但只对白名单租户生效观察这些租户的数据确认无误逐步扩大灰度范围10% → 50% → 100%如有问题立即回滚只影响灰度租户三、数据源层面的租户隔离规则引擎不仅需要在规则层面隔离还需要在数据访问层面隔离。1.多数据源路由不同的租户可能使用不同的数据库大租户独立数据库实例中小租户共享数据库、独立schema小微租户共享数据库、共享schematenant_id区分规则引擎在执行时需要动态选择正确的数据源。2.动态SQL生成规则中可能包含对业务表的查询。这些查询语句需要自动附加租户过滤条件。例如规则中写“查询用户近30天的订单总额”执行的SQL应该自动变成租户ID从当前请求上下文中隐式获取规则编写者不需要手动传入。四、实战案例多租户CRM的审批流配置1.场景描述某SaaS CRM系统客户租户的审批流程各不相同租户A简单审批销售→老板租户B分级审批销售→总监→财务→老板租户C条件审批1万销售审批1-5万总监审批5万老板审批2.规则引擎的表达方式决策流配置通过可视化的决策流编辑器租户B可以自己画出审批节点和流转条件。决策表配置租户C的条件审批可以表达为一张决策表金额范围下一审批人10000销售主管10000-50000销售总监50000总经理租户C不需要开发介入直接在后台配置这张表。3.租户之间的互不影响租户A修改了自己的审批流程租户B和C完全感知不到。每个租户拥有独立的决策流实例和版本历史。五、SaaS厂商需要考虑的其他问题1.规则执行性能多租户环境下规则总数可能急剧膨胀。每个租户有自己的规则集加起来可能有数万条规则。性能优化策略规则预编译将租户规则提前编译为可执行代码缓存起来租户级缓存相同租户的相同请求结果可以缓存异步执行非实时要求的场景放入队列异步处理2.版本回滚租户修改规则后发现问题需要能够一键回滚到之前的版本。规则的历史版本应该保留并提供可视化的差异对比哪些规则变了、变前后有什么不同。3.操作审计租户管理员可以查看本租户内的规则操作记录谁、什么时候、改了什么。SaaS厂商需要更高级别的审计哪个租户在什么时间修改了什么规则用于排障和合规。4.计费模式规则引擎本身也可以作为计费的一个维度按规则数量阶梯收费按决策调用次数收费按租户使用的功能模块收费结尾“千企千面”不是一句口号而是SaaS企业的生存之道。不能用硬编码的方式去应对每个客户的个性化需求那是一条走不远的路。规则引擎提供了另一种思路把业务逻辑的执行权从开发人员手中部分转移到租户或运营人员手中。系统提供能力和框架租户根据自己的需要填充内容。这种模式下开发团队可以专注于平台能力的建设而不是陷入一个个定制需求的泥潭。一套代码千企千面这才是SaaS应有的姿态。如果您对规则引擎有疑问可以与我们一起交流。若想体验有在线Demo:https://rules.bctools.cn