黑龙江网上建设局报建网站,企业信用不良记录查询,服务商名称是什么意思,设计公司网站欣赏需求描述
项目背景
根据员工历史成单情况#xff0c;计算员工对不同类型工单的转化能力。根据员工和工单标签匹配进行派单。
业务流程图 规则描述
每10分钟#xff0c;分城进行一次派单#xff0c;派单规则可能会动态删减#xff0c;需要支持动态配置
工单标签说明
一…需求描述
项目背景
根据员工历史成单情况计算员工对不同类型工单的转化能力。根据员工和工单标签匹配进行派单。
业务流程图 规则描述
每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分钟
采用任务分解模式按城市分片
利用已有消息队列kafkareceive_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 记录派单结果事实统计为报表提供底层数据
业务架构图 系统架构图
