三方组件导致系统宕机的架构设计思考

定时任务【Elastic-job】

使用场景

• SASS系统的定时任务较多，使用三方组件集成
• 需要重试机制，可视化界面等需求

使用问题

• 类似于一个触发条件组件而已，不考虑执行后的结果
• 集成组件时考虑了负载均衡，并没有考虑业务单元

其他因素

• 业务代码编写逻辑，在集群中的单节点for循环处理业务

导致结果

• 在执行任务节点时间段内，系统资源【CPU与内存】飙升
• 在执行任务节点时间段内，如果有大业务处理时，服务器存在宕机风险

消息中间件【rocketMQ】

使用场景

• 上下游系统解耦，接收上游订单
• 同步改异步，导出

使用问题

• 根据消息体内容操作业务数据导致服务器宕机

导致结果

• 垃圾数据导致单节点宕机，mq消息不丢失机制重新下发垃圾数据，从而导致节点一个个掉线

分布式事务【seata】

使用场景

• 分布式框架，保证事务一致

导致结果

• 服务服务器宕机，导致产生垃圾数据

打印组件【JasperReports】

使用场景

• 各业务单据打印功能

使用问题

• 并没有深入该组件的源码，不知道会不会给系统带来性能上的问题

导致结果

• 打印属性填充值长度过大时，带来的性能开销很多，从而一点点拖垮服务器

系统特性

• 系统业务耦合度高，操作性强
• 业务为本，技术为辅

业务

• 有任务问题都需要业务操作的执行

技术

• 以技术驱动业务发展，不能以业务驱动技术迭代
• 如何通过架构设计，达到对系统业务最核心的要求？
• 怎么降低系统的复杂性？

初步想法

去除三方组件【seata】

调整服务划分逻辑【后续补充架构图】

• 核心服务【core-service】，即业务操作服务【本地事务】
• 大业务单元服务【big-businss-service】，如仓储行业的波次、盘点单的创建【本地事务】
• 数据对接服务【edi-service】，如仓储行业的上游下单、定时任务调用、三方组件驱动【本地事务】
• 报表服务【report-service】，系统内查询类报表【走从库，无事务】

好处

• 所有服务均可以操作数据库
• 报表服务可以配置从数据库【要求mysql是主从架构】
• 除了主业务服务之外任何服务有问题都不会影响主服务，主服务要求数据安全性较高，不在使用分布式事务
• 如果出现问题导致数据库服务压力过大，可以随时停止，以解决对业务的最小影响

坏处

• 需要投入较大改动成本
• 系统划分时需要有对业务较为清楚的理解