大话SpringCloud---Spring Cloud Stream消息驱动__概念
学习新技术,了解新概念,记录新生活
这一篇博客简单介绍一下Spring Cloud Stream
消息驱动的概念以及设计思想。
为什么需要呢?
首先一个新东西的出现,那必然是因为某种需求的驱动。而今天的主角Spring Cloud Stream
也是如此。
现在的开发早就讲究前后端分离了,前后端提前商量好数据的传输格式(json的对象等)、所需接口说明等等。后端的朋友只需要提供接口给前端的小伙伴调用即可,就不用像以前那样还要去关注视图层的情况,从而专注于业务的开发。
但是随着社会的发展,后端可不仅仅是后端了,它还需要去分析所产生的海量数据,从而分析出用户的行为与改变运营策略等等。因此后端有分出了大数据这个岗位。
而现在微服务通信难免要去使用消息中间件来通信,这样的话就会有一个问题,如果后端与大数据之间使用的消息中间件不同该怎么办?
比如后端使用RabbitMQ,大数据使用Kafka,那么它们之间通信就很难搞,要来回切换、维护,同时有些开发人员只会其中一种技术,这样子的架构需要开发人员额外去学习另外一种消息中间件,无形增加了成本。
上图,最左边的框框表示前端,中间表示后端,最右边表示大数据。
我们现在希望专注于业务代码的实现,而不是在这些琐碎的事情上浪费时间。
这个时候Spring Cloud Stream
就出来了,它可以屏蔽使用消息中间件的细节,你不需要去管消息中间件底层的细节、切换与维护。你只需要去调用Spring Cloud Stream
的api即可。
它统一了编程的消息模型,就像jdbc至于java一样,我们也不用管数据库用的是Mysql还是Oracle还是SqlServer。我们只用去使用jdbc就可以了。
概念
Spring Cloud Stream是一个框架,用于构建与共享消息传递系统连接的高度可扩展的事件驱动型微服务。
同时还有一个中文版的操作手册,大家可以参考查阅。
应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream 中binder 交互,通过我们配置来 binding ,而 Spring Cloud Stream 的 binder 负责与中间件交互。所以,我们只需要搞清楚如何与 Spring Cloud Stream 交互就可以方便使用消息驱动的方式。 Spring Cloud Stream 目前只实现了 Kafka 和 Rabbit MQ的Binder。
简单来说,我们就是通过一个叫Binder的东西,由它和消息中间件打交道。目前只支持RabbitMQ、Kafka
。上面说到的inoputs
代表消息的生产者,outputs
代表消息的消费者。
总结
一句话,Spring Cloud Stream
通过绑定器的设计,完美地实现了应用程序与消息中间件细节之间的隔离,Stream
对消息中间件进一步的封装,可以做到代码层面对中间件的无感知,甚至于动态的切换中间件(RabbitMq切换为Kafka),使得微服务开发高度解耦,服务可以关注更多自己的业务流程。
记录到这里,感谢观看????