系列第二篇 | 上篇：10万创业狗不狗？从996到999，四个程序员裸辞做外卖返利小程序的血汗逆袭史
上一篇聊了为什么裸辞做外卖，收到很多朋友私信问技术选型。这篇纯技术向——聊聊我们如何基于开源项目，在30天内从零搭建出一个能跑通的外卖返现MVP。
作为团队唯一的架构师，胸中总有一团莫名其妙的优越感，至少技术心态上，要占用最好的架构。
外卖本质和电商没有什么区别，就是送得更快，更烫或更冷。
一句话概括：**没钱、没时间、没有前端，但必须做出来，相当外卖小哥，没有电摩，方便面没有调料，但外卖还得顶硬伤，顶硬上
一、背景与约束
如何多快好省，隐藏一个前段情况下，造成100亿越南盾这个小目标，我们列了下可行性：
| 约束项 | 具体情况 |
|---|---|
| 团队 | 4个后端（Java方向），前端能力一般，刚开始没有专职前端 |
| 预算 | 总共10万，刨去生活费和运营费用，技术投入几乎为零 |
| 时间 | 30天内必须上线MVP，拿到第一批真实用户反馈 |
| 产品形态 | 微信小程序（C端）+ 管理后台（商户端 & 运营端） |
在这个前提下，"从零自研"是不可能的。我们的策略从一开始就很明确——找成熟的开源项目做基座，把精力集中在业务层。
二、技术选型：我们是怎么选的
2.1 选型原则
团队内部讨论后，定了三条朴素原则（穷（：
- 技术栈必须团队全员能上手——不追新，不炫技，用我们最熟的，就像外卖小哥的电摩，选爱玛....不要高大上的YAMAHA
- 能用开源就用开源——后台框架、UI组件、工具库，能站在别人肩膀上就不自己造，能租电就别充电，时间就是效率
- 先跑通再优化——MVP阶段不做过度设计，但核心模块（订单、支付）不能留坑，最好车也是二手的，如果用朋友圈借的那种更佳
2.2 后端选型：likeadmin_java
我们对后端管理框架的需求很明确：
- 完整的用户体系和RBAC权限管理
- 前后端分离，后台管理界面能直接用
- 代码结构规范，方便在此基础上扩展业务模块
- 技术栈主流，出了问题能快速排查
在Gitee上筛了一圈之后，最终选了likeadmin_java。核心原因：
<TEXT>
✅ Spring Boot 2.x + MyBatis Plus —— 团队所有人都是Java出身，闭眼能写
✅ 后台前端是 Vue3 + Element Plus —— 现成的管理界面，省掉大量页面开发
✅ 自带代码生成器 —— 数据库表建好后，CRUD代码一键生成，效率极高
✅ 用户管理、角色权限、文件上传、系统配置等基础模块全部开箱即用
✅ 代码质量尚可，结构清晰，不是那种无法维护的祖传项目
一个判断标准： 我们估算了一下，如果这些基础模块自己写，至少需要2-3周。用likeadmin，这部分时间直接省掉，可以全部投入到业务开发上。
为什么没选若依？ 不为别的，就因为我们采用的外卖返现前端小程序wm-bwc-uniapp使用的后端程序也是 likeadmin 同一家公司的，只是是 PHP 版本，这样我们改成 SpringBoot 版本工作量也少些。
2.3 前端选型：uni-app + 外卖模板
模板项目地址：gitee.com/shenlailai/…
C端选微信小程序没有悬念——外卖返现是高频刚需场景，用户不会为了点个外卖专门下一个App。小程序的"用完即走"和微信社交裂变能力正好契合。
框架选了uni-app，主要考虑：
- 团队会一点Vue，上手成本最低
- 万一后期要做H5或App，可以跨端复用
- 生态相对成熟，社区资源多
关于外卖模板，我们在Gitee上找到了 wm-bwc-uniapp 这个项目。它是一套基于uni-app的外卖小程序前端模板，包含了首页、商户列表、商户详情、订单流程、个人中心等核心页面的UI骨架。
原先小程序：
改造后：
需要强调的是：这个模板我们只用了它的页面结构和部分UI参考，业务逻辑几乎全部重写。 原因后面会详细说。
2.4 整体技术架构
最终确定的技术全景：
<TEXT>
┌─────────────────────────────────────────────┐
│ 技术全景图 │
├─────────────────────────────────────────────┤
│ │
│ 🖥️ 管理后台（商户+运营） │
│ └── likeadmin_java（开源后台框架） │
│ ├── Spring Boot 3.x │
│ ├── MyBatis Plus │
│ ├── Vue3 + Element Plus（前端） │
│ ├── Redis │
│ └── MySQL 8.0（阿里云RDS） │
│ │
│ 📱 用户端（微信小程序） │
│ └── 基于uni-app外卖模板二次开发 │
│ ├── uni-app（Vue3版本） │
│ │
│ 🔗 中间件 & 基础设施 │
│ ├── Nginx（反向代理） │
│ ├── 阿里云ECS │
│ ├── 微信支付 │
│ ├── 阿里云 OSS（图片存储） │
│ └── orion-ops（应用构建发布平台） │
│ └── clk-log（用户行为分析） │
│ └── nginx-web-ui（nginx可视化配置工具） │
│ │
└─────────────────────────────────────────────┘
年服务器成本大概在10000-15000元左右（服务器+OSS+短信），超出了我们的预算（因为我们还要部署 clklog、测试环境、正式环境，Java程序吃内存啊），为此我们还和产品吵了一架，在产品眼中，验证MVP，2核4G的ECS一年 2000不就搞定了？
三、后端搭建过程
3.1 likeadmin_java 的基础能力
部署完likeadmin_java后，我们直接获得了这些能力：
- 系统管理： 管理员账号、角色权限、菜单管理、操作日志
- 基础功能： 文件上传、系统配置、字典管理、定时任务
- 开发工具： 代码生成器、API文档（Swagger）
- 后台前端： 完整的Vue3管理界面，登录、布局、菜单导航全部可用
这些我们一行代码没写，直接拿来用。
3.2 业务模块开发
在likeadmin基础上，我们优化了模块：
<JAVA>
// 我们新增的业务模块结构
├── bwc-common // 公共模块
├── bwc-integration // 三方对接模块（对接美团、淘宝闪购联盟）
├── bwc-service // 核心业务逻辑，主要集中订单系统和返利模块
├── bwc-task // 定时任务调度
├── bwc-api // API接口
│ ├── bwc-api-user //用户端API接口
│ ├── bwc-api-merchant //商家端API接口
│ └── bwc-api-admin //后台端接口
其中，bwc-service 中 订单系统和返利模块是我们投入精力最多的两个模块。
四、运维与工具链
这部分是很多技术文章容易忽略的，但对于小团队来说，运维效率直接影响迭代速度。
除了业务系统本身，我们还引入了三个开源运维工具，分别解决不同阶段的实际问题：
4.1 orion-ops — 应用构建与发布平台
解决的问题： 早期每次发布版本，都要手动SSH登录服务器，执行一堆脚本：停服务、备份Jar包、上传新包、重启、检查日志……整个流程至少10-15分钟，而且容易出错。
引入之后：
- 在 orion-ops 上配置好应用环境和发布流程，之后每次发版只需要在Web界面点一个按钮
- 支持一键回滚，上线出问题可以快速回退到上一个版本，不需要手忙脚乱找备份
- 发布过程有完整的日志记录，每次谁发的、发了什么版本、结果如何，一目了然
- 多环境管理清晰，测试环境和生产环境配置分开，不会误操作
对于我们这种没有专职运维的小团队来说，orion-ops 把"发版"这件事的心智负担降低了很多。 研发同学不需要关心服务器细节，专注写代码就好。
4.2 nginx-web-ui — Nginx 可视化配置工具
解决的问题： 我们的服务器上跑着多个服务——后台管理系统、用户端API、图片上传服务等，全部通过 Nginx 做反向代理。每次需要修改 Nginx 配置（比如新增一个域名、调整SSL证书、修改代理规则），都需要手动编辑 nginx.conf，改完还要执行 nginx -t 验证再 reload。
配置文件写错一个字符就会导致所有服务不可用，这种风险在深夜紧急修复的时候尤其大。
引入 nginx-web-ui 之后：
- 通过 Web 界面可视化管理所有 Nginx 配置，不需要手动编辑配置文件
- 配置修改后一键验证，语法有问题会直接提示，不会出现改完直接 reload 导致服务中断的情况
- SSL 证书管理更直观，到期提醒和续期操作都在界面上完成
- 多个站点的反向代理规则一目了然，维护起来不容易出错
<TEXT>
【没有 nginx-web-ui 时的操作流程】
SSH 登录服务器 → vim /etc/nginx/conf.d/xxx.conf → 手动编辑
→ nginx -t 验证 → 有错误反复改 → nginx -s reload → 检查是否生效
预计耗时：10~20分钟（出错的话更长）
【有 nginx-web-ui 之后的操作流程】
打开浏览器 → 进入 Web 管理界面 → 修改对应配置项 → 点击保存并生效
预计耗时：2~3分钟
对于没有专职运维、开发和运维一肩挑的小团队，这类工具能有效降低操作失误的概率。能用界面操作的事，就不要手写配置文件。
4.3 clk-log — 用户行为分析平台
它是做什么的：
clk-log 是一套可私有化部署的用户行为分析平台。简单来说，就是你自己搭一套"百度统计"或"友盟"，用户在小程序上的所有关键行为——浏览了哪个商户、在哪一步放弃下单、哪个菜品被看了最多但没有加入购物车——都可以通过埋点上报、实时采集、可视化呈现。
它能提供的核心能力：
- 转化漏斗分析：从"进入商户详情"到"支付完成"，每个环节的流失率清清楚楚
- 用户路径追踪：用户在小程序内的操作路径可回溯，找产品问题有数据支撑
- 自定义埋点事件：加入购物车、发起支付、邀请好友等关键行为，自定义上报，灵活度高
- 数据完全私有化：不上传任何第三方平台，数据安全和合规都有保障
- 实时可查：不需要等T+1，行为数据实时入库，实时出报表
对于做产品迭代来说，这类数据是判断优化方向最直接的依据。与其靠猜用户在哪里流失，不如用数据说话。
clk-log 是一套独立的数据分析服务，背后依赖的基础设施不轻——至少需要单独一台服务器来跑分析服务，加上数据存储（ClickHouse 或 MySQL），内存和磁盘的消耗都不小。
我们目前的情况是：全部服务跑在一台 16核32G 的 ECS 上，这台机器还部署了其他服务。
这台机器同时承载着：
<TEXT>
├── 用户端 API 服务
├── 商户后台 + 运营后台
├── 定时任务
├── Redis
├── Nginx
├── Nginx-Web-UI
├── orion-ops
└── 测试环境
在这个现状下，如果再把 clk-log 的分析服务塞进来，内存基本上直接打满，其他服务的稳定性都会受到影响。为了用户行为分析把主业务搞崩，得不偿失。
MVP 阶段我们对数据分析的替代方案是：
- 关键业务节点（下单、支付、退款）的日志全部落库，数据保留完整
- 微信小程序官方的"数据助手"能提供基础的UV/PV和页面访问统计，够用
- 等用户量到一定规模、服务器资源扩容之后，再单独部署一套行为分析服务
这是一个"知道有更好的方案、但当下资源不支持"的典型取舍。 做MVP最重要的是活下来，工具和基础设施随着业务规模逐步补齐就好。后续我们会在规划里先把 clk-log 的部署去除，先找其他免费的替代方案。
一句话总结这个判断：活下去最重要。
