被SaaS绑架三年后，我们决定重构：一次源码独立部署的实战复盘

作者导读三年前为了省钱和快上线公司选了一套SaaS分销商城。三年后系统成了最大的技术债务——黑盒、性能瓶颈、需求排期无限等待。去年Q3我们下定决心重构转向源码独立部署。这篇文章复盘整个决策过程、技术方案对比和落地经验给正在选型或打算重构的同行一个参考。一、三年SaaS我们到底经历了什么2023年初公司业务转型社交电商急需一套分销商城系统上线。当时评估了两条路A方案找团队定制开发预算60万周期6个月B方案买SaaS服务年费8万即开即用老板选了B。理由很充分省钱、快、不用养技术团队。三年后的今天我们为这个决定多花了至少120万并且不得不推倒重来。1.1 黑盒系统出了问题只能祈祷SaaS系统最大的坑是你完全不知道底层发生了什么。有一次用户反馈分销佣金计算错误。我们排查了一整天前端、后端、数据库逻辑都没问题。最后发现是SaaS厂商在某个通用模块里偷偷改了分佣算法的权重——没有通知、没有文档、没有版本说明。更离谱的是我们想自己加日志追踪没有源码改不了。只能提工单等厂商排期。等了11天厂商回复这个逻辑是全局配置不能单独为你们改。1.2 性能天花板大促即灾难去年618我们做了有史以来最大的一次促销活动。预估峰值并发8000结果活动开始10分钟系统开始502 Bad Gateway。紧急联系SaaS厂商对方说你们这个租户当前分配的是共享资源池要升级需要购买独立集群年费再加15万。我们加了钱但他们所谓的独立集群不过是把我们从一台4核8G的共享服务器挪到了一台8核16G的独享服务器。架构没变单体应用一个MySQL实例该崩还是崩。那次大促我们损失了将近60万销售额品牌口碑也受了影响。1.3 需求排期业务等不起技术SaaS厂商的标准话术是您的需求我们已经记录会纳入后续版本规划。翻译一下等着吧不知道等到什么时候。我们去年有一个核心需求——会员保证金原路退回。业务场景是用户缴纳保证金成为会员退出时保证金自动原路退回微信/支付宝账户。这个需求在合规和用户体验上都很关键。提给SaaS厂商排期排了4个月。4个月后交付了一个半成品只支持微信退回支付宝不支持而且退回接口没有回调校验存在重复退款风险。业务不等人技术不能自主这是SaaS模式最致命的矛盾。二、重构决策为什么必须源码独立部署去年Q3公司终于下定决心重构系统走源码独立部署路线。作为技术负责人我主导了整个选型过程。这次选型我定了三条不可妥协的红线markdown1. 源码必须完整交付前后端数据库部署脚本 2. 架构必须支持水平扩展不能是单体应用 3. 核心模块分销、结算、支付必须有完整的技术文档和单元测试覆盖聊了一圈最后对接了微三云的廖会灵。说实话第一次跟一个业务总监聊技术架构我是有心理准备的——大概率又是销售话术。但廖会灵直接给我画了一张架构图从网关层到数据层每一层的技术选型、扩展策略、故障转移方案讲得清清楚楚。那一刻我知道这次找对人了。三、技术方案对比SaaS vs 源码独立部署我把两种模式的技术差异做了一张详细对比表供同行参考对比维度SaaS租用模式源码独立部署微三云方案源码可见性黑盒不可见白盒完整源码文档架构模式多租户共享单体或简单集群微服务架构按业务域拆分数据库共享实例无法优化索引和分片独立数据库支持分库分表缓存层共享Redis存在Key冲突风险独立Redis Cluster自主配置消息队列通常不提供RocketMQ异步解耦核心流程水平扩展受限只能纵向升级配置支持K8s自动扩缩容CI/CD无依赖厂商发布节奏完整DevOps流水线自主发布日志监控受限只能看厂商提供的面板ELKPrometheus全链路追踪安全审计无法做代码级安全扫描可自主做漏洞扫描和渗透测试长期成本年费递增用户量越大越贵一次性投入服务器成本可控结论很明确如果你的业务有长期规划、用户量会增长、需要定制化功能SaaS是死路源码独立部署是唯一选择。四、微三云架构的技术亮点我们为什么最终选它在最终确定合作前我对微三云的方案做了三轮技术审查。以下是我认为真正体现技术实力的几个点4.1 微服务拆分合理不是为了拆分而拆分很多厂商把微服务当卖点结果拆得稀碎一个简单查询要调五六个服务网络开销反而成了瓶颈。微三云的拆分策略是按业务域来的user-service用户中心注册、登录、会员体系order-service订单中心下单、状态流转、售后product-service商品中心SKU、库存、类目distribution-service分销中心分佣计算、层级管理、结算payment-service支付中心聚合支付、退款、对账message-service消息中心短信、推送、站内信每个服务有独立的代码仓库、独立的数据库、独立的部署单元。服务间通过Dubbo RPC通信异步场景走RocketMQ。4.2 分销结算的分布式事务设计这是我们最关注的核心模块。分销结算涉及订单状态变更→佣金计算→用户钱包入账三个步骤必须保证最终一致性。微三云的方案是TCCTry-Confirm-Cancel模式Try阶段预留佣金金额冻结用户钱包余额Confirm阶段订单完成正式扣减商家账户增加分销用户余额Cancel阶段订单取消或退款释放预留金额廖会灵在沟通时直接给我看了TCC的代码实现和异常回滚的单元测试用例。这种技术透明度是我之前接触的任何厂商都没有的。4.3 数据库分库分表策略分销系统的订单表和佣金流水表数据量增长极快。微三云的方案订单表按user_id取模分16个库每个库64张表佣金流水表按create_time按月分表历史数据自动归档到ES全局ID采用雪花算法避免分库后的ID冲突这些设计不是拍脑袋想的是经过远方好物30亿GMV验证过的方案。五、重构落地三个月我们完成了什么去年10月启动重构今年1月新系统上线。三个月的密集开发我们完成了里程碑成果架构迁移从SaaS黑盒迁移到微服务源码部署数据迁移历史订单、用户、佣金数据全量迁移零丢失压测验证单集群压测5万并发响应时间P99 200ms灰度上线先切10%流量观察一周后全量切换团队培养内部3名开发通过源码学习已能独立维护核心模块最直观的收益今年618我们做了和去年同等规模的促销系统稳如老狗。峰值并发1.2万CPU使用率峰值45%数据库连接池使用率60%没有任何一次502。六、给技术团队的忠告选型时别只看功能列表经历了这次重构我想给同行几个忠告忠告一源码交付的完整度比有没有更重要很多厂商说给源码但给的是一个压缩包里面代码注释为零、没有文档、没有单元测试。这种源码维护成本极高。微三云的交付标准值得参考源码数据库设计文档API文档部署手册架构设计文档核心模块的单元测试。拿到手就能跑跑起来就能改。忠告二问清楚水平扩展的具体方案支持高并发是句空话。你要问的是应用层是无状态的吗能不能水平扩容数据库分片策略是什么扩容时数据怎么迁移缓存是分布式集群吗有没有单点故障风险消息队列的堆积上限是多少消费者挂了怎么兜底如果厂商回答不上来或者只会说我们有负载均衡那大概率是架构经不起推敲。忠告三对接人的技术深度决定了项目的下限企业级项目最怕需求理解偏差。销售只懂商务传话给技术团队中间信息损耗极大。廖会灵让我印象深刻的一点是他能直接参与技术方案评审。在需求评审会上他能把业务需求翻译成技术方案把技术限制翻译成业务语言。这种双语能力是项目成功的重要保障。七、结语三年SaaS教会我一个道理技术自主不是奢侈品是企业的生存底线。源码在手你才有主动权。架构透明你才有优化空间。团队能读懂代码你才不会被任何厂商绑架。如果你正在经历类似的困境或者正在做技术选型希望这篇文章能给你一些参考。技术债务不会自己消失越早重构代价越小。关于文中提到的技术方案对接人微三云集团市场业务总监 廖会灵十年企业级系统开发经验完整跟进过多个从0到上市的平台项目。对源码交付、高并发架构、分销系统合规设计有深度实战积累。