微服务架构 | 消息总线和驱动 - [Bus & Stream]
@
§1 消息总线
§1.1 简介
消息总线
- 微服务系统中，指定一个全局通用的 TOPIC
- 此 TOPIC 被所有服务的所有实例监听和消费
- 被扔到这个 TOPIC 里的所有消息，会被所有服务得到，所以称之为 消息总线
BUS
Spring Cloud Bus links nodes of a distributed system with a lightweight message broker. This can then be used to broadcast state changes (e.g. configuration changes) or other management instructions. AMQP and Kafka broker implementations are included with the project. Alternatively, any Spring Cloud Stream binder found on the classpath will work out of the box as a transport.
Spring Cloud Bus 通过轻量级消息代理连接分布式系统中的节点。这可以用于广播状态变更（比如，配置更新）或其他管理指令。此项目包括AMQP（Advanced Message Queuing Protocol）协议和 kafka 代理实现。同时，在类路径（classpath）上能找到的任何 Spring Cloud Stream binder 都可以作为传输工具做到开箱即用。
§1.2 使用
准备 rabbitmq
具体参考 中间件 | 消息队列 - [RabbitMq]
所有需要消息队列的服务添加如下内容
依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
配置
spring:
rabbitmq:
host: 192.168.3.7
port: 5672
username: guest
password: guest
§2 消息驱动
§2.1 简介
消息驱动
类似于 JDBC ，在复杂架构中，不同的子系统很可能使用不同的消息中间件，此时往往引入消息驱动，起作用在于
- 屏蔽不同消息中间件的底层差异
- 统一消息编程模型
- 降低不同消息中间件的切换成本和研发人员的学习成本
Stream
Spring Cloud Stream is a framework for building highly scalable event-driven microservices connected with shared messaging systems.
The framework provides a flexible programming model built on already established and familiar Spring idioms and best practices, including support for persistent pub/sub semantics, consumer groups, and stateful partitions.
Spring Cloud Stream 是一个用于构建 高可扩展微服务与共享消息系统 的连接的框架。
这个框架提供了一个灵活可变的编程模型，此模型基于已经存在并为人熟知的 spring 语法和最佳实践，包括对发布-订阅持久化、消费者组和有状态 partition 的支持
binder
binder 是对不同消息中间件接入 Stream 的实现，类似 jdbc 连接池和 Driver 的关系。
目前已有的 binder 实现：
- RabbitMQ
- Apache Kafka
- Kafka Streams
- Amazon Kinesis
- Google PubSub (partner maintained)
- Solace PubSub+ (partner maintained)
- Azure Event Hubs (partner maintained)
- Azure Service Bus (partner maintained)
- AWS SQS (partner maintained)
- AWS SNS (partner maintained)
- Apache RocketMQ (partner maintained)
§2.2 原理
声明
本帖本质上是个笔记，下面的原理不涉及具体代码实现，而是作者为了让自己明白生撸出来的一套东西
因此，不保证理解的一定对（或者说几乎肯定有不对的地方）
几个重要概念
binder
- 绑定器，用于创建 绑定(binding) 的工具
- 一个绑定器，基本可以理解为对应一个消息中间件，可以类比为对 数据库实例 的连接
binding
- 绑定，绑定器(binder) 的产品
- 绑定的两端分别是 信道(MessageChannel) 和 消息交换机(Exchange)
- 可以类比为对 数据库实例中一个具体库 的连接，但因为绑定一端的 信道(MessageChannel) 本身具有方向，所以只相当于一个连接中读或者写的部分
MessageChannel
- 信道，消息的通道，连接了业务服务和中间件，对一个明确的中间件，它起到了代理(agent，不是 broker)的作用
- 业务中，收发消息等操作实际上是通过操作信道实现的，Stream 就是通过信道实现了对具体中间件的解耦
Source 和 @Output
- source 配合 @EnableBinding 使用
- source 标记了当前服务作为一个 消息源 来建立 绑定(binding)，消息源即消息的发送者、输出者（@Output）
- source 中声明了一个信道，并标记其为 @Output，如下图
Sink和 @Input - sink 配合 @EnableBinding 使用
- sink 标记了当前服务作为一个 消息接收器 来建立 绑定(binding)，消息接收器即消息的接受者、输入者（@Input）
- sink中声明了一个信道，并标记其为 @Input
原理示意图( 以 rabbit 为例 )
C 位的信道
- Stream 屏蔽不同消息中间件底层差异是因为提供了一套通用的编程模型
- 通用编程模型的载体即 消息信道(MessageChannel)
信道的作用
- 可以将信道看做一套标准或默认实现，或者简单理解为一个标准的 API
- 消息信道出现后，研发人员通过操作它，实现对消息中间件的操作
信道如何起作用
- 为了达到上面的目的，消息信道应该同时与业务服务和消息中间件建立物理上的连接以及逻辑上的绑定
- 与业务服务连接，最终可以使用 MessageChannel 的 API 实现对消息中间件的代理
- 与消息中间件连接，实现将消息物理的输入/输出消息中间件
- 总体来说：服务--(通过注解配置)--消息信道--(通过绑定连接访问)--消息中间件
- 通过注解，标记一个输入（@Input）或输出（@Output）方向的信道
- 服务发送或监听的消息，都会先传输到信道中，后面的逻辑由信道代理
- 信道会根据相关配置，建立与指定消息中间件实例上指定 Exchange 的绑定关系
- 信道通过绑定实现与消息中间件的消息传输
§2.3 使用
依赖
根据实际使用的消息中间件决定 xxx 的内容
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-xxx</artifactId>
</dependency>
配置
spring:
application:
name: rabbit-stream-provider
rabbitmq:
host: 192.168.3.10
port: 5672
username: guest
password: guest
cloud:
stream:
binders: # 在此处配置要绑定的rabbitmq的服务信息；
defaultRabbit: # 表示定义的名称，用于于binding整合
type: rabbit # 消息组件类型
bindings: # 服务的整合处理
output: # 这个名字是一个通道的名称
destination: studyExchange # 表示要使用的Exchange名称定义
content-type: application/json # 设置消息类型，本次为json，文本则设置“text/plain”
binder: defaultRabbit # 设置要绑定的消息服务的具体设置
§3 消息队列常见坑
传送门：
微服务架构 | 组件目录
