标签派单系统架构设计

需求描述

项目背景

1. 根据员工历史成单情况，计算员工对不同类型工单的转化能力。
2. 根据员工和工单标签匹配进行派单。

业务流程图

规则描述

每10分钟，分城进行一次派单，派单规则可能会动态删减，需要支持动态配置

工单标签说明

员工标签计算方式

1. BI每月统计员工标签
2. 员工历史成单情况，每个二级标签排名前40%的人，会有该标签
3. 每个员工，一级标签，自排序，取第一个，例如： 性别一级标签， 张三，接女性的单，大于男性，就给张三，服务女性标签

派单规则

工单类过滤,都满足才通过

• 工单时效性, 工单超时判断
• 工单合法性,工单是否是未派单状态

员工类过滤：都满足才通过

• 员工，日/月工单上限
• 员工，开工状态校验
• 门店，日/月工单上限
• 员工，工单价值匹配
• 等10余条规则

排序： 员工接单量排序

架构设计

明确需求，找出复杂度

需求描述基本满足编码要求，但是对于架构设计，还是不够的。还需依据需求，多次沟通，判断质量复杂度，业务复杂度

业务复杂度方面，规则多，逻辑多，且未来2年内变化较大，业务复杂度较高。

质量复杂度方面（高性能，高可用，成本，安全等），需要与产品尽可能沟通，明确。

首先关注的是业务量，业务量越大，对高性能要求越大。历史数据表明，日均1W单。最高1min 200单，属于高性能要求较低。

其次关注业务容忍度，影响高可用，公司规定派单系业务故障时间不能超过1min

然后关注成本部分，公司没有特殊要求

最后考虑，安全等问题，这需求不涉及法律法规，公司规定，这里忽略。

通盘考虑，可以判断出， 标签派单系统， 业务复杂度高，质量复杂度较低

根据设计复杂度模型，找出大致架构设计方向

设计复杂度模型

组内人员介绍，派单组3个人，都是java后端开发，公司以由完善的微服务架构

根据复杂度判断结果，依据设计复杂度模型，考虑组内人员情况，公司架构情况，得出架构大致方向：

可扩展方面： 采用微服务架构

高性能，高可用方面： 采用集群+负载均衡

拆解，取舍，细化架构

可扩展设计

架构可扩展设计

微服务拆分，理论上：

  -  3个人维护一个迭代中的系统，1个人维护3个处于维护期的系统。-  一次调用不超过5个系统

但是考虑到派单，规则变化较大，封装变化，适度扩展。

拆分的微服务如下：

• receive_wait_order 接受待派工单， 分城查询待派工单，开发后基本不变
• dispatch 派单，变化较大
• score 员工标签配置服务，开发后基本不变。
• record 记录派单结果，事实统计，为报表提供底层数据

代码可扩展设计

派单系统，规则多，未来变化大，这里采用规则引擎，降低复杂度。

规则引擎对比

结合团队情况 ，大家都是Java后端开发，公司已有配置中心，根据 合适，简单，演进 原则，选择liteFlow，结合已有配置中心。

高性能，高可用设计

日均1W单。最高1min 200单，一次派单预计0.8s，业务需求每10分钟按城市派1轮，推导出，性能要求不高，可接受一定时延，不超过10min分钟

采用任务分解模式，按城市分片，

利用已有消息队列kafka，receive_wait_order 每10分钟发送派单消息， 消息体为：需要派单的城市

一次派单预计耗时0.8s，单台dispatch 派单QPS 1.25， 3台dispatch QPM 225，满足业务需求

3台dispatch 同一个消费组进行消费，来实现按城市分片派单。

其他服务没有高性能要求，但又高可用要求，均选择2台。

存储设计

结构化数据，采用Mysql 存储，大多数表数据量较小，不用特殊处理

但是派单结果表 1天1W单，1年365W ，未来场景考虑， 派单结果表采用 按年分表

分表采用Sharding-JDBC ，SDK嵌入record项目无需考虑高性能，高可用

最终结构图

• receive_wait_order 接受待派工单， 分城查询待派工单，开发后基本不变
• dispatch 派单，变化较大
• score 员工标签配置服务，开发后基本不变
• record 记录派单结果，事实统计，为报表提供底层数据

业务架构图

系统架构图