Bindings
如前所述，Binding 在外部消息传递系统（例如，队列、主题等）和应用程序提供的 Producers 和 Consumers 之间提供了一个桥梁。
As stated earlier, Bindings provide a bridge between the external messaging system (e.g., queue, topic etc.) and application-provided Producers and Consumers.
以下示例展示了一个完全配置且正常运行的 Spring Cloud Stream 应用程序，它以 String 类型接收消息的有效负载（请参阅 [Content Type Negotiation] 部分），将其记录到控制台，并在将其转换为大写后向下游发送。
The following example shows a fully configured and functioning Spring Cloud Stream application that receives the payload of the message
as a String type (see [Content Type Negotiation] section), logs it to the console and sends it down stream after converting it to upper case.
@SpringBootApplication
public class SampleApplication {
public static void main(String[] args) {
SpringApplication.run(SampleApplication.class, args);
}
@Bean
public Function<String, String> uppercase() {
return value -> {
System.out.println("Received: " + value);
return value.toUpperCase();
};
}
}上述示例看起来与任何 vanilla spring-boot 应用程序并无不同。它定义了一个类型为 Function 的单个 bean，仅此而已。那么，它是如何成为 spring-cloud-stream 应用程序的呢？它成为 spring-cloud-stream 应用程序仅仅是因为类路径上有 spring-cloud-stream 和 binder 依赖项和自动配置类，从而有效地将引导应用程序的上下文设置为 spring-cloud-stream 应用程序。此时，类型为 Supplier、Function 或 Consumer 的 bean 被视为事实上的消息处理程序，触发绑定到由提供的 binder 公开的目的地，遵循某些命名约定和规则以避免额外的配置。
The above example looks no different then any vanilla spring-boot application. It defines a single bean of type Function
and that is it. So, how does it become a spring-cloud-stream application?
It becomes a spring-cloud-stream application simply because of the presence of spring-cloud-stream and binder dependencies
and auto-configuration classes on the classpath, effectively setting the context for your boot application as a spring-cloud-stream application.
And in this context beans of type Supplier, Function or Consumer are treated as defacto message handlers triggering
binding of to destinations exposed by the provided binder following certain naming conventions and
rules to avoid extra configuration.