需求描述
项目背景
- 根据员工历史成单情况,计算员工对不同类型工单的转化能力。
- 根据员工和工单标签匹配进行派单。
业务流程图
规则描述
每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 记录派单结果,事实统计,为报表提供底层数据