定时任务【Elastic-job】
使用场景
- SASS系统的定时任务较多,使用三方组件集成
- 需要重试机制,可视化界面等需求
使用问题
- 类似于一个触发条件组件而已,不考虑执行后的结果
- 集成组件时考虑了负载均衡,并没有考虑业务单元
其他因素
- 业务代码编写逻辑,在集群中的单节点for循环处理业务
导致结果
- 在执行任务节点时间段内,系统资源【CPU与内存】飙升
- 在执行任务节点时间段内,如果有大业务处理时,服务器存在宕机风险
消息中间件【rocketMQ】
使用场景
- 上下游系统解耦,接收上游订单
- 同步改异步,导出
使用问题
- 根据消息体内容操作业务数据导致服务器宕机
导致结果
- 垃圾数据导致单节点宕机,mq消息不丢失机制重新下发垃圾数据,从而导致节点一个个掉线
分布式事务【seata】
使用场景
- 分布式框架,保证事务一致
导致结果
- 服务服务器宕机,导致产生垃圾数据
打印组件【JasperReports】
使用场景
- 各业务单据打印功能
使用问题
- 并没有深入该组件的源码,不知道会不会给系统带来性能上的问题
导致结果
- 打印属性填充值长度过大时,带来的性能开销很多,从而一点点拖垮服务器
系统特性
- 系统业务耦合度高,操作性强
- 业务为本,技术为辅
业务
- 有任务问题都需要业务操作的执行
技术
- 以技术驱动业务发展,不能以业务驱动技术迭代
- 如何通过架构设计,达到对系统业务最核心的要求?
- 怎么降低系统的复杂性?
初步想法
去除三方组件【seata】
调整服务划分逻辑【后续补充架构图】
- 核心服务【core-service】,即业务操作服务【本地事务】
- 大业务单元服务【big-businss-service】,如仓储行业的波次、盘点单的创建【本地事务】
- 数据对接服务【edi-service】,如仓储行业的上游下单、定时任务调用、三方组件驱动【本地事务】
- 报表服务【report-service】,系统内查询类报表【走从库,无事务】
好处
- 所有服务均可以操作数据库
- 报表服务可以配置从数据库【要求mysql是主从架构】
- 除了主业务服务之外任何服务有问题都不会影响主服务,主服务要求数据安全性较高,不在使用分布式事务
- 如果出现问题导致数据库服务压力过大,可以随时停止,以解决对业务的最小影响
坏处
- 需要投入较大改动成本
- 系统划分时需要有对业务较为清楚的理解