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

微信扫一扫,分享到朋友圈

理论 | 当 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组件,实现基本的日志信息的处理。

.NET Core使用NPOI将Excel中的数据批量导入到MySQL

上一篇

人类另一个本质是“仓鼠精”?

下一篇

你也可能喜欢

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

长按储存图像,分享给朋友