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

Spring Boot 1.0 版本

在很远很远的以前,作为单体应用,只有一个Spring Boot 应用,当两个Spring Boot 需要建立联系的时候,需要使用RestFulAPI作为两个应用之间的联系,实现其交流。
其具体过程如下
理论 | 当 Spring Boot 遇上了消息队列……插图
如上图所示,当有访问的时候,直接请求到API GATEWAY,然后有网关分发到相关的接口,实现其访问。
如上图所示。
此时对于接口来说,相当的平稳,应用全部通过Rest进行交流。互不干扰,互不影响,相互相当平稳,岁月安好,一切平安。
理论 | 当 Spring Boot 遇上了消息队列……插图1

消息队列实现削峰

当有大的流量来了肿么办,突然间没办法处理那么多的请求。
理论 | 当 Spring Boot 遇上了消息队列……插图2
请求太多,一招解决,加机器,直接集群上手,一套集群,直接搭上。
理论 | 当 Spring Boot 遇上了消息队列……插图3
集群带来的是什么,大量的机器,大量的人力,大量的物力,大量的财力的耗费,全都是钱啊。银子哗啦啦的像流水一般的流走。
理论 | 当 Spring Boot 遇上了消息队列……插图4
有以下几点

  1. 在高峰时期可以这样干,因为挣的多,花的也多,盈利的也多,利润也多。
  2. 在低谷不能这样干,因为这全是成本啊,并且峰值也就仅仅那一刻,所以呢,消息队列在这个时候登场。

消息队列实现流量削峰 v2.0

上方的架构图继续演化。以及改造
理论 | 当 Spring Boot 遇上了消息队列……插图5
这这里添加了相关的消息队列,通过消息队列实现当流量过来的时候,起到水坝的作用,暂时拦截流量。

理论 | 当 Spring Boot 遇上了消息队列……插图6

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

通过如此简单的一个消息队列实现了流量的基本削峰,既节省了成本,又节省了服务器的开销。

应用间的通信 v3.0

这个时候,由于应用被解耦成了多个部分,一部分为用户模块,一部分为邮件模块,例如,当需要用户注册成功以后发送消息到邮件模块,让其发送邮件。

本节 不会再次阐述削锋

理论 | 当 Spring Boot 遇上了消息队列……插图7
这个最简单的方法,直接调用api。

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

理论 | 当 Spring Boot 遇上了消息队列……插图8

问题来了!

理论 | 当 Spring Boot 遇上了消息队列……插图9

大量的请求来了怎么办!
调用失败,发送方这么知道?
如何确保只调用一次,重复性调用怎么办?
由于邮件处理和用户处理模块,性能不一致,两个性能之间巨大的差异怎么办。

大量的问题需要解决。

这个时候,消息队列继续出现

消息队列的应用

架构图如下

理论 | 当 Spring Boot 遇上了消息队列……插图10
两个应用间的通信一个生产方,一个消费方,直接通过消息队列实现两者之间的相互通信。
理论 | 当 Spring Boot 遇上了消息队列……插图11
几乎做到了如此的精美绝伦,如此的天衣无缝。实在令人不可思议。

总结

使用消息队列,实现两个应用之间的相互的解耦,并实现其基本的事物等功能。以及异步的功能
重点在于,实现应用的解耦,事物的基本实现,异步的基本实现。

日志处理 v4.0

当应用规模小的时候,不需要进行小规模的日志处理,这个时候,可以直接保存在本地,当应用规模很大的时候,每天产生上G的日志。
理论 | 当 Spring Boot 遇上了消息队列……插图12

使用消息队列实现日志的处理

俩张图祭天
理论 | 当 Spring Boot 遇上了消息队列……插图13
理论 | 当 Spring Boot 遇上了消息队列……插图14
其核心为生产者与消费者模型,模型来源于操作系统,通过生产者………
理论 | 当 Spring Boot 遇上了消息队列……插图15

简单来说, 就是日志量过大,通过客户端采集放入消息队列,进行延缓处理,然后日志处理应用,再次收集日志信息。通过ELK实现日志的基本处理。

即,通过ELK组件,实现基本的日志信息的处理。