转载

Spring Cloud Stream与Spring Integration集成以及Spring Cloud Function的关系：开启从基于注释到...

目的是揭开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.<b>class</b>)
<b>public</b> <b>class</b> SampleApplication  {
    @StreamListener(Processor.INPUT)
    @SendTo(Processor.OUTPUT)
    <b>public</b> String uppercase(String value) {
        <b>return</b> value.toUpperCase();
    }
}

基于函数(自v2.1.0起)

@SpringBootApplication
<b>public</b> <b>class</b> SampleApplication  {
    @Bean
    <b>public</b> Function<String, String> uppercase() {
        <b>return</b> value -> value.toUpperCase();
    }
}

两者都是有效且功能齐全的SCSt应用程序。两者都做同样的事情，并且都产生相同的结果，这就提出了一个问题：为什么？Spring一直以来都是“您关心功能需求，我们会处理非函数性（样板）”。

因此，在SCSt作为框架及其“绑定和激活/触发”的核心目标的上下文中，我们很快意识到这些抽象是样板，不应泄漏到用户代码中，尤其是以注释的形式泄漏，因为它们有助于无正当理由而导致此类代码对SCSt的二进制依赖性。

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

原文 https://www.jdon.com/53319

正文到此结束