1. 项目概述同城家政小程序的商业价值与技术选型在同城生活服务领域家政服务一直保持着稳定的市场需求。最近两年我们团队用Java技术栈完整开发了一套自营家政小程序系统从接单派单到服务评价形成了闭环。选择Java作为主要开发语言主要基于三点考虑首先是Spring Boot生态对高并发场景的成熟支持其次是团队已有的Java技术积累最后是考虑到后期可能对接企业ERP系统时Java的兼容优势。这套系统目前已在三个城市实际运行日均订单量稳定在800-1200单。与市面上常见的第三方平台模式不同我们采用自营服务模式所有服务人员都是公司直聘员工这种模式虽然管理成本较高但服务质量可控性提升了47%客户投诉率降低了63%。2. 核心架构设计2.1 技术栈组成后端采用经典的Spring BootMyBatis组合Spring Boot 2.7.5保持与Java 17的兼容性MyBatis-Plus 3.5.2简化DAO层开发Redis 6.2缓存热点数据和分布式锁RabbitMQ 3.9异步处理订单状态变更MinIO存储服务前后对比照片前端小程序采用uni-app框架实现了微信、支付宝双端兼容。特别要说明的是我们没有选用现成的UI框架而是基于业务需求自定义了组件库这使得界面加载速度比市面同类产品快30%左右。2.2 微服务划分策略系统按业务域划分为六个微服务用户中心服务处理C端用户和B端管理员的鉴权订单服务核心业务逻辑所在调度服务基于地理位置的智能派单支付服务聚合微信、支付宝支付评价服务处理评分和投诉数据看板服务实时统计和报表这种划分方式在后期扩容时显现出优势——当订单量激增时我们可以单独对订单服务和调度服务进行横向扩展。3. 关键技术实现细节3.1 智能派单算法派单逻辑是整个系统的核心难点我们实现了三级派单策略public class DispatchStrategy { // 第一级基于服务人员技能标签匹配 public ListWorker filterBySkills(Order order) { // 实现细节... } // 第二级基于实时位置的距离计算 public ListWorker sortByDistance(ListWorker workers, Location clientLocation) { // 使用Redis GEO命令实现 } // 第三级基于负载均衡的最终分配 public Worker selectFinalWorker(ListWorker candidates) { // 考虑当前待处理订单数和服务评分 } }实际运行中这套算法使平均接单时间从25分钟缩短到8分钟。有个值得分享的细节最初我们使用MySQL计算距离当并发量超过500时数据库压力明显增大后来改用Redis的GEO功能后性能提升了7倍。3.2 订单状态机设计订单状态流转采用状态机模式实现public enum OrderState { UNPAID { public void pay(Order order) { /*...*/ } }, PAID { public void assignWorker(Order order) { /*...*/ } }, // 其他状态... } // 使用示例 order.getState().assignWorker(order);这种设计避免了复杂的if-else嵌套当业务方要求增加预约定金状态时我们只用了2小时就完成了扩展体现了良好的可维护性。4. 性能优化实践4.1 缓存策略我们采用多级缓存架构本地缓存Caffeine缓存用户基础信息等变化不频繁的数据Redis集群缓存服务项目价格、技师资料等MySQL作为最终数据持久层特别要注意的是缓存击穿问题。对于热门服务项目如空调清洗我们使用Redisson实现了分布式锁public ServiceDetail getServiceDetail(Long id) { String cacheKey service: id; ServiceDetail detail redisTemplate.opsForValue().get(cacheKey); if (detail null) { RLock lock redissonClient.getLock(lock: cacheKey); try { lock.lock(); // 双重检查 detail redisTemplate.opsForValue().get(cacheKey); if (detail null) { detail serviceDetailMapper.selectById(id); redisTemplate.opsForValue().set(cacheKey, detail, 1, TimeUnit.HOURS); } } finally { lock.unlock(); } } return detail; }4.2 数据库优化订单表采用了分库分表策略按城市分库北京、上海、广州三个库按月分表order_202301、order_202302等查询优化方面我们为常用查询建立了联合索引CREATE INDEX idx_order_search ON t_order (city_code, service_type, status, create_time);有个踩坑经验最初我们在status字段上单独建了索引但实际执行时MySQL优化器并没有使用后来改为联合索引后订单查询速度提升了15倍。5. 安全防护措施5.1 接口安全所有API接口都经过三重防护JWT鉴权使用RS256算法参数签名防止重放攻击敏感操作二次验证如短信验证码特别要注意的是支付回调接口的安全处理。我们实现了签名验证和白名单IP校验PostMapping(/pay/callback) public String callback(RequestBody String body, HttpServletRequest request) { // 验证IP白名单 if (!ipWhiteList.contains(request.getRemoteAddr())) { throw new SecurityException(非法IP); } // 验证签名 if (!signatureService.verify(body)) { throw new SecurityException(签名无效); } // 处理业务逻辑... }5.2 数据安全用户敏感信息如手机号、地址在数据库中全部采用AES加密存储。这里有个细节加密密钥不是硬编码在代码中而是通过KMS系统动态获取每次服务启动时刷新。6. 运维监控体系6.1 日志收集采用ELK栈实现日志集中管理使用Logstash的Grok插件解析Java日志在Kibana中建立了专门的订单看板关键错误日志通过企业微信机器人实时报警6.2 性能监控通过PrometheusGrafana监控系统关键指标JVM内存和GC情况接口响应时间P99MySQL连接池使用率Redis缓存命中率我们在Grafana中配置了智能预警规则当订单创建成功率低于99.9%时自动触发告警。7. 项目演进方向目前系统正在向三个方向迭代引入机器学习预测各区域订单量提前调度服务人员增加AR远程指导功能提升复杂服务的完成质量开发管理端APP让督导人员可以实时查看服务过程在架构层面我们正在试验将部分服务迁移到GraalVM原生镜像初步测试显示启动时间从6秒降低到了0.8秒这对应对突发流量很有帮助。