Spring Cloud Stream-神秘化和简化
这是一系列博客文章中的第一篇,旨在澄清和预览即将发布的spring-cloud-stream和spring-cloud-function (均为3.0.0)版本中的内容。
最近,我与一个用户进行了讨论,听到了一些提示,促使我开始撰写一系列博客文章(以此为起点),目的是揭开Spring Cloud Stream和Spring Cloud Function项目的真实目标的神秘面纱,并进行演示。他们的新功能。
Spring Integration包装器?
促使所有这一切的特定短语是- “ Spring Cloud Stream,是轻量级的Spring Integration输入/输出路由器……” 。这是一种有趣的看法,但我必须不同意。虽然它可能是受企业集成模式(EIP)的启发,并基于Spring Integration(SI)构建的,但最后一部分实际上只是实现细节。Spring Cloud Stream(SCSt)作为框架从来就不是“成为轻量级的Spring Integration输入/输出路由器” 。实际上,该陈述表明了问题的一部分,在某种程度上,SI(支持SCSt的一些内部需求的选择框架)被认为是SCSt的核心,因此许多人认为SCSt是扩展或扩展。 SI的包装器。它不是。一直以来都是关于纯微服务,并将它们绑定到数据的源和目标 (即消息传递系统)。就那么简单。
如果您不了解SCSt的内部知识就足够抽象,那么您很快就会意识到它确实是一个绑定和激活框架。它将一段代码(由用户提供)绑定到活页夹公开的数据的源/目标,并根据活页夹实现(例如消息到达等)激活此类代码。就是这样。
起作用还是不起作用?
从历史上看,Spring Cloud Stream公开了基于注解的配置模型,该模型需要用户提供很多可以轻松推断的信息,从而简化了配置。
让我们看下面的两个代码片段
基于注释:
@SpringBootApplication
@EnableBinding(Processor.class)
public class SampleApplication {
@StreamListener(Processor.INPUT)
@SendTo(Processor.OUTPUT)
public String uppercase(String value) {
return value.toUpperCase();
}
}
基于函数(自v2.1.0起):
@SpringBootApplication
public class SampleApplication {
@Bean
public Function<String, String> uppercase() {
return value -> value.toUpperCase();
}
}
两者都是有效且功能齐全的SCSt应用程序。两者都做同样的事情,并且都产生相同的结果–区别在于,在基于注释的示例中,用户必须了解SCSt抽象(即消息传递,通道,绑定等),而实际的用户代码与它们无关。这就提出了一个问题:为什么?Spring一直以来都是“您担心功能需求,我们会处理非功能性(样板)” 。因此,在SCSt作为框架及其“绑定和激活/触发”核心目标的上下文中,我们很快意识到这些抽象是样板,不应泄漏到用户代码中,尤其是以注释的形式泄漏,因为它们有助于无正当理由而导致此类代码对SCSt的二进制依赖性。
另外,鉴于Spring产品组合中大多数新框架的基础是Spring Boot,请考虑一下Spring Boot的核心信息–依赖关系(例如JAR)包括自动配置,这实际上是对我们(Spring)如何相信的看法事情应该是 ,同时让您选择退出。因此,在这种情况下,为什么需要提供那么多指令,尤其是通过注释( EnableBinding, Processor, StreamListener
以及其他),只需遵循一些约定即可轻松提取或推断相同的信息(在SCSt的上下文中)。例如,在SCSt上下文中的功能bean是处理器。我们知道一个处理器只有一个输入目标和一个输出,并且我们知道它们的名称,那么为什么我们需要显式声明已知和显而易见的名称呢?依此类推……同样,请记住,在推导所有这些内容的同时,我们仍然保留使用现有的使用者和生产者属性以及所有其他配置选项。它们仍然在此处适用,可让您配置和重新配置与StreamListener
。
因此,我要说的是,我们正从缓慢的旅程开始,从基于注释的编程模型转变为更加敏捷,简单且符合Spring Boot要求的,带有明确文档和直观约定的,固执己见的模型,并且该过程非常有限。用户需要的即用型配置。
有关spring-cloud-stream中功能支持的更多最新信息,请点击此链接 。
请随时提供任何反馈。