1. 程式人生 > >Spring Cloud學習筆記27——訊息匯流排:Spring Cloud Bus

Spring Cloud學習筆記27——訊息匯流排:Spring Cloud Bus

訊息匯流排

在微服務架構的系統中,我們通常會使用輕量級的訊息代理來構建一個共用的訊息主題讓系統中所有微服務例項都連線上來,由於該主題中產生的訊息會被所有例項監聽和消費,所以我們稱它為訊息匯流排。

在總線上的各個例項都可以方便地廣播一些需要讓其他連線在該主題上的例項都知道的訊息,例如配置資訊的變更或者其他一些管理操作等。

由於訊息匯流排在微服務架構系統中被廣泛使用,所以它同配置中心一樣,幾乎是微服務架構中的必備元件。Spring Cloud作為微服務架構綜合性解決方案,對此自然也有自己的實現,也就是Spring Cloud Bus。通過使用Spring Cloud Bus

,可以非常容易地搭建起訊息匯流排,同時實現了一些訊息匯流排中的常用功能,比如,配合Spring Cloud Config實現微服務應用配置資訊的動態更新等。

訊息代理

訊息代理(Message Broker)是一種訊息驗證、傳輸、路由的架構模式。它在應用程式之間起到通訊排程並最小化應用之間的依賴的作用,使得應用程式可以高效地解耦通訊過程。訊息代理是一箇中間件產品,它的核心是一個訊息的路由程式,用來實現接收和分發訊息,並根據設定好的訊息處理流來轉發給正確的應用。它包括獨立的通訊和資訊傳遞協議,能夠實現組織內部和組織間的網路通訊。設計代理的目的就是為了能夠從應用程式中傳入訊息,並執行一些特別的操作。

當前版本的Spring Cloud Bus僅支援兩款中介軟體產品:RabbitMQKafka

RabbitMQ

RabbitMQ是實現了高階訊息佇列協議(AMQP)的開源訊息代理軟體,也稱為面向訊息的中介軟體。

AMQPAdvanced Message Queuing Protocol的簡稱,它是一個面向訊息中介軟體的開放式標準應用層協議,它定義了以下這些特性:

  • 訊息方向
  • 訊息佇列
  • 訊息路由(包括點到點和釋出-訂閱模式)
  • 可靠性
  • 安全性

AMQP要求訊息的提供者和客戶端接收者的行為要實現對不同供應商可以用相同的方式(比如SMTP

HTTPFTP等)進行互相操作。在以往的中介軟體標準中,主要還是建立在API級別,比如JMS,集中於通過不同的中介軟體實現來建立標準化的程式間的互操作性,而不是在多箇中間件產品間實現互操作性。

RabbitMQAMQP協議實現,所以它可以支援多種作業系統、多種程式語言,幾乎可以覆蓋所有主流的企業級技術平臺。在微服務架構訊息中介軟體的選型中,它是一個非常適合且優秀的選擇。因此,在Spring Cloud Bus中包含了對Rabbit的自動化預設配置。

基本概念

  • Broker:可以理解為訊息佇列伺服器的實體,它是一箇中間件應用,負責接收訊息生產者的訊息,然後將訊息傳送至訊息接收者或者其他的Broker
  • Exchange:訊息交換機,是訊息第一個到達的地方,訊息通過它指定的路由規則,分發到不同的訊息佇列中去。
  • Queue:訊息佇列,訊息通過傳送和路由之後最終到達的地方,到達Queue的訊息即進入邏輯上等待消費的狀態。每個訊息都會被髮送到一個或多個佇列。
  • Binding:繫結,它的作用就是把ExchangeQueue按照路由規則繫結起來,也就是ExchangeQueue之間的虛擬連線。
  • Routing Key:路由關鍵字,Exchange根據這個關鍵字進行訊息投遞。
  • Virtual host:虛擬主機,它是對Broker的虛擬劃分,將消費者、生產者和它們依賴的AMQP相關結構進行隔離,一般都是為了安全考慮。比如,我們可以在一個Broker中設定多個虛擬主機,對不同使用者進行許可權的分離。
  • Connection:連線,代表生產者、消費者、Broker之間進行通訊的物理網路。
  • Channel:訊息通道,用於連線生產者和消費者的邏輯結構。在客戶端的每個連線裡,可建立多個Channel,每個Channel代表一個會話任務,通過Channel可以隔離同一個連線中的不同互動內容。
  • Producer:訊息生產者,製造訊息併發送訊息的程式。
  • Consumer:訊息消費者,接收訊息並處理訊息的程式。

Kafka

Kafka是一個由LinkedIn開發的分散式訊息系統,它於2011年年初開源,現在由著名的Apache基金會維護與開發。它是基於訊息釋出-訂閱模式實現的訊息系統。

基本概念

  • BrokerKafka叢集包含一個或多個伺服器,這些伺服器被稱為Broker
  • Topic:邏輯上同RabbitMQQueue佇列相似,每條釋出到Kafka叢集的訊息都必須有一個Topic。(物理上不同Topic的訊息分開儲存,邏輯上一個Topic的訊息雖然保存於一個或多個Broker上,但使用者只需指定訊息的Topic即可生產或消費資料而不必關係資料存於何處。)
  • PartitionPartition是物理概念上的分割槽,為了提供系統吞吐率,在物理上每個Topic會分成一個或多個Partition,每個Partition對應一個資料夾(儲存對應分割槽的訊息內容和索引檔案)。
  • Producer:訊息生產者,負責生產訊息併發送到Kafka Broker
  • Consumer:訊息消費者,向Kafka Broker讀取訊息並處理的客戶端。
  • Consumer Group:每個Consumer屬於一個特定的組(可為每個Consumer指定屬於一個組,若不指定則屬於預設組),組可以用來實現一條訊息被組內多個成員消費等功能。