Spring Cloud及微服务（九）：消息驱动Spring Cloud Stream

本文内容基于《Spring Cloud微服务实战》，翟永超著。

---

出现背景

Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。

通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。

Spring Cloud Stream本质上就是整合了Spring Boot和Spring Integration，实现了一套轻量级消息驱动的微服务框架。

Spring Boot整合Stream-Rabbit

• 依赖

• 消息消费者

• 启动程序，在RabbitMQ控制台发送给消息

• 程序输出

Spring Cloud Stream应用模型结构图

Spring Cloud Stream构建的应用程序与消息中间件之间是通过绑定器Binder相关联的，绑定器对于应用程序而言起到了隔离作用，它使得不同消息中间件的实现细节对应应用程序来说是透明的。

• 绑定器

通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件的实现。就如上一章中，从RabbitMQ切换到Kafka。

• 发布-订阅模式

Spring Cloud Stream中的消息通信方式遵循了发布-订阅模式，当一条消息被投递到消息中间件之后，它会通过共享的Topic主题进行广播，消息消费者在订阅的主题中收到它并触发自身的业务逻辑处理。

相对于点对点队列实现的消息通信来说，Spring Cloud Stream采用的发布-订阅模式可以有效降低消息生产者与消费者之间的耦合。当需要对同一类消息增加一种处理方式时，只需要增加一个应用程序并将输入通道绑定到既有的Topic中就可以实现功能的扩展，而不需要改变原来已经实现的任何内容。

• 消费组

在现实的微服务架构中，每一个微服务应用都会部署多个实例，当消息生产者发送消息给某个微服务时，这时候就会被同一个微服务的多个实例消费，出现重复消费。

通过spring.cloud.stream.bindings.input.group属性为应用指定一个组名，这样这个应用的多个实例在接收到消息的时候，只会有一个成员真正收到并进行处理。

• 消息分区

消费组无法控制消息具体被哪个实例消费，但是对于一些业务场景，需要对一些具有相同特征的消息设置每次都被同一个消费实例处理。

消息生产者可以为消息增加一个固有的特征ID来进行分区。

绑定消息通道

在Spring Cloud Stream中，可以在接口中通过@Input和@Output注解来定义消息通道，而用于定义绑定消息通道的接口则可以被@EnableBinding注解的value参数来指定，从而在应用启动的时候实现对定义消息通道的绑定。

Spring Cloud Stream自带一个Sink、一个Source、一个Processor，源码如下：