同城家政小程序技术架构与智能派单实践

1. 同城家政小程序的技术选型与架构设计

作为一名长期从事本地生活服务类应用开发的工程师，我发现同城家政服务类小程序的技术架构需要同时兼顾高并发、实时性和业务复杂性。基于SpringBoot+MyBatisPlus+MySQL的技术栈选择，实际上是在多年项目迭代中验证过的可靠方案。

1.1 后端技术栈的深度考量

SpringBoot的选用绝非偶然。在家政服务场景中，服务人员的上下班状态切换、订单状态的实时更新等都需要高频的接口调用。我们实测发现，SpringBoot的内嵌Tomcat容器在4核8G的服务器上，可以稳定支撑每秒800+的并发请求，这对于早晚高峰的订单爆发非常关键。

MyBatisPlus相比原生MyBatis的优势在于：

• 内置的Lambda表达式写法让多表联查代码量减少40%
• 自动分页插件完美适配管理后台的数据展示需求
• 代码生成器可以快速产出订单、服务人员等核心模块的CRUD代码

实际开发中发现，将MySQL的隔离级别设置为READ-COMMITTED，配合MyBatisPlus的@Version乐观锁注解，可以完美解决家政服务中常见的"订单重复接单"问题。

1.2 前端跨端方案的选择

Uniapp的跨端能力确实能节省成本，但需要特别注意：

1. 微信小程序端的分包加载策略必须优化，否则首次加载速度会超过2秒
2. APP端的地图组件需要单独处理，不能直接使用小程序的地图API
3. H5版本要特别注意支付流程的兼容性处理

我们在项目中采用了"核心代码共用，特殊逻辑分端实现"的策略：

• 公共业务逻辑放在common目录
• 各端差异通过条件编译处理

javascript复制// #ifdef MP-WEIXIN
wx.requestPayment(...)
// #endif
// #ifdef APP-PLUS
uni.requestPayment(...)
// #endif

2. 智能派单系统的实现细节

2.1 规则引擎的设计原理

智能派单的核心是多重过滤规则的有序执行：

1. 地理围栏过滤：先筛选3公里内的服务人员（MySQL空间索引优化）
2. 服务能力过滤：匹配服务标签（如"深度保洁"、"宠物友好"）
3. 时间窗口过滤：排除已排满的时间段
4. 信用等级过滤：优先派给评分4.8以上的服务者

java复制// 实际项目中的复合查询示例
List<Worker> workers = workerMapper.selectList(
    Wrappers.<Worker>query()
        .eq("service_type", order.getServiceType())
        .apply("ST_Distance_Sphere(point({0},{1}), point(longitude,latitude)) < {2}", 
               order.getLng(), order.getLat(), 3000)
        .gt("credit_score", 4.5)
        .orderByAsc("current_order_count")
);

2.2 机器学习模型的渐进式接入

初期可以先用规则引擎，但数据量超过1万单后就应该引入机器学习。我们的实施路径是：

1. 第一阶段：基于历史订单的简单统计（如A阿姨接保洁单完成率92%）
2. 第二阶段：加入用户画像特征（某用户经常给"细致程度"打低分）
3. 第三阶段：实时反馈调整（某服务者近期3单均超时）

关键技巧：模型预测结果需要与规则引擎加权融合，我们采用7:3的权重比例，既保持稳定性又具备学习能力。

3. 实时定位与路径优化的工程实践

3.1 高德地图API的深度集成

地图集成中最容易踩的坑：

• 坐标系不统一（小程序用GCJ-02，后台用WGS84）
• 静态地图快照生成时的并发限制
• 路径规划时的成本计算（要考虑服务者的交通工具）

我们封装了统一的MapUtils工具类处理这些问题：

java复制public class MapUtils {
    private static final ExecutorService executor = Executors.newFixedThreadPool(10);
    
    public static CompletableFuture<RoutePlan> asyncRoutePlan(LatLng origin, LatLng dest) {
        return CompletableFuture.supplyAsync(() -> {
            // 实际调用高德API的逻辑
            return amapClient.routePlan(origin, dest);
        }, executor);
    }
}

3.2 服务者轨迹的压缩算法

为了节省流量和存储空间，我们采用了Douglas-Peucker算法对轨迹点进行压缩：

java复制public List<LatLng> compressTrack(List<LatLng> points, double tolerance) {
    if (points.size() < 3) return points;
    
    int maxIndex = 0;
    double maxDistance = 0;
    
    // 找出偏离最大的点
    for (int i = 1; i < points.size() - 1; i++) {
        double distance = perpendicularDistance(
            points.get(i), 
            points.get(0), 
            points.get(points.size()-1)
        );
        if (distance > maxDistance) {
            maxDistance = distance;
            maxIndex = i;
        }
    }
    
    // 递归处理
    if (maxDistance > tolerance) {
        List<LatLng> left = compressTrack(points.subList(0, maxIndex+1), tolerance);
        List<LatLng> right = compressTrack(points.subList(maxIndex, points.size()), tolerance);
        return Stream.concat(left.stream(), right.stream().skip(1))
                   .collect(Collectors.toList());
    } else {
        return Arrays.asList(points.get(0), points.get(points.size()-1));
    }
}

实测可以将轨迹数据体积减少70%以上，同时保留关键路径点。

4. 订单状态机的设计与实现

家政服务的订单状态流转比电商复杂得多，我们定义了11种状态和28种转换规则：

4.1 状态枚举设计

java复制public enum OrderStatus {
    PENDING_PAY,     // 待支付
    PAID,           // 已支付
    WAITING_DISPATCH, // 待派单
    DISPATCHED,     // 已派单
    ACCEPTED,       // 已接单
    ARRIVED,        // 已到达
    SERVICING,      // 服务中
    WAITING_CHECK,  // 待验收
    COMPLETED,      // 已完成
    CANCELLED,      // 已取消
    AFTER_SALES     // 售后中
}

4.2 状态转换的防护措施

使用状态模式避免非法跳转：

java复制public class OrderStateMachine {
    private OrderState currentState;
    
    public void toNextStatus(OrderEvent event) {
        currentState.handle(this, event);
    }
    
    // 各状态的具体实现
    private class DispatchedState implements OrderState {
        @Override
        public void handle(OrderStateMachine machine, OrderEvent event) {
            if (event == OrderEvent.WORKER_ACCEPT) {
                machine.setState(new AcceptedState());
            } else {
                throw new IllegalStateException("非法状态转换");
            }
        }
    }
}

5. 性能优化实战记录

5.1 MySQL索引优化方案

经过慢查询分析，我们为订单表设计了复合索引：

sql复制ALTER TABLE `orders` ADD INDEX `idx_area_service` (
    `city_code`, 
    `district_code`,
    `service_type`,
    `status`
);

配合MyBatisPlus的动态表名拦截器，实现按城市分表查询。

5.2 Redis缓存设计要点

我们采用多级缓存策略：

1. 第一层：本地缓存（Caffeine） - 缓存服务者基础信息
2. 第二层：Redis集群 - 缓存热门服务类型的可用工作者列表
3. 第三层：Redis布隆过滤器 - 快速判断某个服务者是否在线

缓存更新策略采用"被动失效+定时刷新"双机制：

java复制@CacheEvict(value = "workers", key = "#workerId")
public void updateWorkerStatus(Long workerId, Status status) {
    // 更新数据库
}

@Scheduled(fixedRate = 10_000)
public void refreshHotWorkers() {
    // 每10秒刷新热门区域的服务者缓存
}

6. 安全防护的实战经验

6.1 支付环节的防重放攻击

我们采用"随机字符串+时间戳"签名方案：

1. 前端生成nonce_str（16位随机字符串）
2. 拼接timestamp（精确到秒）
3. 使用HMAC-SHA256生成签名

java复制public String generateSign(String nonce, long timestamp, String secret) {
    String content = nonce + "|" + timestamp;
    return HmacUtils.hmacSha256Hex(secret, content);
}

6.2 敏感数据的脱敏处理

在Jackson序列化时自动脱敏：

java复制@JsonSerialize(using = SensitiveSerializer.class)
public class UserDTO {
    @Sensitive(type = SensitiveType.MOBILE)
    private String mobile;
}

public class SensitiveSerializer extends JsonSerializer<String> {
    @Override
    public void serialize(String value, JsonGenerator gen, SerializerProvider provider) {
        // 手机号显示为138****1234
        gen.writeString(value.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2"));
    }
}

7. 运维监控体系的建设

7.1 基于Prometheus的监控方案

我们在SpringBoot中暴露的关键指标：

• 订单创建速率（orders_created_total）
• 派单延迟（dispatch_latency_seconds）
• 服务者在线率（workers_online_ratio）

Grafana监控看板配置示例：

yaml复制- expr: rate(orders_created_total[5m])
  record: instance:orders:rate5m
- expr: histogram_quantile(0.95, sum(rate(dispatch_latency_seconds_bucket[5m])) by (le))
  record: instance:dispatch:latency95

7.2 日志收集的实践技巧

采用ELK方案时需要注意：

1. 为每个订单设置唯一traceId贯穿全链路
2. 敏感信息在日志输出前必须脱敏
3. 控制单条日志体积，超过10KB的转为附件存储

Logback的配置优化：

xml复制<appender name="ELK" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <filter class="com.xxx.SensitiveLogFilter"/>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <maxFileSize>50MB</maxFileSize>
        <maxHistory>30</maxHistory>
    </rollingPolicy>
</appender>

在项目上线后，我们通过渐进式迭代将系统稳定性从99.5%提升到了99.95%。关键经验是：初期不要过度设计，但要为扩展留好接口；所有核心流程必须有降级方案；监控指标要面向业务而不仅是技术层面。