「SAAS + 自建」混合架构实践——传统行业数智化的成本与架构博弈

背景

传统超大型租车公司数智化项目，30个管理岗 + 1000个一线司机。核心流程：接单→接人→运输→到达，四节点状态流转，每节点采集照片、GPS、手写签字、数字表单，支持一单多司机并行。

核心矛盾：管理端用SaaS平台没问题（30人订阅费可控），但1000个司机和下游服务商的SaaS订阅费直接劝退客户。而且司机的多节点状态流转、并行作业，SaaS的外链表单也撑不住。

架构：「厚前端 + 薄后端 + SaaS中台」

┌─────────────────────┐ ┌──────────────────────┐

│ 微信小程序(1000司机) │ → │ Node.js API(自有服务器) │

│ · 多节点状态流转 │ │ · 状态机引擎 │

│ · 多模态数据采集 │ │ · 多模态数据聚合 │

│ · 离线暂存(预留) │ │ · SaaS OpenAPI双向同步 │

└─────────────────────┘ └───────────────────────┘

1. 计算与数据分离 — API跑在自有服务器，但数据库和文件存储上云。服务器挂了可快速重建，数据不能丢。牺牲可用性，保数据完整性。
2. SaaS只做数据中台 — SaaS承担它擅长的事（仪表盘、报表、审批流），1000人的数据采集链路剥离到自建系统。数据通过Webhook+API双向同步，SaaS是唯一数据源。
3. 轻量状态机替代BPMN — 没用Temporal/Camunda，用JSON字段+状态码实现。200人规模不需要重型编排引擎，但扩展性是隐患。

纠结点：

1. 双向同步的最终一致性 — SaaS不支持事务，自建系统↔SaaS之间的数据同步，各位有没有比「 定时重试 + 人工兜底」更优雅的方案？
2. 状态机的扩展边界 — 当前4节点线性流转够用，但客户需求在膨胀（条件分支、动态节点）。轻量状态机到什么规模该切BPMN？有没有量化的判断标准？
3. 多模态数据的存储成本 — 1000人×4节点×5MB ≈ 20GB/天。SaaS侧的附件存储和带宽会不会成为隐性瓶颈？回写URL还是转存到SaaS？

客户AI方向的规划：

AI路径

不做AI规划的架构师不是好架构师。这个项目的终局是「智能运输调度平台」：

近期 — 边缘AI：小程序端嵌入轻量OCR模型（TFLite），本地识别里程表读数、校验签字真实性。挑战是模型控制在10MB内。

中期 — 云端AI：引入智能调度（订单-司机最优匹配）、ETA预测、异常检测（路线偏移/异常停留）。数据管道：GPS轨迹流 → Kafka → TDengine → 特征存储 → 模型推理。

模型部署选型：初期用第三方API验证，中期迁移到自有GPU服务器。7B模型在RTX 4060上跑，200人规模够用，月推理成本可压到几百元。

远期 — 多租户SaaS：验证跑通后产品化，卖给更多物流/租赁公司。数据隔离方案倾向「核心独立库 + 边缘共享库」，但还在评估。

几个问题：

1. SaaS+自建混合架构中，双向同步有没有比消息队列+重试更干净的方案？
2. 小程序端嵌入TFLite做本地推理，有人做过实际项目吗？精度和包大小的平衡点在哪？
3. 消费级GPU（RTX 4060）7×24跑7B推理模型，散热和驱动稳定性有坑吗？
4. 多租户「核心独立+边缘共享」的数据隔离方案，生产环境实际表现如何？