记一次架构演变

image

架构的演变往往都是循序渐进的一个过程,没有哪一个架构一开始就是完美无缺的,今天就给大家介绍一个实际项目架构演变案例,通过这个实际案例的分享,跟大家一起来亲身经历架构演变的过程,希望大家能够有所收获。

业务背景

需要定期获取亚马逊平台的商家业务数据,然后存入我们自己数据库中,最后通过Saas平台将业务数据展现给商家。

业务要点:
  1. 需要定期获取亚马逊业务数据
  2. 需要将亚马逊业务数据存入数据库中

因为需要定期执行任务,所以这边我们需要一个任务调度框架。这边我们可以用xxl-job分布式调度框架来实现。架构图如下所示:

image

xxl-job分布式调度框架有兴趣的童鞋,可以去学习学习,它是一个很强大的分布式任务调度框架,给我们提供了很多强大的功能,而且还提供了一个admin任务管理中心。

绑定商家过多

随着绑定商家越来越多,任务执行耗时越来越长,执行完任务可能需要十几分钟,任务执行过长一方面会导致线程奔溃,另一方面也会导致数据延迟。

拆分任务:

不再统一一次性获取所有商家数据,以商家维度批量创建任务来获取商家业务数据,这样就可以并发的获取所有商家的业务数据。

线程任务过多

随着绑定的商家进一步增多,采用现有方案也逐渐出现问题。

问题:
  1. 任务线程过多导致内存溢出
  2. 任务线程消费情况很难统计
  3. 无法控制任务线程消费速度

为了避免上诉问题,我们可以引入MQ,架构如下所示:

image

去除之前的一个商家就是一个任务的模式,采用一个任务来统一推送所有商家数据到MQ中,然后在消息消费服务中进行亚马逊业务数据获取和入库操作。这样我们就可以有效的控制消费,也不会导致内存溢出的情况发生了。

大量慢SQL出现

随着绑定商家的再一步增多,数据库操作出现大量的慢SQL。

因为亚马逊业务数据获取完毕之后直接插入数据库就会导致数据插入不均衡,因为有些商家数据量大,有些商家数据量小,所以导致数据库性能没有得到充分的利用。

因为没有统一入库,所以可能会存在锁的情况发生。

为了解决这种问题,我们可以引入redis来进行数据统一入库,将所有的亚马逊业务数据先存入redis缓存中,然后进行数据的统一入库。具体架构如下所示:

image

具体做法是:将之前业务消费服务直接存入数据库修改为存入redis缓存,然后再新建一个统一入库任务,负责发送统一入库消息,最后消息消费端进行数据的统一入库。

总结

这边架构演变就分享到这边,世界上没有完美无缺的架构,所以我们不仅仅要学习框架的搭建,更要懂得如何更好的使用他们。

林老师带你学编程https://wolzq.com

林老师带你学编程 wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!