消息驱动微服务框架Spring Cloud Stream使用详解1（基本介绍）
一、基本介绍
1，什么是 Spring Cloud Stream?
- Spring Cloud Stream 是一个用来为微服务应用构建消息驱动能力的框架。它为一些供应商的消息中间件产品提供了个性化的自动化配置实现，并且引入了发布-订阅、消费组以及分区这三个核心概念。
- Spirng Cloud Stream 本质上就是整合了 Spring Boot 和 Spring Integration，实现一套轻量级的消息驱动的微服务框架。通过使用 Spring Cloud Stream 可以有效简化开发人员对消息中间件的使用复杂度，让系统开发人员可以有更多的精力关注于核心业务逻辑的处理。
- Spring Cloud Stream 基于 Spring Boot 实现，所以它秉承了 Spring Boot 的优点，自动化配置功能可以帮助我们快速上手使用。不过 Spring Cloud Stream 目前只支持 RabbitMQ 和 Kafka 这两个消息中间件的自动化配置。
2，Spring Cloud Stream 解决了什么问题？
（1）在实际开发过程中，服务与服务之间通信经常会使用到消息中间件，如果我们一开始选择使用某个中间件比如：RabbitMQ，那么该中间件和系统的耦合性就会非常高。后续如果我们再要替换为 Kafka 那么代码变动会比较大。
（2）Spring Cloud Stream 解决了开发人员无感知的使用消息中间件的问题，因为 Spring Cloud Stream 对消息中间件的进一步封装，可以做到代码层面对中间件的无感知，甚至于动态的切换中间件（RabbitMQ 切换为 Kafka），降低系统和中间件的耦合性，让应用程序可以关注更多自己的业务流程。
3，Spring Cloud Stream 核心概念
（1）下面是官方文档中的 Spring Cloud Stream 应用模型的结构图，而 Spring Cloud Stream 中消息的发布和消费，涉及四个组件：Source、Channel、Binder 和 Sink。
上面的结构图中，样例应用程序和 Binder 之间定义了两条输入通道和三条输出通道来传递信息，而绑定器则是作为这些通道和消息中间件之间的桥梁进行通信。当需要升级消息中间件，或者更换其他消息中间件产品时，我们要做的就是更换它们对应的 Binder 绑定器而不需要修改任何 Spring Boot 的应用逻辑。
（3）绑定器 Binder：Spring Cloud Stream 构建的应用程序与消息中间件之间是通过绑定器 Binder 相关联的，绑定器对于程序而言起到了隔离作用，它使得不同消息中间件的实现细节对应用程序来说是透明的。
由于 RabbitMQ 和 Kafka 自身的实现结构有所不同，因此 RabbitMQ 与 Kafka 的绑定器分别使用消息中间件中不同概念来实现消息的生产与消费：
- RabbitMQ 绑定器：在 RabbitMQ 中，通过 Exchange 交换器来实现 Spring Cloud Stream 的主题概念，所以消息通道的输入输出目标映射了一个具体的 Exchange 交换器。而对于每个消费组，则会为对应的 Exchange 交换器绑定一个 Queue 队列进行消息收发。
- Kafka 绑定器：由于 Kafka 自身就有 Topic 概念，所以 Spring Cloud Stream 的主题直接采用了 Kafka 的 Topic 主题概念，每个消费组的通道目标都会直接连接 Kafka 的主题进行消息收发。
（4）Source 与 Sink：当一个服务准备发布消息时，它将使用一个 Source 发布消息，它接受普通的 Java 对象，该对象代表发布的消息，Source 将 Java对象序列化并将消息发布到 Channel。而服务会通过 Sink 从队列中接受消息，将消息反序列化为 POJO 对象。
附：消息中间件几个常见的应用场景
碰到下面的几种情况的时候，我们就要考虑使用消息队列。如果碰巧使用的是 RabbitMQ 或者 Kafka，而且同样也是在使用 Spring Cloud ，那可以考虑下用 Spring Cloud Stream。
1，异步处理
比如用户在电商网站下单，下单完成后会给用户推送短信或邮件，发短信和邮件的过程就可以异步完成。因为下单付款是核心业务，发邮件和短信并不属于核心功能，并且可能耗时较长，所以针对这种业务场景可以选择先放到消息队列中，有其他服务来异步处理。
2，应用解耦
假设公司有几个不同的系统，各系统在某些业务有联动关系，比如 A 系统完成了某些操作，需要触发 B 系统及 C 系统。如果 A 系统完成操作，主动调用 B 系统的接口或 C 系统的接口，可以完成功能，但是各个系统之间就产生了耦合。用消息中间件就可以完成解耦，当 A 系统完成操作将数据放进消息队列，B 和 C 系统去订阅消息就可以了。这样各系统只要约定好消息的格式就好了。
3，流量削峰
比如秒杀活动，一下子进来好多请求，有的服务可能承受不住瞬时高并发而崩溃，所以针对这种瞬时高并发的场景，在中间加一层消息队列，把请求先入队列，然后再把队列中的请求平滑的推送给服务，或者让服务去队列拉取。
4，日志处理
Kafka 最开始就是专门为了处理日志产生的。
