当前位置: 首页 > news >正文

标签派单系统架构设计

需求描述

项目背景

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

业务流程图

规则描述

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

工单标签说明

一级标签二级标签
客户性别男>女
客户性格温和>冷漠>急躁
客户属性严谨>社会
客户年龄20+> 30+> 40+> 50+> 60+
客户学历初中> 高中> 大专> 大学> 硕士> 博士

员工标签计算方式

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

派单规则

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

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

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

  • 员工,日/月工单上限
  • 员工,开工状态校验
  • 门店,日/月工单上限
  • 员工,工单价值匹配
  • 等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 记录派单结果,事实统计,为报表提供底层数据

业务架构图

系统架构图

http://www.lryc.cn/news/89856.html

相关文章:

  • Jmeter和Postman那个工具更适合做接口测试?
  • k8s污点与容忍
  • 市面上有哪些软件可以结合agentgpt的?众包平台结合的好处!
  • 【js】对象属性的拦截和Proxy代理与Reflect映射的用法与区别
  • Yolov8涨点神器:ODConv+ConvNeXt提升小目标检测能力
  • git代码回滚是使用reset还是revert
  • 深入理解Java ThreadLocal及其内存泄漏防范
  • 介绍10款ChatGPT替代产品
  • 数字逻辑 期末
  • MT4交易外汇平台有哪些优势?为何是外汇投资首选?
  • 问卷调查工具实力榜单发布
  • javascript中property和attribute有什么区别?
  • 快速上手kettle
  • Leetcode 399. 除法求值
  • kotlin协程并发/并行与串行互相切换,CoroutineScope与await
  • 初识linux之简单了解TCP协议与UDP协议
  • 【String——简单使用】
  • Python下Taobao封装API接口的优势
  • LeetCode 49 字母异位词分组
  • ( 链表) 142. 环形链表 II——【Leetcode每日一题】
  • 论文解读 | 基于改进点对特征的点云6D姿态估计
  • Shell脚本while循环语句应用
  • Kubernetes Dashboard + Ingress 及其 yaml 文件分析
  • 【SpringCloud组件——Nacos】
  • pinia状态管理 用法
  • Oracle客户端版本安装
  • 基于Android studio二手车交易系统app
  • 【LCD应用编程】绘制点、线、矩形框
  • 第八篇、基于Arduino uno,获取MAX30102心率传感器的心率信息——结果导向
  • 【MySQL】MySQL主从同步延迟原因与解决方案