家政派单通常面临多角色协作、多业务模式混合、同城实时调度三大难点。基于规则引擎的智能派单系统本质是将派单业务规则从代码中解耦通过可配置的条件-动作模型统一处理人工指派、师傅抢单、系统自动派单等场景。本文将结合多个家政服务平台的通用实践从订单模型、规则建模、派单策略、状态机、效果评估五个维度给出可直接落地的设计方法与代码示例。家政派单的业务场景与订单模型分析市面上的家政O2O系统普遍包含用户端、师傅端、商家端和管理端四个角色入口并支持小程序、App、公众号与H5多端访问。从业务模式看派单相关的任务类型可以归纳为三种定价制任务平台或商家设定固定薪酬师傅看单抢单或由系统直接指派。竞价制任务用户发布需求多位师傅在规定时间内参与竞争用户或平台根据条件选择合适人选。悬赏制任务用户悬赏发布师傅主动报名平台可结合规则辅助筛选。在设计订单模型时上述模式可以通过一个dispatch_type字段区分同时保留统一的订单主体结构。推荐使用如下核心表设计task_order - id - user_id -- 用户id - dispatch_type -- 1 定价制 2 竞价制 3 悬赏制 - status -- 初始状态待接单 - address -- 服务地址含经纬度 - expected_time -- 期望服务时间 - extra_requirements -- 用户备注/个性化需求 - created_at派单系统面向的是同城场景因此经纬度与距离计算是后续规则执行的基础数据。建议在设计阶段对address字段做反向地理编码冗余存一份lat、lng避免规则引擎实时调用地图服务造成性能损耗。规则引擎的选择与规则建模方法规则引擎并非必须引入Drools、Easy Rules等重型框架。对于家政派单这种业务规则变动频繁、但并发量中等的场景使用轻量级规则引擎 数据库规则配置通常性价比更高。核心思想是将规则抽象为“条件-动作”对由规则引擎统一加载、匹配与执行。一个通用的派单规则模型可以这样设计publicclassDispatchRule{privateStringruleId;privateStringconditionExpression;// 如distance 5 score 90privateStringactionType;// ASSIGN / NOTIFY / SUGGESTprivateStringtargetUserId;// 当actionType为ASSIGN时生效privateintpriority;// 规则优先级}规则引擎执行流程如下加载所有启用状态的规则到本地缓存。根据当前订单上下文距离、时间、订单类型、师傅评分等构造事实Fact对象。按优先级排序逐条匹配规则。匹配成功则执行对应动作记录命中日志。若存在多个匹配规则通过优先级和规则业务语义决定终动作。// 伪代码示例publicvoiddispatch(TaskOrderorder){RuleContextcontextnewRuleContext(order);ListDispatchRulerulesruleLoader.loadEnabledRules();rules.sort(Comparator.comparing(DispatchRule::getPriority));for(DispatchRulerule:rules){if(expressionEvaluator.evaluate(rule.getConditionExpression(),context)){RuleActionExecutor.execute(rule.getActionType(),rule.getTargetUserId(),order);logDispatcherHit(rule.getRuleId(),order.getId());break;// 只执行条命中规则}}}该方案的优势在于新增派单策略时只需在规则配置表中添加记录不需要修改服务端代码也便于商家端和管理端在后台进行可视化配置。派单策略核心规则编排与服务评分算法家政派单不同于网约车师傅通常具备一定的服务半径偏好和技能标签。因此智能派单不能只依赖“近距离”策略至少需要组合距离、评分、接单率、技能匹配度、活跃时间五个因子。一种实践方法是将规则引擎与评分算法结合规则引擎负责硬性条件过滤如距离、技能评分算法负责对满足条件的师傅进行排序。师傅得分 距离分(30%) 综合评分(25%) 接单率(20%) 技能匹配(15%) 活跃度(10%)距离分可以通过maxDistance归一化计算publicdoubledistanceScore(doubledistance,doublemaxDistance){returnMath.max(0,1-distance/maxDistance);}技能匹配需要引入师傅技能标签与订单服务项的对齐逻辑。比如订单要求“空调清洗”那么拥有该技能标签的师傅在该维度得满分没有则为0。规则引擎在评分前过滤掉没有对应技能的师傅如果该服务项下师傅数量极少可以通过规则配置降级策略扩大到相邻技能品类。派单结果建议通过WebSocket或推送网关实时通知师傅端同时给予师傅一定时间窗口如30秒确认。若确认超时系统自动切换至候补列表这一处理逻辑也由规则引擎驱动确保规则统一。订单状态机与超时回收机制家政派单全流程涉及多个状态变更直接使用if-else容易造成状态不可控。推荐使用有限状态机State Machine管理订单状态流转。常见状态定义PENDING - ASSIGNED - ACCEPTED - IN_PROGRESS - COMPLETED PENDING - CANCELLED ASSIGNED - TIMEOUT - PENDING ACCEPTED - CANCELLED其中ASSIGNED状态需要格外关注。系统指派后师傅未确认超过指定时间必须触发超时回收。一种务实做法是通过延迟消息队列实现超时检测而不是依赖定时扫描数据库。// Spring Boot RabbitMQ 延迟队列示例RabbitListener(queuesorder.timeout.queue)publicvoidhandleAssignTimeout(LongorderId){TaskOrderorderorderService.getById(orderId);if(order.getStatus()OrderStatus.ASSIGNED){DispatchRuletimeoutRuleruleEngine.matchRule(ASSIGN_TIMEOUT_RECYCLE);executeRule(timeoutRule,order);}}状态机的核心价值在于所有状态变更收敛到统一入口便于记录流转日志。结合规则引擎可以实现更丰富的业务策略例如同一个师傅连续拒绝3次后系统自动降低该师傅的派单优先级订单等待超过5分钟无人接单自动扩大派单半径。这些都属于规则配置不需要改动核心代码。数据埋点与派单效果评估规则引擎布置完成后需要建立一套针对派单质量的评估指标体系。建议至少关注以下指标接单率师傅点击接单次数 /派单总次数平均响应时长从派单到师傅确认的时间间隔用户取消率派单后、服务开始前用户主动取消的比例订单完成率终完成服务的订单占已支付订单的比例师傅平均评分反映服务质量的长期指标每次派单决策都应打印结构化日志包含订单ID、规则ID、候选师傅列表、得分排序、终命中结果。这些日志一方面用于复盘派单规则合理性另一方面可以基于历史数据离线调整评分算法权重。对于家政派单平台建议预留A/B测试空间。例如新规则先应用于小流量订单观察接单率是否显著优于旧规则。规则引擎天然适合灰度发布只需在规则配置表中增加is_gray标志位即可实现。针对同城多商户场景派单规则还需要区分商户维度和平台维度。商户自有师傅优先派单、商户之间不允许跨店接单等约束都应抽象为规则参数避免在业务代码中写死。从开源家政系统的实践经验看这种将业务规则收敛到配置中心的架构能够显著降低后续多商户入驻时的派单逻辑维护成本。FAQ问家政派单系统必须引入Drools之类重型规则引擎吗不需要。家政派单的规则数量一般不超过几百条并发量也远低于电商秒杀场景。使用轻量级表达式引擎如QLExpress、Aviator加上数据库配置即可满足需求同时避免引入过于复杂的依赖。问如何避免师傅挑单导致用户长时间无人接单可以将“近N次拒绝派单”作为规则条件连续拒绝达到阈值后系统自动降低该师傅的派单优先级同时轮换触发“扩大派单半径”“提升悬赏权重”等补偿策略。这类逻辑用规则引擎配置非常灵活。问师傅接单率低问题可能出现在哪些环节先看接单率指标是否在合理区间再回溯派单日志。常见原因包括派单半径设置过小、评分权重不合理、师傅技能标签不准确或者通知渠道延迟严重。可以通过查看同一地域、同一时段的历史订单日志定位具体瓶颈。
家政派单通常面临多角色协作、多业务模式混合、同城实时调度三大难点。基于规则引擎的智能派单系统本质是将派单业务规则从代码中解耦通过可配置的条件-动作模型统一处理人工指派、师傅抢单、系统自动派单等场景。本文将结合多个家政服务平台的通用实践从订单模型、规则建模、派单策略、状态机、效果评估五个维度给出可直接落地的设计方法与代码示例。家政派单的业务场景与订单模型分析市面上的家政O2O系统普遍包含用户端、师傅端、商家端和管理端四个角色入口并支持小程序、App、公众号与H5多端访问。从业务模式看派单相关的任务类型可以归纳为三种定价制任务平台或商家设定固定薪酬师傅看单抢单或由系统直接指派。竞价制任务用户发布需求多位师傅在规定时间内参与竞争用户或平台根据条件选择合适人选。悬赏制任务用户悬赏发布师傅主动报名平台可结合规则辅助筛选。在设计订单模型时上述模式可以通过一个dispatch_type字段区分同时保留统一的订单主体结构。推荐使用如下核心表设计task_order - id - user_id -- 用户id - dispatch_type -- 1 定价制 2 竞价制 3 悬赏制 - status -- 初始状态待接单 - address -- 服务地址含经纬度 - expected_time -- 期望服务时间 - extra_requirements -- 用户备注/个性化需求 - created_at派单系统面向的是同城场景因此经纬度与距离计算是后续规则执行的基础数据。建议在设计阶段对address字段做反向地理编码冗余存一份lat、lng避免规则引擎实时调用地图服务造成性能损耗。规则引擎的选择与规则建模方法规则引擎并非必须引入Drools、Easy Rules等重型框架。对于家政派单这种业务规则变动频繁、但并发量中等的场景使用轻量级规则引擎 数据库规则配置通常性价比更高。核心思想是将规则抽象为“条件-动作”对由规则引擎统一加载、匹配与执行。一个通用的派单规则模型可以这样设计publicclassDispatchRule{privateStringruleId;privateStringconditionExpression;// 如distance 5 score 90privateStringactionType;// ASSIGN / NOTIFY / SUGGESTprivateStringtargetUserId;// 当actionType为ASSIGN时生效privateintpriority;// 规则优先级}规则引擎执行流程如下加载所有启用状态的规则到本地缓存。根据当前订单上下文距离、时间、订单类型、师傅评分等构造事实Fact对象。按优先级排序逐条匹配规则。匹配成功则执行对应动作记录命中日志。若存在多个匹配规则通过优先级和规则业务语义决定终动作。// 伪代码示例publicvoiddispatch(TaskOrderorder){RuleContextcontextnewRuleContext(order);ListDispatchRulerulesruleLoader.loadEnabledRules();rules.sort(Comparator.comparing(DispatchRule::getPriority));for(DispatchRulerule:rules){if(expressionEvaluator.evaluate(rule.getConditionExpression(),context)){RuleActionExecutor.execute(rule.getActionType(),rule.getTargetUserId(),order);logDispatcherHit(rule.getRuleId(),order.getId());break;// 只执行条命中规则}}}该方案的优势在于新增派单策略时只需在规则配置表中添加记录不需要修改服务端代码也便于商家端和管理端在后台进行可视化配置。派单策略核心规则编排与服务评分算法家政派单不同于网约车师傅通常具备一定的服务半径偏好和技能标签。因此智能派单不能只依赖“近距离”策略至少需要组合距离、评分、接单率、技能匹配度、活跃时间五个因子。一种实践方法是将规则引擎与评分算法结合规则引擎负责硬性条件过滤如距离、技能评分算法负责对满足条件的师傅进行排序。师傅得分 距离分(30%) 综合评分(25%) 接单率(20%) 技能匹配(15%) 活跃度(10%)距离分可以通过maxDistance归一化计算publicdoubledistanceScore(doubledistance,doublemaxDistance){returnMath.max(0,1-distance/maxDistance);}技能匹配需要引入师傅技能标签与订单服务项的对齐逻辑。比如订单要求“空调清洗”那么拥有该技能标签的师傅在该维度得满分没有则为0。规则引擎在评分前过滤掉没有对应技能的师傅如果该服务项下师傅数量极少可以通过规则配置降级策略扩大到相邻技能品类。派单结果建议通过WebSocket或推送网关实时通知师傅端同时给予师傅一定时间窗口如30秒确认。若确认超时系统自动切换至候补列表这一处理逻辑也由规则引擎驱动确保规则统一。订单状态机与超时回收机制家政派单全流程涉及多个状态变更直接使用if-else容易造成状态不可控。推荐使用有限状态机State Machine管理订单状态流转。常见状态定义PENDING - ASSIGNED - ACCEPTED - IN_PROGRESS - COMPLETED PENDING - CANCELLED ASSIGNED - TIMEOUT - PENDING ACCEPTED - CANCELLED其中ASSIGNED状态需要格外关注。系统指派后师傅未确认超过指定时间必须触发超时回收。一种务实做法是通过延迟消息队列实现超时检测而不是依赖定时扫描数据库。// Spring Boot RabbitMQ 延迟队列示例RabbitListener(queuesorder.timeout.queue)publicvoidhandleAssignTimeout(LongorderId){TaskOrderorderorderService.getById(orderId);if(order.getStatus()OrderStatus.ASSIGNED){DispatchRuletimeoutRuleruleEngine.matchRule(ASSIGN_TIMEOUT_RECYCLE);executeRule(timeoutRule,order);}}状态机的核心价值在于所有状态变更收敛到统一入口便于记录流转日志。结合规则引擎可以实现更丰富的业务策略例如同一个师傅连续拒绝3次后系统自动降低该师傅的派单优先级订单等待超过5分钟无人接单自动扩大派单半径。这些都属于规则配置不需要改动核心代码。数据埋点与派单效果评估规则引擎布置完成后需要建立一套针对派单质量的评估指标体系。建议至少关注以下指标接单率师傅点击接单次数 /派单总次数平均响应时长从派单到师傅确认的时间间隔用户取消率派单后、服务开始前用户主动取消的比例订单完成率终完成服务的订单占已支付订单的比例师傅平均评分反映服务质量的长期指标每次派单决策都应打印结构化日志包含订单ID、规则ID、候选师傅列表、得分排序、终命中结果。这些日志一方面用于复盘派单规则合理性另一方面可以基于历史数据离线调整评分算法权重。对于家政派单平台建议预留A/B测试空间。例如新规则先应用于小流量订单观察接单率是否显著优于旧规则。规则引擎天然适合灰度发布只需在规则配置表中增加is_gray标志位即可实现。针对同城多商户场景派单规则还需要区分商户维度和平台维度。商户自有师傅优先派单、商户之间不允许跨店接单等约束都应抽象为规则参数避免在业务代码中写死。从开源家政系统的实践经验看这种将业务规则收敛到配置中心的架构能够显著降低后续多商户入驻时的派单逻辑维护成本。FAQ问家政派单系统必须引入Drools之类重型规则引擎吗不需要。家政派单的规则数量一般不超过几百条并发量也远低于电商秒杀场景。使用轻量级表达式引擎如QLExpress、Aviator加上数据库配置即可满足需求同时避免引入过于复杂的依赖。问如何避免师傅挑单导致用户长时间无人接单可以将“近N次拒绝派单”作为规则条件连续拒绝达到阈值后系统自动降低该师傅的派单优先级同时轮换触发“扩大派单半径”“提升悬赏权重”等补偿策略。这类逻辑用规则引擎配置非常灵活。问师傅接单率低问题可能出现在哪些环节先看接单率指标是否在合理区间再回溯派单日志。常见原因包括派单半径设置过小、评分权重不合理、师傅技能标签不准确或者通知渠道延迟严重。可以通过查看同一地域、同一时段的历史订单日志定位具体瓶颈。
