这是小小本周的第五篇，当 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 组件，实现根本的日志信息的解决。