springcloud 消息队列_SpringCloud 消息驱动 Stream

1、为什么引入SpringCloud Stream

当我们的消息生产者产生了消息之后，就把消息推送到RabbitMQ或Kafka这样的消息中间件上，消息消费者实现了对消息中间件的监听，当侦听到了消息的时候，就去获取对应的消息，完成整个消息的推送接收流程。

如果是简单的单条消息传递，那直接从消息生产者到消息消费者就OK了，但是消息一旦多起来，并且生产者和消费者都错综复杂，就更不利于管理了。使用消息中间件就可以集中化管理这些复杂的消息。消息生产者可以看作是现实生活中的寄信人，RabbitMQ或Kafka这样的消息中间件相当于是一个邮局，最后的收信人类似消息消费者。我们只需要把自己需要寄送的信件放到邮筒里，就可以完成信件的寄送，收信人也只需要从邮箱取信件，至于中间邮局是怎么完成信件的接收、运输和分发，我们都不关心。

Spring Cloud就完成了上述的工作，它使用Stream来帮助我们完成各个服务之间的消息推送接收，同时集成了RabbitMQ和Kafka这样的消息中间件API，可以十分便捷地完成消息推送接收开发。

其实这也是Spring Cloud整个核心的体现，简化开发流程，能让我们将大部分的精力集中到业务的开发上。

2、是什么

一句话：屏蔽底层消息中间键的差异，降低切换版本，统一消息的编程模型。

是一个建消息驱动的微服务的框架。用于构建与共享消息传递系统连接的高度可伸缩的事件驱动微服务框架。该框架提供了一个灵活的编程模型，他建立在已经建立和熟悉的spring熟语和最佳实现上，包括支持就的发布/订阅，消费组以及消息分区三个核心概念。

官网：https://spring.io/projects/spring-cloud-stream#overview

应用程序通过inputs或者outputs来与Spring Cloud Stream中binder对象交互。

通过我们配置来binding(绑定)，而Spring Cloud Stream的binder对象负责与消息中间件交互。

所以，我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。

通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。

目前仅支持RabbitMQ、Kafka。

3、设计思想

知其然知其所以然！这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰。我们如果用了两个消息队列的其中一种，后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑就是一个灾难性的，一大堆东西都要重新推倒重新做，因为它跟我们的系统耦合了，这时候springcloud Stream给我们提供了—种解耦合的方式。

通过定义绑定器Binder作为中间层，实现了应用程序与消息中间键细节之间的隔离

使用MQ的发布-订阅模式：通过Topic主题进行广播：

在RabbitMQ就是：Exchange

在Kafka就是Topic

理论实操小总结

4、常用注解

标准流程套路：

关键名词：

Binder：很方便的连接中间建，屏蔽差异

Channel：通道，是队列Quenue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置

Source和Sink：简单的可理解为参照对象是Sptring Cloud Stream自身，从Stream发布消息就是输出，接收消息就是输入。

常用注解：