乐趣区

关于java:理论-当-Spring-Boot-遇上了消息队列

这是小小本周的第五篇,当 Spring Boot 遇上了音讯队列。

Spring Boot 1.0 版本

在很远很远的以前,作为单体利用,只有一个 Spring Boot 利用,当两个 Spring Boot 须要建立联系的时候,须要应用 RestFulAPI 作为两个利用之间的分割,实现其交换。
其具体过程如下

如上图所示,当有拜访的时候,间接申请到 API GATEWAY,而后有网关散发到相干的接口,实现其拜访。
如上图所示。
此时对于接口来说,相当的安稳,利用全副通过 Rest 进行交换。互不烦扰,互不影响,互相相当安稳,岁月安好,所有安全。

音讯队列实现削峰

当有大的流量来了肿么办,忽然间没方法解决那么多的申请。

申请太多,一招解决,加机器,间接集群上手,一套集群,间接搭上。

集群带来的是什么,大量的机器,大量的人力,大量的物力,大量的财力的消耗,全都是钱啊。银子哗啦啦的像流水个别的流走。

有以下几点

  1. 在顶峰期间能够这样干,因为挣的多,花的也多,盈利的也多,利润也多。
  2. 在低谷不能这样干,因为这全是老本啊,并且峰值也就仅仅那一刻,所以呢,音讯队列在这个时候退场。

音讯队列实现流量削峰 v2.0

上方的架构图持续演变。以及革新

这这里增加了相干的音讯队列,通过音讯队列实现当流量过去的时候,起到水坝的作用,临时拦挡流量。

如此精妙绝伦的设计,前不见古人,后不见来者哇。

通过如此简略的一个音讯队列实现了流量的根本削峰,既节俭了老本,又节俭了服务器的开销。

利用间的通信 v3.0

这个时候,因为利用被解耦成了多个局部,一部分为用户模块,一部分为邮件模块,例如,当须要用户注册胜利当前发送音讯到邮件模块,让其发送邮件。

本节 不会再次论述削锋


这个最简略的办法,间接调用 api。

通过 api 的形式,实现间接调用,流程图如下

问题来了!

大量的申请来了怎么办!
调用失败,发送方这么晓得?
如何确保只调用一次,重复性调用怎么办?
因为邮件解决和用户解决模块,性能不统一,两个性能之间微小的差别怎么办。

大量的问题须要解决。

这个时候,音讯队列持续呈现

音讯队列的利用

架构图如下


两个利用间的通信一个生产方,一个生产方,间接通过音讯队列实现两者之间的互相通信。

简直做到了如此的精美绝伦,如此的浑然一体。切实令人不堪设想。

总结

应用音讯队列,实现两个利用之间的互相的解耦,并实现其根本的事物等性能。以及异步的性能
重点在于,实现利用的解耦,事物的根本实现,异步的根本实现。

日志解决 v4.0

当利用规模小的时候,不须要进行小规模的日志解决,这个时候,能够间接保留在本地,当利用规模很大的时候,每天产生上 G 的日志。

应用音讯队列实现日志的解决

俩张图祭天


其外围为生产者与消费者模型,模型来源于操作系统,通过生产者 ………

简略来说,就是日志量过大,通过客户端采集放入音讯队列,进行延缓解决,而后日志解决利用,再次收集日志信息。通过 ELK 实现日志的根本解决。

即,通过 ELK 组件,实现根本的日志信息的解决。

退出移动版