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