Spring Cloud Stream与Spring Integration集成以及Spring Cloud Function的关系:开启从基于注释到函数式编程的漫长转换 - spring.io


目的是揭开Spring Cloud Stream和Spring Cloud Function项目的真正目标的神秘面纱,并进行演示他们的新功能。

Spring Cloud Stream是Spring Integration包装器吗?
 Spring Cloud Stream,是一个轻量级的Spring Integration输入/输出路由器……”。这是一个有趣的看法,但我不同意,尽管它可能是受企业集成模式(EIP)的启发并且在Spring Integration(SI)的基础上构建,最后一部分实际上只是一个实现细节,Spring Cloud Stream(SCSt)作为框架绝不是“成为轻量级的Spring Integration输入/输出路由器”。
实际上,该陈述表明了问题的一部分,在某种程度上,SI(支持SCSt的一些内部需求的选择框架)被认为是SCSt的核心,因此许多人都认为SCSt是扩展的SI的包装器。

Spring Cloud Stream一直以来都是关于纯微服务,并将它们绑定到数据的源和目标(即消息传递系统),就那么简单。它确实是一个绑定和激活框架。它将一段代码(由用户提供)绑定到公开的源/目标,并根据绑定器的具体实现(例如消息到达等)激活此类代码,就是这样。

Function还是非Function?
从历史上看,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应用程序。两者都做同样的事情,并且都产生相同的结果,这就提出了一个问题:为什么?Spring一直以来都是“您关心功能需求,我们会处理非函数性(样板)”。
因此,在SCSt作为框架及其“绑定和激活/触发”的核心目标的上下文中,我们很快意识到这些抽象是样板,不应泄漏到用户代码中,尤其是以注释的形式泄漏,因为它们有助于无正当理由而导致此类代码对SCSt的二进制依赖性。

因此,我要说的是,我们正开始缓慢的旅程,从基于注释的编程模型转变为更加敏捷,简单且符合Spring Boot要求的,经过明确记录的直观模型,并且在有限的条件下实现了直观的约定。用户所需的即用型配置。(banq注:从基于注释到函数式编程是一个大方向)