本文是「汽修 SaaS 开发连载」第 6 篇。前几篇讲了业务建模和并发控制这篇回头看地基技术栈怎么选的哪些判断对了哪些现在想改。先列约束再谈选型技术选型最怕上来就比框架评分表。我们先把汽修场景的硬约束摆出来选型是围绕这些约束做的门店网络不可靠。车间里手机信号时有时无收银和开单不能因为断网就停摆。写入集中在营业时段。白天工单、领料高频写入凌晨几乎没流量写入曲线非常陡。团队要养得活。我们是小团队选型必须考虑半年后招人能不能招到、社区资料多不多。客户数据敏感。车牌、手机号、消费记录都在库里SaaS 化之后数据安全没有退路。整体形态模块化单体不是微服务一开始团队里也有直接上微服务的声音理由是后面要做连锁和开放平台。我们最后选了模块化单体modular monolith按领域拆模块模块间只走接口调用┌─────────────────────────────────────────────┐ │ 应用层 │ │ PC 后台 API │ 技师 App API │ 小程序 API │ ├─────────────────────────────────────────────┤ │ order │ inventory │ archive │ member │ ... │ ← 领域模块接口隔离 ├─────────────────────────────────────────────┤ │ 共享基础设施 │ │ 认证鉴权 / 消息队列 / 对象存储 / 定时任务 │ └─────────────────────────────────────────────┘理由写在这里供同样规模的团队参考多租户 SaaS 的复杂度在数据隔离和权限不在服务拆分。第一阶段就把运维拆成十几个服务等于把人力从业务功能挪去搭基础设施客户看不到任何东西。微服务该拆的时候比如后面报表和实时业务分库再拆单体的模块边界拆清楚迁出去是顺手的边界混乱的微服务往回收才是灾难。主力组件和选它的理由层选型关键理由现在的评价后端框架Spring Boot团队熟事务和生态省事对没换的理由数据库MySQLInnoDB事务强一致是进销存的刚需对领料扣减依赖行锁和条件更新缓存Redis会话、权限缓存、号段发号对消息队列RabbitMQ工单事件广播进度推送、凭证生成起步量级足够量再涨可能换暂不折腾对象存储云 OSS维修照片视频量大但访问低频对注意配好生命周期降冷前端 PCVue Element Plus后台表单密集型页面组件全对技师端微信小程序口袋工具免安装车间扫码即用半对见下文部署云主机 Docker Compose单客户版本迭代快P3 连锁阶段大概率要迁 K8s一个当时没想清楚的选型技师端技师端我们最初在原生 App和小程序之间犹豫最后选了小程序图的是免安装、发链接就能用。上线后两个真实反馈好的一面推广成本确实低。让一个五十岁的钣金师傅装 App 很难让他扫个码用小程序教会只要两分钟。问题的一面车间弱网下小程序的体验比预期差页面白屏时技师不知道是没网还是卡了。我们后来做了两层补救工单列表和待办做本地缓存断网可看关键操作报完工、领料失败时有明确提示和自动重试。原生 App 的离线能力更强但配套的推送、更新、多端发布成本对我们来说现阶段不划算。这个决定以后可能推翻先记在这里。数据库里最值钱的一个设计决定选型文章一般不谈这个但它比框架选择重要我们从第一版就把tenant_id 写进了所有业务表哪怕单店版根本用不上。之前做别的项目吃过亏单租户系统改多租户全表加字段加索引历史数据回填前后折腾了一个多月。这次每个建表语句都带 tenant_id查询拦截器自动拼租户条件。代价是几乎为零收益在 P3 连锁阶段兑现。有个细节tenant_id 相关的索引必须放在联合索引最左否则拦截器拼上条件后全表扫描。这条我们是在压测时发现的一个没带 tenant_id 前缀的查询在 30 万行工单表上慢查询告警。复盘两处现在会改的消息队列上得太早。初期事件量小用 Spring 事件 本地表轮询完全够RabbitMQ 的运维成本镜像队列、告警配置前三个月基本是纯负担。报表一开始就独立数据源。这个反而是对的忍住了先共用业务库的诱惑后来写 BI 那篇会展开。选型没有标准答案约束不同答案就不同。如果你也在做类似的多门店 SaaS欢迎评论区聊聊你们的团队规模和栈。下一篇开始进连锁架构系列多租户数据隔离怎么做到门店只看本店总部可穿透。「汽修 SaaS 开发连载」· 06 / 05 领料扣库存的并发问题实战 · 04 单车利润需求让表结构推倒重来
本文是「汽修 SaaS 开发连载」第 6 篇。前几篇讲了业务建模和并发控制这篇回头看地基技术栈怎么选的哪些判断对了哪些现在想改。先列约束再谈选型技术选型最怕上来就比框架评分表。我们先把汽修场景的硬约束摆出来选型是围绕这些约束做的门店网络不可靠。车间里手机信号时有时无收银和开单不能因为断网就停摆。写入集中在营业时段。白天工单、领料高频写入凌晨几乎没流量写入曲线非常陡。团队要养得活。我们是小团队选型必须考虑半年后招人能不能招到、社区资料多不多。客户数据敏感。车牌、手机号、消费记录都在库里SaaS 化之后数据安全没有退路。整体形态模块化单体不是微服务一开始团队里也有直接上微服务的声音理由是后面要做连锁和开放平台。我们最后选了模块化单体modular monolith按领域拆模块模块间只走接口调用┌─────────────────────────────────────────────┐ │ 应用层 │ │ PC 后台 API │ 技师 App API │ 小程序 API │ ├─────────────────────────────────────────────┤ │ order │ inventory │ archive │ member │ ... │ ← 领域模块接口隔离 ├─────────────────────────────────────────────┤ │ 共享基础设施 │ │ 认证鉴权 / 消息队列 / 对象存储 / 定时任务 │ └─────────────────────────────────────────────┘理由写在这里供同样规模的团队参考多租户 SaaS 的复杂度在数据隔离和权限不在服务拆分。第一阶段就把运维拆成十几个服务等于把人力从业务功能挪去搭基础设施客户看不到任何东西。微服务该拆的时候比如后面报表和实时业务分库再拆单体的模块边界拆清楚迁出去是顺手的边界混乱的微服务往回收才是灾难。主力组件和选它的理由层选型关键理由现在的评价后端框架Spring Boot团队熟事务和生态省事对没换的理由数据库MySQLInnoDB事务强一致是进销存的刚需对领料扣减依赖行锁和条件更新缓存Redis会话、权限缓存、号段发号对消息队列RabbitMQ工单事件广播进度推送、凭证生成起步量级足够量再涨可能换暂不折腾对象存储云 OSS维修照片视频量大但访问低频对注意配好生命周期降冷前端 PCVue Element Plus后台表单密集型页面组件全对技师端微信小程序口袋工具免安装车间扫码即用半对见下文部署云主机 Docker Compose单客户版本迭代快P3 连锁阶段大概率要迁 K8s一个当时没想清楚的选型技师端技师端我们最初在原生 App和小程序之间犹豫最后选了小程序图的是免安装、发链接就能用。上线后两个真实反馈好的一面推广成本确实低。让一个五十岁的钣金师傅装 App 很难让他扫个码用小程序教会只要两分钟。问题的一面车间弱网下小程序的体验比预期差页面白屏时技师不知道是没网还是卡了。我们后来做了两层补救工单列表和待办做本地缓存断网可看关键操作报完工、领料失败时有明确提示和自动重试。原生 App 的离线能力更强但配套的推送、更新、多端发布成本对我们来说现阶段不划算。这个决定以后可能推翻先记在这里。数据库里最值钱的一个设计决定选型文章一般不谈这个但它比框架选择重要我们从第一版就把tenant_id 写进了所有业务表哪怕单店版根本用不上。之前做别的项目吃过亏单租户系统改多租户全表加字段加索引历史数据回填前后折腾了一个多月。这次每个建表语句都带 tenant_id查询拦截器自动拼租户条件。代价是几乎为零收益在 P3 连锁阶段兑现。有个细节tenant_id 相关的索引必须放在联合索引最左否则拦截器拼上条件后全表扫描。这条我们是在压测时发现的一个没带 tenant_id 前缀的查询在 30 万行工单表上慢查询告警。复盘两处现在会改的消息队列上得太早。初期事件量小用 Spring 事件 本地表轮询完全够RabbitMQ 的运维成本镜像队列、告警配置前三个月基本是纯负担。报表一开始就独立数据源。这个反而是对的忍住了先共用业务库的诱惑后来写 BI 那篇会展开。选型没有标准答案约束不同答案就不同。如果你也在做类似的多门店 SaaS欢迎评论区聊聊你们的团队规模和栈。下一篇开始进连锁架构系列多租户数据隔离怎么做到门店只看本店总部可穿透。「汽修 SaaS 开发连载」· 06 / 05 领料扣库存的并发问题实战 · 04 单车利润需求让表结构推倒重来
