账云 CloudLedger 是一款面向小微企业的云端财税 SaaS，帮助代账会计与创业公司完成记账、开票、报税与财务报表生成。产品上线第三年，付费客户从最初的两百家增长到八千家，技术债也随之累积——早期的单体应用已经跑在一台数据库上，月底结账高峰期频繁出现慢查询与超时。
客户找到泰格视觉时，并没有打算换技术栈，而是希望我们在「不中断现有业务」的前提下，把后端架构演进到能支撑五万家客户的规模，同时把每月最耗人力的报税流程进一步自动化。
走查代码后，我们列出了四张风险清单：所有租户数据共用一个库表，靠 tenant_id 区分，一旦索引失效就会全表扫描；账单计算逻辑散落在四十多个脚本里，会计每到月底要手动跑五批任务；报税模块与税务总局接口之间没有重试与对账机制，曾出现过申报成功但前端未回写的事故；监控只有一台云主机的磁盘告警，应用层错误率无人知晓。
我们没有做大爆炸式的重写，而是用六个月把单体拆成六个可独立部署的服务。
按租户规模分库：前两千家大客户独占 Schema，中小客户共享 Schema 但强隔离；账单与凭证数据按月份分区。
把散落的记账规则收敛为一套可视化规则引擎，会计可在后台配置「工资—社保—个税」联动，系统自动生成凭证。
对接税务总局接口加入幂等重试、状态机与每日对账任务；任何申报异常都会在企业微信推送给值班工程师。
财税系统最残酷的考验是月底与征期截止日。我们对账单跑批做了三件事：把原来串行的任务拆成可并行的租户级分片；引入消息队列削峰，让八千家客户的凭证生成在三小时窗口内平稳完成；为每批任务加入断点续跑，中途失败不必从头再来。
可观测性方面，我们搭了一套从日志、指标到链路追踪的看板，错误率、慢查询、接口耗时按租户维度下钻。上线第一个月，值班工程师第一次在用户投诉之前就发现了问题。
财税系统最经不起「停机维护」四个字，我们用双写与灰度把风险压到最低。
数据迁移阶段，我们没有直接切换库，而是让新旧两套数据库并行写入两周：用户在前端的每一次操作，同时落在老库与新库上，后台每分钟对账比对两库数据差异，直到连续三天差异为零才开始只读切流。整个过程客户无感知，没有出现一笔凭证丢失。
服务上线采用租户灰度：先放 50 家测试客户观察一周，再扩到 500 家、2000 家，最后全量。每一档都设定了错误率与响应时间的熔断阈值，一旦异常立刻回滚到上一档。
合规层面，财税数据涉及企业敏感财务信息，我们在多租户隔离之外，补充了传输加密、敏感字段脱敏与操作审计日志，满足等保三级对日志留存半年的要求。会计人员的每一次越权查询都会被记录并告警。
项目收尾时，我们把所有架构决策写成一份内部技术文档，并对客户的两名后端工程师做了为期两周的结对带教，确保交接后他们能独立维护这套系统——这也是我们不希望客户「离了乙方就不会走路」的一贯做法。
架构升级完成后，账云顺利承接了客户数五倍的增长
我们之前一直担心「重构」会把现有的客户搞挂，所以拖了两年不敢动。泰格的工程师最让我安心的是，他们每一步都先写兼容层、再灰度切流，整个六个月过程中没有出现一次影响客户的故障。更难得的是，他们不只是把代码重写快了，而是真的理解代账会计月底在干什么，账单引擎现在帮我们每个征期省下了两个全职人力。
我们始终认为，后端项目的价值不在架构图有多漂亮，而在月底三点钟、系统还能安安静静地跑完八千家客户的凭证。渐进式重构、双写灰度与结对带教，本质上都是为了让客户的业务一天都不停摆——这是泰格视觉对每一个技术项目的底线承诺。
项目交付后，我们与账云签订了一年期的远程运维支持，每季度联合做一次容量评估与压测，确保客户数从八千走向两万的过程中，系统始终领先业务一步。
这套渐进式重构方法论，后来被我们复用到三家不同行业的 SaaS 客户身上，平均把迁移周期缩短了三成，也把客户的停机风险压到了最低。系统稳定运行，是我们对每一位托付者的基本交代。
从架构到运维，泰格视觉为 SaaS 团队提供长期工程伙伴