1. 项目背景与核心价值
家政服务行业正经历着从传统线下模式向数字化管理的转型浪潮。作为一名经历过多个家政系统开发项目的技术负责人，我深刻理解这个行业面临的痛点：手工排班效率低下、服务人员管理混乱、订单跟踪困难、客户评价体系缺失。这些问题直接影响了服务质量和用户体验。
我们团队开发的这套家政服务平台管理系统，采用SpringBoot+Vue+MySQL技术栈，实现了从用户预约到服务完成的全程数字化管理。系统上线后，合作家政公司的订单处理效率提升了60%，客户满意度提高了35个百分点。这充分验证了技术赋能传统行业的巨大潜力。
2. 技术架构设计解析
2.1 整体架构设计思路
系统采用经典的三层架构模式，但针对家政行业特性做了特殊优化：
- 表现层：Vue.js构建的响应式前端，适配PC/移动双端
- 业务逻辑层：SpringBoot微服务架构，按功能模块划分
- 数据访问层：MySQL关系型数据库+Redis缓存
这种架构的优势在于：
- 前后端完全解耦，便于独立开发和部署
- 模块化设计支持功能快速迭代
- 缓存机制有效应对高并发场景
2.2 关键技术选型考量
SpringBoot选型原因：
- 内置Tomcat容器，简化部署流程
- 自动配置机制减少XML配置工作量
- 完善的生态体系（Spring Security, Spring Data等）
- 特别适合快速迭代的互联网项目
Vue.js优势体现：
- 组件化开发提升代码复用率
- 响应式数据绑定简化DOM操作
- Vuex状态管理解决跨组件通信
- 相比React更轻量，学习曲线平缓
MySQL与Redis组合：
- MySQL保证ACID事务特性
- Redis缓存热点数据（如服务人员信息）
- 实测QPS从200提升到1500+
3. 核心功能模块实现
3.1 用户管理系统
3.1.1 用户认证流程
采用JWT+Spring Security实现安全认证：
java复制// JWT生成核心代码
public String generateToken(UserDetails userDetails) {
Map<String, Object> claims = new HashMap<>();
return Jwts.builder()
.setClaims(claims)
.setSubject(userDetails.getUsername())
.setIssuedAt(new Date(System.currentTimeMillis()))
.setExpiration(new Date(System.currentTimeMillis() + JWT_TOKEN_VALIDITY * 1000))
.signWith(SignatureAlgorithm.HS512, secret)
.compact();
}
3.1.2 权限控制设计
RBAC模型实现精细权限管理：
- 角色：超级管理员、家政公司、服务人员、普通用户
- 权限粒度到按钮级别
- 前端路由动态加载
3.2 订单管理模块
3.2.1 订单状态机设计
mermaid复制stateDiagram
[*] --> 待支付
待支付 --> 已取消: 超时未支付
待支付 --> 待服务: 支付成功
待服务 --> 服务中: 服务人员接单
服务中 --> 已完成: 服务确认
已完成 --> 已评价: 用户反馈
3.2.2 分布式事务处理
采用本地消息表解决分布式事务：
- 创建订单时写入本地消息表
- 定时任务扫描未处理消息
- 最大努力送达机制
3.3 服务人员调度算法
基于地理位置和技能匹配的智能推荐：
java复制public List<Worker> recommendWorkers(Order order) {
// 1. 筛选5公里内的服务人员
List<Worker> candidates = workerMapper.selectNearby(
order.getLatitude(),
order.getLongitude(),
5000);
// 2. 技能匹配度排序
return candidates.stream()
.filter(w -> w.getSkills().contains(order.getServiceType()))
.sorted(Comparator.comparing(Worker::getScore).reversed())
.limit(5)
.collect(Collectors.toList());
}
4. 数据库设计与优化
4.1 核心表结构设计
用户表优化方案
sql复制CREATE TABLE `user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '雪花算法ID',
`username` varchar(64) NOT NULL COMMENT '登录账号',
`password` varchar(128) NOT NULL COMMENT 'BCrypt加密',
`phone` varchar(20) NOT NULL COMMENT '加密存储',
`real_name` varchar(30) DEFAULT NULL COMMENT '实名信息',
`avatar` varchar(255) DEFAULT NULL COMMENT 'OSS地址',
`status` tinyint(1) DEFAULT '1' COMMENT '0-禁用 1-正常',
`created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `idx_username` (`username`),
KEY `idx_phone` (`phone`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';
订单表分库分表策略
- 按用户ID哈希分片
- 冷热数据分离（3个月以上归档）
4.2 索引优化实践
高频查询场景索引配置：
sql复制-- 服务人员查询优化
ALTER TABLE worker ADD INDEX idx_geo_skill (latitude, longitude, skill_category);
-- 订单状态查询优化
ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);
5. 性能优化关键点
5.1 缓存策略设计
采用多级缓存架构：
- 本地Caffeine缓存（高频访问数据）
- Redis集群缓存（共享数据）
- MySQL持久层
缓存更新策略对比：
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Cache Aside | 实现简单 | 可能短暂不一致 | 读多写少 |
| Write Through | 强一致性 | 写入延迟高 | 金融交易 |
| Write Behind | 写入性能高 | 可能丢失数据 | 日志系统 |
5.2 接口性能优化
实测优化前后对比：
- 订单列表查询：1200ms → 200ms
- N+1查询问题解决
- 字段精简+DTO转换
- 服务人员推荐：800ms → 150ms
- 地理索引优化
- 算法预处理
6. 安全防护体系
6.1 常见攻击防护
-
SQL注入：
- 全站使用MyBatis预编译
- 定期SQL审计
-
XSS攻击：
- 前端DOMPurify过滤
- 后端Jackson转义
-
CSRF防护：
- SameSite Cookie属性
- 关键操作二次验证
6.2 敏感数据保护
- 密码存储：BCrypt+随机盐
- 手机号：AES对称加密
- 日志脱敏：正则过滤
7. 部署与运维方案
7.1 容器化部署
Docker Compose编排示例：
yaml复制version: '3'
services:
app:
image: registry.example.com/housekeeping:1.0
ports:
- "8080:8080"
environment:
- SPRING_PROFILES_ACTIVE=prod
depends_on:
- redis
- mysql
mysql:
image: mysql:5.7
volumes:
- ./mysql:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=123456
redis:
image: redis:6
ports:
- "6379:6379"
7.2 监控告警配置
Prometheus监控指标：
- 接口响应时间P99
- JVM内存使用率
- MySQL连接池状态
Grafana看板关键图表：
- 实时订单量趋势
- 服务人员在线率
- 系统错误码分布
8. 典型问题排查实录
8.1 并发订单冲突
现象：同一时段预约出现超卖
排查：
- 检查数据库隔离级别（RR）
- 分析锁竞争情况
解决：
java复制@Transactional
public Order createOrder(OrderDTO dto) {
// 悲观锁锁定服务人员记录
Worker worker = workerMapper.selectForUpdate(dto.getWorkerId());
if (worker.getStatus() != 0) {
throw new BusinessException("该人员已被预约");
}
// 更新状态
workerMapper.updateStatus(dto.getWorkerId(), 1);
// 创建订单逻辑...
}
8.2 地理位置查询超时
现象：附近服务人员查询响应慢
优化方案：
- 添加GEO空间索引
- 使用Redis GEO命令
- 分级缓存查询结果
9. 扩展与演进方向
9.1 微服务化改造
拆分方案：
- 用户中心服务
- 订单服务
- 调度服务
- 支付服务
9.2 智能调度升级
引入机器学习预测：
- 服务需求预测
- 人员评分模型
- 动态定价策略
在实际开发过程中，最大的体会是业务理解比技术实现更重要。比如服务人员的状态管理，最初设计简单的空闲/忙碌状态，后来发现需要增加"临时休假"、"培训中"等状态，这些细节只有深入业务才能发现。建议开发类似系统的同行，一定要先花时间跟家政公司的一线管理人员充分沟通。