一、Spring Cloud Stream 在實際的企業開發中，消息中間件是至關重要的組件之一。消息中間件主要解決應用解耦，非同步消息，流量削鋒等問題，實現高性能，高可用，可伸縮和最終一致性架構。不同的中間件其實現方式，內部結構是不一樣的。如常見的RabbitMQ和Kafka，由於這兩個消息中間件的架 ...
一、Spring Cloud Stream
在實際的企業開發中，消息中間件是至關重要的組件之一。消息中間件主要解決應用解耦，非同步消息，流量削鋒等問題，實現高性能，高可用，可伸縮和最終一致性架構。不同的中間件其實現方式，內部結構是不一樣的。如常見的RabbitMQ和Kafka，由於這兩個消息中間件的架構上的不同，像 RabbitMQ有exchange，kafka有Topic，partitions分區，這些中間件的差異性導致實際項目開發造成了一定的困擾，如果用了兩個消息隊列的其中一種，後面的業務需求，想往另外一種消息隊列進行遷移，這時候無疑就是一個災難性的，一大堆東西都要重新推倒重新做，因為它跟我們的系統耦合了，這時候 springCloud Stream提供了一種解耦合的方式。
1、概述
Spring Cloud Stream由一個中間件中立的核組成。應用通過Spring Cloud Stream插入的input(相當於消費者consumer，它是從隊列中接收消息的)和output(相當於生產者producer，它是從隊列中發送消 息的)通道與外界交流。通道通過指定中間件的Binder實現與外部代理連接。業務開發者不再關註具體消息中間件，只需關註Binder對應用程式提供的抽象概念來使用消息中間件實現業務即可。
說明：最底層是消息服務，中間層是綁定層，綁定層和底層的消息服務進行綁定，頂層是消息生產者和消息消費者，頂層可以向綁定層生產消息和和獲取消息消費
2、核心概念
綁定器Binder
綁定器是Spring Cloud Stream中一個非常重要的概念。在沒有綁定器這個概念的情況下，Spring Boot應用要直接與消息中間件進行信息交互的時候，由於各消息中間件構建的初衷不同，實現細節上會有較大的差異性，這使得實現的消息交互邏輯就會非常笨重，因為對具體的中間件實現細節有太重的依賴，當中間件有較大的變動升級、或是更換中間件的時候，就需要付出非常 大的代價來實施。 通過定義綁定器作為中間層，實現了應用程式與消息中間件(Middleware)細節之間的隔離。通過嚮應用程式暴露統一的Channel通過，使得應用程式不需要再考慮各種不同的消息中間件的實現。當需要升級消息中間件，或者是更換其他消息中間件產品時，需要做的就是更換對應的Binder綁定器而不需要修改任何應用邏輯 。甚至可以任意的改變中間件的類型而不需要修改一行代碼。 Spring Cloud Stream支持各種binder實現。
通過配置把應用和spring cloud stream 的 binder 綁定在一起，之後只需要修改 binder 的配置來達到動態修改topic、exchange、type等一系列信息而不需要修改一行代碼。
發佈/訂閱模型
在Spring Cloud Stream中的消息通信方式遵循了發佈-訂閱模式，當一條消息被投遞到消息中間件之後，它會通過共用的 Topic 主題進行廣播，消息消費者在訂閱的主題中收到它並觸發自身的業務邏輯處理。這裡所提到的 Topic 主題是Spring Cloud Stream中的一個抽象概念，用來代表發佈共用消息給消費者的地方。在不同的消息中間件中， Topic 可能對應著不同的概念，比如：在RabbitMQ中的它對應了Exchange、而在Kakfa中則對應了Kafka中的Topic。
二、SpringCloud Config
1、配置中心概述
對於單體應用而言，常使用配置文件來管理所有配置，比如SpringBoot的application.yml文件， 但是在微服務架構中全部手動修改的話很麻煩而且不易維護。微服務的配置管理一般有以下需求：
集中配置管理，一個微服務架構中可能有成百上千個微服務，所以集中配置管理是很重要的。 不同環境不同配置，比如數據源配置在不同環境（開發，生產，測試）中是不同的。
運行期間可動態調整。例如，可根據各個微服務的負載情況，動態調整數據源連接池大小等配置修改後可自動更新。如配置內容發生變化，微服務可以自動更新配置。
綜上所述對於微服務架構而言，一套統一的、通用的管理配置機制是不可缺少的總要組成部分。常見的做法就是通過配置伺服器進行管理。
2、常見配置中心
Spring Cloud Config為分散式系統中的外部配置提供伺服器和客戶端支持。 Apollo（阿波羅）是攜程框架部門研發的分散式配置中心，能夠集中化管理應用不同環境、不同集群的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置管理場景。
3、Spring Cloud Config簡介
Spring Cloud Config項目是一個解決分散式系統的配置管理方案。它包含了Client和Server兩個部分， server提供配置文件的存儲、以介面的形式將配置文件的內容提供出去，client通過介面獲取數據、並依據此數據初始化自己的應用。
Spring Cloud Config為分散式系統中的外部配置提供伺服器和客戶端支持。使用Config Server，可以為所有環境中的應用程式管理其外部屬性。非常適合spring應用，也可以使用在其他語言的應用上。隨著應用程式通過從開發到測試和生產的部署流程，可以管理這些環境之間的配置，並確定應用程式具有遷移時需要運行的一切。伺服器存儲後端的預設實現使用git，因此它輕鬆支持標簽版本的配置環境，以及可以訪問用於管理內容的各種工具。
4、Spring Cloud Config
（1）概述
Config Server是一個可橫向擴展、集中式的配置伺服器，它用於集中管理應用程式各個環境下的配置， 預設使用Git存儲配置文件內容，也可以使用SVN存儲，或者是本地文件存儲。
（2）配置中心的高可用
在單機環境中，客戶端都是直接調用配置中心的server端來獲取配置文件信息。這樣就存在了一個問題，客戶端和服務端的耦合性太高，如果server端要做集群，客戶端只能通過原始的方式來路由， server端改變IP地址的時候，客戶端也需要修改配置，不符合springcloud服務治理的理念。 springcloud提供了這樣的解決方案，只需要將server端當做一個服務註冊到eureka中，client端去 eureka中去獲取配置中心server端的服務即可。
（3）消息匯流排bus
在微服務架構中，通常會使用輕量級的消息代理來構建一個共用的消息主題來連接各個微服務實例，它廣播的消息會被所有在註冊中心的微服務實例監聽和消費，也稱消息匯流排。 SpringCloud中也有對應的解決方案，SpringCloud Bus將分散式的節點用輕量的消息代理連接起來，可以很容易搭建消息匯流排，配合SpringCloud config 實現微服務應用配置信息的動態更新。
根據此圖可以看出利用Spring Cloud Bus做配置更新的步驟: 提交代碼觸發post請求給bus/refresh server端接收到請求併發送給Spring Cloud Bus Spring Cloud bus接到消息並通知給其它客戶端其它客戶端接收到通知，請求Server端獲取最新配置全部客戶端均獲取到最新的配置。
5、開源配置中心Apollo
（1）Apollo概述
Apollo（阿波羅）是攜程框架部門研發的分散式配置中心，能夠集中化管理應用不同環境、不同集群的 配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置 管理場景。服務端基於Spring Boot和Spring Cloud開發，打包後可以直接運行，不需要額外安裝 Tomcat等應用容器。 正是基於配置的特殊性，所以Apollo從設計之初就立志於成為一個有治理能力的配置發佈平臺，目前提供了以下的特性：
-
統一管理不同環境、不同集群的配置
- Apollo提供了一個統一界面集中式管理不同環境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。
- 同一份代碼部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
- 通過命名空間（namespace）可以很方便地支持多個不同應用共用同一份配置，同時還允許應用對共用的配置進行覆蓋
-
配置修改實時生效（熱發佈）
- 用戶在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程式
-
版本發佈管理
- 所有的配置發佈都有版本概念，從而可以方便地支持配置的回滾
-
灰度發佈
- 支持配置的灰度發佈，比如點了發佈後，只對部分應用實例生效，等觀察一段時間沒問題後再推給所有應用實例
-
許可權管理、發佈審核、操作審計
- 應用和配置的管理都有完善的許可權管理機制，對配置的管理還分為了編輯和發佈兩個環節，從而減少人為的錯誤。
- 所有的操作都有審計日誌，可以方便地追蹤問題
（2）Apollo的實現方式
上圖簡要描述了Apollo客戶端的實現原理：
1. 客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。
2. 客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。 這是一個fallback機制，為了防止推送機制失效導致配置不更新 客戶端定時拉取會上報本地版本，所以一般情況下，對於定時拉取的操作，服務端都會返回 304 - Not Modified 定時頻率預設為每5分鐘拉取一次，客戶端也可以通過在運行時指定System Property: apollo.refreshInterval 來覆蓋，單位為分鐘。
3. 客戶端從Apollo配置中心服務端獲取到應用的最新配置後，會保存在記憶體中。
4. 客戶端會把從服務端獲取到的配置在本地文件系統緩存一份 在遇到服務不可用，或網路不通的時候，依然能從本地恢復配置 5. 應用程式從Apollo客戶端獲取最新的配置、訂閱配置更新通知。
（3）Apollo中的幾個核心概念：
-
application (應用)
- 實際使用配置的應用，Apollo客戶端在運行時需要知道當前使用配置的應用，從而可以去獲取對應的配置；
- 每個應用都需要有唯一的身份標識 -- appId。
-
environment (環境)
- 配置對應的環境，Apollo客戶端在運行時需要知道當前應用所處環境，從而獲取應用的配置
- 所以環境預設是通過讀取機器上的配置（server.properties中的env屬性）指定的，也支持運行時通過System Property等指定。
-
cluster (集群)
-
一個應用下不同實例的分組，比如典型的可以按照數據中心分，把上海機房的應用實例分為一個集群，把北京機房的應用實例分為另一個集群。
-
對不同的cluster，同一個配置可以有不一樣的值，如zookeeper地址。
-
集群預設是通過讀取機器上的配置（server.properties中的idc屬性）指定的，不過也支持運行時通過System Property指定。
-
-
namespace (命名空間)
-
一個應用下不同配置的分組，可以簡單地把namespace類比為文件，不同類型的配置存放在不同的文件中，如資料庫配置文件，RPC配置文件，應用自身的配置文件等；
-
應用可以直接讀取到公共組件（公有）的配置namespace，如DAL，RPC等；
-
應用也可以通過繼承（引用）公共組件（公有）的配置namespace來對公共組件的配置做調整，如DAL的初始資料庫連接數；
- 私有namespace只有當前項目可以訪問。
-
github地址 https://github.com/ctripcorp/apollo
感謝閱讀，借鑒了不少大佬資料，如需轉載，請註明出處，謝謝！https://www.cnblogs.com/huyangshu-fs/p/13888671.html
