说说那些年做SaaS系统架构时踩过的坑和学到的经验教训

说到做SaaS系统架构时踩过的坑，那真是三天三夜也说不完，我就挑几个印象最深的，用大白话讲讲,希望能给你提个醒。

第一个大坑：以为租户数据隔离就是加个字段那么简单。

刚开始做的时候，想法特别天真，觉得SaaS嘛，不就是多个客户用同一套系统吗？那给每个表加个“租户ID”字段不就行了？查询数据的时候，每个请求都带上这个ID做过滤，数据不就自然隔离开了？听起来很美,对吧？

结果一上线就傻眼了，最要命的是性能问题，你想想，随着客户越来越多，数据量爆炸式增长，每一条SQL语句都要加上“WHERE tenant_id = ?”这个条件，这会导致数据库的索引变得非常复杂，甚至失效，有一次，一个不小心的开发人员写了个查询，忘了加这个租户ID条件，直接来了个全表扫描，差点把数据库拖垮，所有客户的系统都卡死了好几分钟，那真是惊心动魄，这叫“数据噪音”问题,一个租户的慢查询可能会影响到所有租户。

逻辑删除的坑，我们有些表为了数据安全，用的是逻辑删除，就是加个“is_deleted”标记，有一次，某个客户要求彻底删除他们的所有数据，我们才发现，要在一个上亿条记录的大表里，精准地只删除某个租户的逻辑删除数据，简直是一场灾难，操作起来风险极高，生怕误删了别人的数据，从这儿我学到，数据隔离策略必须在设计之初就深思熟虑，不能拍脑袋，后来我们研究了多种方案，比如独立数据库（成本太高但最安全）、共享数据库但独立模式（schema），最后根据业务场景做了混合架构，核心、敏感数据用独立模式，一些通用、非核心的数据才用共享表加租户ID的方式，这个教训就是，架构设计不能偷懒，简单的方案背后可能隐藏着巨大的运维成本。

第二个大坑：低估了“可配置性”带来的复杂度。

SaaS产品要满足不同客户的需求，肯定要做很多可配置的功能，有的客户希望工作流是这样走的，有的客户希望表单字段是那样的，我们一开始觉得，这不就是多几个配置项嘛,在数据库里建几张配置表就搞定了。

但现实是，配置项之间会相互影响，产生“组合爆炸”，你给一个审批流程配置了A、B、C三个节点，又允许客户配置条件跳转，当A、B、C三个节点的条件可以任意组合跳转时，可能的路径数量是指数级增长的，这带来的问题是：第一，测试根本没法全覆盖，你无法预知客户会配出多么奇葩的流程，线上bug不断，第二，系统代码里充满了“if...else...”来判断各种配置，代码变得像一团乱麻，难以维护，加一个新功能要改动很多地方,生怕动了别人的逻辑。

我们曾经为了一个高度可配置的报表系统，把后端代码写得无比复杂，后来几乎没人敢动那块代码，经验教训就是，“过度配置”是万恶之源。 后来我们学乖了，采用了一种叫“约定大于配置”的思路，我们不再追求满足客户100%的个性化需求，而是提炼出80%客户的通用需求，把它做成产品固化的、最优的标准流程，对于另外20%的特殊需求，我们通过开放API的方式，让客户自己去做二次开发集成，或者由我们的实施团队通过低代码平台去有限度地实现，这样既保证了核心产品的稳定和简洁,又保留了足够的灵活性。

第三个大坑：对“灰度发布”和“故障隔离”的漠视。

早期我们系统更新，经常是周五晚上搞到半夜，然后把新版本直接部署上线，祈祷一切顺利，这种“赌博式”发布不出问题则已，一出问题就是大问题，有一次，我们给一个新客户做了一个定制化功能，觉得没问题就全量发布了，结果这个功能里的一个隐藏bug，导致我们一个老客户的核心业务流程出了错，造成了实际的经济损失,差点丢了那个大客户。

这件事给了我们当头一棒，SaaS是多租户的，你的任何一个改动，影响的不是一个人，而是一群人，一群公司，从此以后，我们坚决推行灰度发布机制，具体做法是：第一，建立完整的预发布环境，严格模拟线上数据，第二，任何新功能上线，先在公司内部试用，再挑选一两个友好的“体验客户”试用，最后才分批次、按比例逐步放量给全体客户，我们加强了监控和告警，一旦发现某个新版本的数据指标（如错误率、响应时间）有异常,立刻能自动回滚到上一个稳定版本。

这个坑让我们真正理解了什么叫“SaaS服务的责任感”，你的代码不再只属于你，它关系到无数客户的正常运营。稳字当头，是SaaS架构的第一要务。 宁可新功能晚上线一周,也绝不能因为仓促而带来不稳定的风险。

做SaaS架构，本质上是在平衡艺术，平衡隔离与成本、平衡个性化与复杂度、平衡创新与稳定，每一个坑踩下去都很疼，但爬出来后的经验,都成了后来设计中最宝贵的财富。