需求描述
项目背景
- 根据员工历史成单情况，计算员工对不同类型工单的转化能力。
- 根据员工和工单标签匹配进行派单。
业务流程图
规则描述
每10分钟，分城进行一次派单，派单规则可能会动态删减，需要支持动态配置
工单标签说明
| 一级标签 | 二级标签 |
|---|---|
| 客户性别 | 男>女 |
| 客户性格 | 温和>冷漠>急躁 |
| 客户属性 | 严谨>社会 |
| 客户年龄 | 20+> 30+> 40+> 50+> 60+ |
| 客户学历 | 初中> 高中> 大专> 大学> 硕士> 博士 |
员工标签计算方式
- BI每月统计员工标签
- 员工历史成单情况，每个二级标签排名前40%的人，会有该标签
- 每个员工，一级标签，自排序，取第一个，例如： 性别一级标签， 张三，接女性的单，大于男性，就给张三，服务女性标签
派单规则
工单类过滤,都满足才通过
- 工单时效性, 工单超时判断
- 工单合法性,工单是否是未派单状态
员工类过滤：都满足才通过
- 员工，日/月工单上限
- 员工，开工状态校验
- 门店，日/月工单上限
- 员工，工单价值匹配
- 等10余条规则
排序： 员工接单量排序
架构设计
明确需求，找出复杂度
需求描述基本满足编码要求，但是对于架构设计，还是不够的。还需依据需求，多次沟通，判断质量复杂度，业务复杂度
业务复杂度方面，规则多，逻辑多，且未来2年内变化较大，业务复杂度较高。
质量复杂度方面（高性能，高可用，成本，安全等），需要与产品尽可能沟通，明确。
首先关注的是业务量，业务量越大，对高性能要求越大。历史数据表明，日均1W单。最高1min 200单，属于高性能要求较低。
其次关注业务容忍度，影响高可用，公司规定派单系业务故障时间不能超过1min
然后关注成本部分，公司没有特殊要求
最后考虑，安全等问题，这需求不涉及法律法规，公司规定，这里忽略。
通盘考虑，可以判断出， 标签派单系统， 业务复杂度高，质量复杂度较低
根据设计复杂度模型，找出大致架构设计方向
设计复杂度模型
组内人员介绍，派单组3个人，都是java后端开发，公司以由完善的微服务架构
根据复杂度判断结果，依据设计复杂度模型，考虑组内人员情况，公司架构情况，得出架构大致方向：
可扩展方面： 采用微服务架构
高性能，高可用方面： 采用集群+负载均衡
拆解，取舍，细化架构
可扩展设计
架构可扩展设计
微服务拆分，理论上：
- 3个人维护一个迭代中的系统，1个人维护3个处于维护期的系统。
- 一次调用不超过5个系统
但是考虑到派单，规则变化较大，封装变化，适度扩展。
拆分的微服务如下：
- receive_wait_order 接受待派工单， 分城查询待派工单，开发后基本不变
- dispatch 派单，变化较大
- score 员工标签配置服务，开发后基本不变。
- record 记录派单结果，事实统计，为报表提供底层数据
代码可扩展设计
派单系统，规则多，未来变化大，这里采用规则引擎，降低复杂度。
规则引擎对比
| 规则引擎 | 优点 | 缺点 |
|---|---|---|
| drools | 成熟度高，大公司开发 | 需要花时间掌握，成本高 |
| liteFlow | 支持，多种逻辑关系，xml或yml配置，支持配置中心热更新,掌握成本低 | 没有界面，需要xml等配置 |
| ice | 支持，多种逻辑关系，有精美界面 | 单独部署,如果二次开发，需要前端技能 |
结合团队情况 ，大家都是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 记录派单结果，事实统计，为报表提供底层数据
业务架构图
系统架构图
