独立开发者全栈项目复盘一人维护 SaaS 的技术架构简化与运维自动化一、引言独立开发者的技术选型和团队开发有本质区别。团队可以分工协作前端、后端、运维各司其职而独立开发者必须一个人扛下所有。在这种约束下技术决策的关键词不是强大而是省心。过去两年维护了一个面向中小企业的 SaaS 产品——一个轻量级的团队协作工具月活用户约 2000付费用户 400。从技术架构到运维流程经历了三次重大简化每次简化都是对抗过度设计本能的过程。这篇文章复盘一人维护 SaaS 的技术架构优化经验。二、架构演进从重到轻的三次减负V1微服务架构——独立开发者的噩梦起步时犯的典型错误看了太多大厂的架构分享一上来就搞了 4 个微服务 Kafka 3 个独立数据库。结果是本地开发需要同时启动 8 个进程Docker Compose 启动一次要 5 分钟部署一次要更新 4 个服务镜像任何服务版本不兼容就挂一片排查问题需要在 4 个服务的日志里跳来跳去Kafka 挂了整个通知链路就断了而我经常忘记检查 Kafka 的健康状态一个人维护微服务的成本三个月后实在扛不住了。V2Modular Monolith——实用主义的回归重构为 Modular Monolith 后的 Go 项目结构// 项目目录结构 project/ ├── cmd/ │ └── server/ │ └── main.go // 唯一入口 ├── internal/ │ ├── user/ // 用户模块 │ │ ├── handler.go │ │ ├── service.go │ │ ├── repository.go │ │ └── model.go │ ├── project/ // 项目模块 │ ├── notification/ // 通知模块 │ ├── file/ // 文件模块 │ └── shared/ // 共享层 │ ├── middleware/ │ ├── database/ │ └── errors/ ├── web/ // 前端代码(Vue3) │ └── src/ ├── migrations/ ├── Dockerfile └── docker-compose.yml // 只需 3 个服务关键设计原则——模块间通过接口隔离但不通过网络隔离// internal/user/service.go package user type Service struct { repo Repository notifier Notifier // 依赖接口而非具体实现 fileStore FileStore } // 接口定义在消费方而非提供方 type Notifier interface { SendWelcome(ctx context.Context, userID int64) error } type FileStore interface { GetUploadURL(ctx context.Context, key string) (string, error) }// cmd/server/main.go // 所有模块在同一个进程中组装没有网络开销 func main() { db : database.Connect(cfg.DatabaseURL) redis : redis.NewClient(redis.Options{Addr: cfg.RedisAddr}) userRepo : user.NewRepository(db) notifSvc : notification.NewService(db, redis) fileStore : file.NewS3Store(cfg.S3Config) userSvc : user.NewService(userRepo, notifSvc, fileStore) projectSvc : project.NewService(db, userSvc) router : gin.Default() user.RegisterRoutes(router, userSvc) project.RegisterRoutes(router, projectSvc) router.Run(:8080) }核心收益开发一个go run启动全部服务5 秒就位部署一个二进制文件 一个配置文件部署脚本 20 行排查日志在一个地方grep一条命令就能追踪请求全链路数据库一个 PostgreSQL 实例备份恢复一条命令V3前端嵌入后端——极简的终极形态更进一步将 Vue3 前端构建产物嵌入到 Go 二进制中//go:embed web/dist/* var webAssets embed.FS func main() { // ... 模块初始化 ... // 生产环境嵌入静态文件 if cfg.Env production { router.Use(static.Serve(/, static.EmbedFolder(webAssets, web/dist))) } else { // 开发环境代理到 Vite Dev Server router.Use(proxy(/, http://localhost:5173)) } router.Run(:8080) }这个改造让部署变成了一行命令./server——没有 Nginx 配置、没有静态文件 CDN、没有跨域问题。对于一个 2000 月活的 SaaS足够了。三、运维自动化让机器做重复的事一人维护 SaaS最值钱的是时间最危险的是等出了问题再说。自动部署# .github/workflows/deploy.yml name: Deploy on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Build run: | cd web npm ci npm run build cd .. CGO_ENABLED0 go build -o server ./cmd/server - name: Deploy uses: appleboy/ssh-actionv1 with: host: ${{ secrets.SSH_HOST }} username: deploy key: ${{ secrets.SSH_KEY }} script: | systemctl stop myapp cp ${{ github.workspace }}/server /opt/myapp/server cp -r ${{ github.workspace }}/migrations /opt/myapp/ systemctl start myapp # 自动运行数据库迁移 /opt/myapp/server migrate # 健康检查 curl -f http://localhost:8080/health || systemctl restart myapp自动备份#!/bin/bash # scripts/backup.sh —— crontab 每日凌晨执行 BACKUP_DIR/backup/db RETENTION_DAYS30 # 数据库备份 pg_dump myapp $BACKUP_DIR/myapp_$(date %Y%m%d).sql # 压缩 gzip $BACKUP_DIR/myapp_$(date %Y%m%d).sql # 上传到 S3异地备份 aws s3 cp $BACKUP_DIR/myapp_$(date %Y%m%d).sql.gz \ s3://myapp-backups/db/$(date %Y%m)/ \ --storage-class STANDARD_IA # 清理本地过期备份 find $BACKUP_DIR -name *.sql.gz -mtime $RETENTION_DAYS -delete echo [$(date)] Backup completed自动监控// 内建健康检查 自动告警 func HealthCheckHandler(c *gin.Context) { checks : map[string]func() error{ database: checkDB, redis: checkRedis, disk: checkDiskSpace, s3: checkS3Connection, } results : make(map[string]string) healthy : true for name, check : range checks { if err : check(); err ! nil { results[name] fmt.Sprintf(unhealthy: %v, err) healthy false } else { results[name] healthy } } if !healthy { // 发送告警通知邮件 企业微信 sendAlert(Health check failed, results) c.JSON(http.StatusServiceUnavailable, results) return } c.JSON(http.StatusOK, results) }四、技术选型的经验法则几条独立开发者的技术选型法则法则说明反例单进程优先不到万不得已不加新服务一开始就上微服务托管服务优先能用 RDS 不自己装 MySQL自己维护数据库集群前后端同仓库一个 repo 管所有部署一条命令前端一个 repo 后端一个 repo数据库单实例2000 用户不需要读写分离为未来百万用户过度设计监控做减法只监控内存/CPU/磁盘/错误率上全套可观测性平台日志即文档关键操作的日志就是排查依据日志级别混乱关键信息缺失五、总结一个人维护 SaaS不必追求技术的前沿和架构的正统。实用主义才是生存法则跑得起来比设计得漂亮重要。微服务很美但一个人调不通 Kafka 的时候再美的架构都是负担。Modular Monolith 虽然不高级但它能让你专心做产品而不是修基础设施。自动化不是可选项是生存条件。部署自动化、备份自动化、监控自动化——每一项都能在关键时刻救你。这些自动化脚本一次性写好后几乎不需要维护但收益每天都在产生。做减法比做加法难。砍掉一个用不上的缓存层、合并两个可以共享的数据表、删除一段从来没人看的监控代码——这些减法操作需要判断力。但每次减法成功维护负担就轻一分。两年的独立开发者经验告诉我技术选型的最高境界不是用了多少新技术而是用最少的技术解决了问题还能睡个好觉。技术栈Go 1.22 Gin / Vue 3 Vite / PostgreSQL / Redis / Docker / GitHub Actions
独立开发者全栈项目复盘一人维护 SaaS 的技术架构简化与运维自动化一、引言独立开发者的技术选型和团队开发有本质区别。团队可以分工协作前端、后端、运维各司其职而独立开发者必须一个人扛下所有。在这种约束下技术决策的关键词不是强大而是省心。过去两年维护了一个面向中小企业的 SaaS 产品——一个轻量级的团队协作工具月活用户约 2000付费用户 400。从技术架构到运维流程经历了三次重大简化每次简化都是对抗过度设计本能的过程。这篇文章复盘一人维护 SaaS 的技术架构优化经验。二、架构演进从重到轻的三次减负V1微服务架构——独立开发者的噩梦起步时犯的典型错误看了太多大厂的架构分享一上来就搞了 4 个微服务 Kafka 3 个独立数据库。结果是本地开发需要同时启动 8 个进程Docker Compose 启动一次要 5 分钟部署一次要更新 4 个服务镜像任何服务版本不兼容就挂一片排查问题需要在 4 个服务的日志里跳来跳去Kafka 挂了整个通知链路就断了而我经常忘记检查 Kafka 的健康状态一个人维护微服务的成本三个月后实在扛不住了。V2Modular Monolith——实用主义的回归重构为 Modular Monolith 后的 Go 项目结构// 项目目录结构 project/ ├── cmd/ │ └── server/ │ └── main.go // 唯一入口 ├── internal/ │ ├── user/ // 用户模块 │ │ ├── handler.go │ │ ├── service.go │ │ ├── repository.go │ │ └── model.go │ ├── project/ // 项目模块 │ ├── notification/ // 通知模块 │ ├── file/ // 文件模块 │ └── shared/ // 共享层 │ ├── middleware/ │ ├── database/ │ └── errors/ ├── web/ // 前端代码(Vue3) │ └── src/ ├── migrations/ ├── Dockerfile └── docker-compose.yml // 只需 3 个服务关键设计原则——模块间通过接口隔离但不通过网络隔离// internal/user/service.go package user type Service struct { repo Repository notifier Notifier // 依赖接口而非具体实现 fileStore FileStore } // 接口定义在消费方而非提供方 type Notifier interface { SendWelcome(ctx context.Context, userID int64) error } type FileStore interface { GetUploadURL(ctx context.Context, key string) (string, error) }// cmd/server/main.go // 所有模块在同一个进程中组装没有网络开销 func main() { db : database.Connect(cfg.DatabaseURL) redis : redis.NewClient(redis.Options{Addr: cfg.RedisAddr}) userRepo : user.NewRepository(db) notifSvc : notification.NewService(db, redis) fileStore : file.NewS3Store(cfg.S3Config) userSvc : user.NewService(userRepo, notifSvc, fileStore) projectSvc : project.NewService(db, userSvc) router : gin.Default() user.RegisterRoutes(router, userSvc) project.RegisterRoutes(router, projectSvc) router.Run(:8080) }核心收益开发一个go run启动全部服务5 秒就位部署一个二进制文件 一个配置文件部署脚本 20 行排查日志在一个地方grep一条命令就能追踪请求全链路数据库一个 PostgreSQL 实例备份恢复一条命令V3前端嵌入后端——极简的终极形态更进一步将 Vue3 前端构建产物嵌入到 Go 二进制中//go:embed web/dist/* var webAssets embed.FS func main() { // ... 模块初始化 ... // 生产环境嵌入静态文件 if cfg.Env production { router.Use(static.Serve(/, static.EmbedFolder(webAssets, web/dist))) } else { // 开发环境代理到 Vite Dev Server router.Use(proxy(/, http://localhost:5173)) } router.Run(:8080) }这个改造让部署变成了一行命令./server——没有 Nginx 配置、没有静态文件 CDN、没有跨域问题。对于一个 2000 月活的 SaaS足够了。三、运维自动化让机器做重复的事一人维护 SaaS最值钱的是时间最危险的是等出了问题再说。自动部署# .github/workflows/deploy.yml name: Deploy on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Build run: | cd web npm ci npm run build cd .. CGO_ENABLED0 go build -o server ./cmd/server - name: Deploy uses: appleboy/ssh-actionv1 with: host: ${{ secrets.SSH_HOST }} username: deploy key: ${{ secrets.SSH_KEY }} script: | systemctl stop myapp cp ${{ github.workspace }}/server /opt/myapp/server cp -r ${{ github.workspace }}/migrations /opt/myapp/ systemctl start myapp # 自动运行数据库迁移 /opt/myapp/server migrate # 健康检查 curl -f http://localhost:8080/health || systemctl restart myapp自动备份#!/bin/bash # scripts/backup.sh —— crontab 每日凌晨执行 BACKUP_DIR/backup/db RETENTION_DAYS30 # 数据库备份 pg_dump myapp $BACKUP_DIR/myapp_$(date %Y%m%d).sql # 压缩 gzip $BACKUP_DIR/myapp_$(date %Y%m%d).sql # 上传到 S3异地备份 aws s3 cp $BACKUP_DIR/myapp_$(date %Y%m%d).sql.gz \ s3://myapp-backups/db/$(date %Y%m)/ \ --storage-class STANDARD_IA # 清理本地过期备份 find $BACKUP_DIR -name *.sql.gz -mtime $RETENTION_DAYS -delete echo [$(date)] Backup completed自动监控// 内建健康检查 自动告警 func HealthCheckHandler(c *gin.Context) { checks : map[string]func() error{ database: checkDB, redis: checkRedis, disk: checkDiskSpace, s3: checkS3Connection, } results : make(map[string]string) healthy : true for name, check : range checks { if err : check(); err ! nil { results[name] fmt.Sprintf(unhealthy: %v, err) healthy false } else { results[name] healthy } } if !healthy { // 发送告警通知邮件 企业微信 sendAlert(Health check failed, results) c.JSON(http.StatusServiceUnavailable, results) return } c.JSON(http.StatusOK, results) }四、技术选型的经验法则几条独立开发者的技术选型法则法则说明反例单进程优先不到万不得已不加新服务一开始就上微服务托管服务优先能用 RDS 不自己装 MySQL自己维护数据库集群前后端同仓库一个 repo 管所有部署一条命令前端一个 repo 后端一个 repo数据库单实例2000 用户不需要读写分离为未来百万用户过度设计监控做减法只监控内存/CPU/磁盘/错误率上全套可观测性平台日志即文档关键操作的日志就是排查依据日志级别混乱关键信息缺失五、总结一个人维护 SaaS不必追求技术的前沿和架构的正统。实用主义才是生存法则跑得起来比设计得漂亮重要。微服务很美但一个人调不通 Kafka 的时候再美的架构都是负担。Modular Monolith 虽然不高级但它能让你专心做产品而不是修基础设施。自动化不是可选项是生存条件。部署自动化、备份自动化、监控自动化——每一项都能在关键时刻救你。这些自动化脚本一次性写好后几乎不需要维护但收益每天都在产生。做减法比做加法难。砍掉一个用不上的缓存层、合并两个可以共享的数据表、删除一段从来没人看的监控代码——这些减法操作需要判断力。但每次减法成功维护负担就轻一分。两年的独立开发者经验告诉我技术选型的最高境界不是用了多少新技术而是用最少的技术解决了问题还能睡个好觉。技术栈Go 1.22 Gin / Vue 3 Vite / PostgreSQL / Redis / Docker / GitHub Actions
