核心概念
4.1應用模型
一個spring cloud Stream 應用包括了一個訊息中介軟體作為核心。某個應用通過springcloud Stream使用input和output通道與外界(注:訊息佇列)
進行訊息交換。通道通過中介軟體專用的繫結機制連線到外部的虛擬主機(注：原文為brokers，這是訊息佇列裡面的概念，可以理解成訊息隊裡的虛擬主機)。

(注：圖片中的MiddleWare就是指的訊息中介軟體，Springcloud Stream Application就是使用SpringcloudStream元件的應用，
這兩者通過Binder緊密的結合起來了，但是SpringCloud Stream Application中的應用想要通過Binder獲取到中介軟體中的訊息，
必須呼叫 Application Core中提供的API，而在架構上，Application Core是通過inputs和outputs通道撘成的橋和Binder進行
互動的)

4.1.1、FatJAR
Spring Cloud Stream應用可以在你的ide上單機執行。如果你需要在生產環境中執行spring cloud Stream專案，你可以建立一個可執行
的JAR通過maven或者Gradle。

4.2、抽象的Binder
Spring Cloud Stream 提供了Binder來實現和kafka或者RabbitMQ的互動(注：根據kafka和rabbitmq提供的服務來實現一定的功能，我
個人稱之為互動)。同時，spring Cloud Stream 也提供了一個例子，https://github.com/spring-cloud/spring-cloud-stream/blob/master/spring-cloud-stream-test-support/src/main/java/org/springframework/cloud/stream/test/binder/TestSupportBinder.java

spring cloud Stream使用spring boot的自動配置進行配置，使得 Binder靈活的連線各種訊息中介軟體成為可能。例如：
部署者可以在執行態下動態的選擇哪個目標（例如kafka的topics或者 rabbitmq的exchange）作為最終通道連線的物件。
這種配置支援任意一種springboot的配置。例如在sink的例子 https://docs.spring.io/spring-cloud-stream/docs/Elmhurst.RELEASE/reference/htmlsingle/#spring-cloud-stream-overview-introducing

spring.cloud.stream.bindings.input.destination=raw-sensor-data

會使得Binder從 名為 raw-sensor-data 的kafka topic 或者一個繫結在名為raw-sensor-data的RabbitMQ交換機的佇列中
獲取訊息。

Springcloud Stream會在classpath下面自動尋找和使用一個找到的binder。你可以用相同的程式碼使用不同的訊息中介軟體。如果要
這樣做，需要在build專案的時候引入一個不同的binder。在更復雜的環境下，你可以為你的應用打包很多binder，在不同的環境下使用
不同的binder（甚至你可以為不同的Binder繫結不同的通道)

4.3、支援釋出-訂閱模式
訊息資料通過在共享的主題中廣播，兩個應用之間的互動遵從釋出-訂閱模式。可以從下面這張展示部署在同一個topic下相互影響的spring
cloud Stream叢集是如何實現訊息的釋出-訂閱模式的。

感測器向http埠傳送的訊息資料被髮送到一個名為raw-sensor-data的公共目標。這個，目標下訂閱了兩個微服務，一個十計算時間窗平均值的微服務，
另一個是將原始資料放入到HDFS（Hadoop分散式檔案系統）的微服務應用。為了處理訊息資料，兩個應用程式都將該topic下的訊息作為自己執行時的輸入裝置。
釋出-訂閱交流模型減少了訊息生產者和訊息消費者在加入新的拓撲節點時不改變當前已有的網路模型的複雜度。

4.4、消費者組
雖然訊息 釋出-訂閱模式使得具有共享topics的應用間的交流變得簡單，但是通過建立給定應用程式的多個例項來擴充套件的能力同樣重要。
執行此操作時，應用程式的不同例項將放置在競爭的使用者關係中，其中只有一個例項來處理給定的訊息。
Spring Cloud Stream通過消費者群體的概念對此行為進行建模。每一個消費者通過使用如下配置

spring.cloud.stream.bingings.<channelName>.group 

的屬性來指明特定的組名。例如，在下面的圖片中，這個屬性將被這樣設定

# left
spring.cloud.stream.bindings.<channelName>.group=hdfsWrite
# right
spring.cloud.stream.bindings.<channelName>.group=average

訂閱給定目標的所有組都會收到已釋出資料的副本，但每個組中只有一個成員從該目標接收給定的訊息，預設情況下，未指定組時，
Spring Cloud Stream將應用程式分配給與所有其他使用者組具有釋出 - 訂閱關係的匿名且獨立的單成員使用者組。

4.5、消費者型別
有兩種消費者型別：
訊息驅動（非同步）
輪詢（同步）
在2.0版本以前只支援訊息驅動的方式，訊息一旦可用就會傳遞，並且可以使用一個執行緒來處理它
如果要控制處理訊息的速率，可能需要使用同步使用者

4.5.1、永續性
消費者組訂閱是持久的，與Spring Cloud Stream的固定應用模型一致。也就是說，繫結器實現確保組訂閱是持久的，一旦
建立了一個組的至少一個訂閱，該組就會接收訊息，即使它們是在組中的所有應用程式都已停止時傳送的。
通常，在將應用程式繫結到給定目標時，最好始終指定使用者組。擴充套件Spring Cloud Stream應用程式時，必須為每個輸入
繫結指定一個使用者組。這樣做可以防止應用程式的例項接收重複的訊息

4.6、分割槽支援
Spring Cloud Stream支援在給定應用程式的多個例項之間對資料進行分割槽。在分割槽方案中，物理通訊介質（例如代理主題）
被視為結構化為多個分割槽。一個或多個生產者應用程式例項將資料傳送到多個消費者應用程式例項，並確保由共同特徵標識的
資料由同一個消費者例項處理。
Spring Cloud Stream提供了一種通用抽象，用於以統一的方式實現分割槽處理用例，因此，無論訊息中介軟體本身具有自然分
區（例如，Kafka）或者沒有（例如，RabbitMQ），都可以使用分割槽

分割槽是有狀態處理中的一個關鍵概念，由於效能或一致性原因，確保所有相關資料一起處理至關重要。或者，在時間視窗平均
值計算示例中，重要的是來自任何給定感測器的所有測量值都由相同的應用程式例項處理。