Windows Azure Service Bus (1) 基礎


  《Windows Azure Platform 系列文章目錄

 

  我們在基於Windows Azure進行雲端開發的時候,雲端的軟件通常都需要與其他軟件進行交互。這些其他軟件可能包括其他Internet上的軟件,或者內網的軟件。

  對於內網的軟件來說,Azure提供Site-to-Site(S2S) VPN 和Point-to-Site(P2S) VPN的方式來打通Azure和內網應用程序之間的VPN連接。但是如果內網的應用程序使用了網絡地址轉換(NAT),S2S和P2S是無法支持在NAT背后的VPN Device。

Obtain an externally facing IPv4 IP for your VPN device. This IP address is required for a site-to-site configuration and is used for your VPN device, which cannot be located behind a NAT.

  在這種情況下,Windows Azure 提供的Service Bus功能可以幫助用戶解決以上的問題。

 

  Service Bus基礎

  Service Bus是一種多租戶的雲服務,這意味着該服務可以由多個用戶共享。每個用戶(如應用程序開發人員)創建一個命名空間,然后定義用戶在該命名空間內需要的通信機制。

  Service Bus運行的架構圖如下:

  

 

  在命名空間內,用戶可以使用三種不同通信機制的一個或者多個實例,每種機制使用不同方式連接應用程序。分別為:

  -隊列(Queue)。允許單向通信,每個隊列均充當一個中介(有時稱為代理),可存儲發送的消息,直到它們被接收為止。

  -主題(Topic)。使用訂閱 提供單向通信。主題與隊列一樣可充當代理,但主題僅允許每個訂閱查看符合特定條件的消息。

  -中繼(Relay)。提供雙向通信。與隊列和主題不同,中繼不存儲傳送中的消息,它不是代理。相反,中繼只是將消息傳遞到目標應用程序。

  當您創建隊列、主題或中繼時,請對其進行命名。結合您對命名空間的任何命名,此名稱可創建對象的唯一標識符。應用程序可將此名稱提供給 Service Bus,然后使用隊列、主題或中繼相互通信。

  

  若要使用任意這些對象,Windows 應用程序可使用 Windows Communication Foundation (WCF)。對於隊列和主題,Windows 應用程序還可使用 Service Bus 定義的消息傳遞 API。也可通過 HTTP 訪問隊列和主題,並且為了更輕松地通過非 Windows 應用程序使用它們,Microsoft 提供了 Java、Node.js 和其他語言的 SDK。

  即使 Service Bus 本身在雲(即 Microsoft Windows Azure 數據中心)中運行,使用它的應用程序也能隨處運行,了解這一點很重要。您可以使用 Service Bus 連接在 Windows Azure 上運行的應用程序或在您自己的數據中心內運行的應用程序。您也可以使用 Service Bus 通過本地應用程序或通過平板電腦和手機來連接在 Windows Azure 或其他雲平台上運行的應用程序。甚至可以將家用電器、傳感器和其他設備連接到中央應用程序或其他應用程序。Service Bus 是雲中的通用通信機制,幾乎可從任何位置對其進行訪問。使用 Service Bus 的方式取決於應用程序需要執行的操作。


隊列

假設您決定使用 Service Bus 隊列連接兩個應用程序。圖 2 說明了此情況。

Service Bus 隊列圖表

圖 2:Service Bus 隊列提供單向異步排隊方法。

  過程很簡單:發送方將消息發送至 Service Bus 隊列,接收方在隨后的某個時間內接收該消息。一個隊列只能有一位接收方,如圖 2 所示,或者多個應用程序可從同一隊列中讀取消息。在后一種情況下,每條消息通常僅由一位接收方讀取,隊列不提供多播服務。

  每條消息由兩部分組成:每個鍵/值對一組屬性和二進制消息正文。使用的方式取決於應用程序嘗試執行的操作。例如,發送近期銷售消息的應用程序可能包含屬性 Seller="Ava" 和 Amount=10000。消息正文可能包含已簽署的銷售合同的掃描圖像,如果不包含該合同,只需留空。

  接收方可采用兩種不同方式從 Service Bus 隊列中讀取消息。第一種方式稱作 ReceiveAndDelete,即,從隊列中移除消息並立即將其刪除。此操作很簡單,但如果接收者在完成處理消息之前崩潰,則該消息將丟失。因為消息已從隊列中移除,所以接收方無法訪問該消息。

  第二種方式 PeekLock 旨在幫助解決這個問題。與 ReceiveAndDelete 一樣,PeekLock 可從隊列中移除消息。不過,它不會刪除該消息。相反,它會鎖定該消息,使其對其他接收方不可見,然后等待以下三個事件之一:

  • 如果接收方成功處理了該消息,將調用“完成”,並且隊列將刪除該消息。
  • 如果接收方判定它無法成功處理該消息,將調用“放棄”。隊列即會解除對該消息的鎖定,使其可供其他接收方使用。
  • 如果接收方在可配置時間段(默認為 60 秒)內沒有調用這兩個命令,隊列將假定接收方失敗。在這種情況下,隊列的行為就像接收方已調用“放棄”一樣,即,使消息可供其他接收方使用。

  請注意,可能發生的情況:同一條消息可能被發送兩次,即,或許將其發送給兩個不同的接收方。使用 Service Bus 隊列的應用程序必須為此做好准備。為了更輕松地進行重復檢測,每條消息都擁有一個唯一的 MessageID 屬性,無論從隊列中讀取消息多少次,該屬性默認情況下始終保持不變。

  隊列在很多情況下都非常有用。即使兩個應用程序沒有同時運行,隊列也可使這兩個應用程序之間相互通信,這對於批處理和移動應用程序尤為方便。當所發送的消息傳播給多個接收方時,具有這些接收方的隊列還提供自動負載平衡。

 


主題

隊列雖然在一些情況下有用,但並非總是正確的解決方案。有時,Service Bus 主題更好。圖 3 說明了這一點。

Service Bus 主題和訂閱圖表

圖 3:根據訂閱應用程序指定的篩選器,它可接收發送至 Service Bus 主題的部分或全部消息。

  主題在很多方面與隊列類似。發送方將消息提交至主題的方式與將消息提交至隊列的方式相同,這些消息與使用隊列的消息看起來一樣。最大的區別是主題讓每個接收應用程序通過定義篩選器 創建其自己的訂閱。然后,訂戶將只能看到與該篩選器匹配的消息。例如,圖 3 顯示一個發送方以及一個具有三個訂戶的主題,每個訂戶都擁有自己的篩選器:

  • 訂戶 1 僅接收包含 Seller="Ava" 屬性的消息。
  • 訂戶 2 接收包含 Seller="Ruby" 屬性和/或值大於 100,000 的 Amount 屬性的消息。Ruby 或許是銷售經理,因此她希望查看她自己的銷售以及其他人做的所有大單銷售。
  • 訂戶 3 將其篩選器設置為 True,這意味着它將接收所有消息。例如,此應用程序可能負責維護和審核記錄,因此它需要查看全部內容。

  與隊列一樣,某主題的訂戶可使用 ReceiveAndDelete 或 PeekLock 讀取消息。不過與隊列不同的是,發送至主題的單個消息可由多個訂戶接收。此方法通常稱作發布和訂閱,在當多個應用程序對相同消息感興趣時非常有用。通過定義適當的篩選器,每位訂戶可以只訪問需要查看的消息流部分。

 


中繼

隊列和主題均通過代理提供單向異步通信。流量只按一個方向流動,發送方和接收方之間沒有直接連接。但如果您不希望這樣,該怎么辦?假設您的應用程序需要同時發送和接收消息,或者可能您希望應用程序之間進行直接鏈接,而不需要在某個位置來存儲兩者之間的消息。為解決此類問題,Service Bus 提供了中繼,如圖 4 所示。

Service Bus 中繼圖表

圖 4:Service Bus 中繼提供應用程序之間的同步雙向通信。

  關於中繼明顯要問的問題是:為何我要使用中繼?即使我不需要隊列,那么為什么要通過雲服務進行應用程序通信,而非直接交互?答案是直接對話比您想象的更艱難。

  假設您希望連接兩個本地應用程序,這兩個應用程序均在企業數據中心中運行。每個應用程序都位於防火牆之后,並且每個數據中心很可能使用網絡地址轉換 (NAT)。防火牆阻止幾乎所有端口上的傳入數據,並且 NAT 意味着運行每個應用程序的計算機很可能沒有固定 IP 地址。如果不借助一些額外的幫助,那么通過公共 Internet 連接這些應用程序會產生問題。

  Service Bus 中繼可提供此幫助。若要通過中繼進行雙向通信,每個應用程序需使用 Service Bus 建立出站 TCP 連接,然后一直保持打開狀態。將通過這些連接傳輸兩個應用程序之間的全部通信。由於每個連接均從數據中心內部建立,因此,防火牆將允許到每個應用程序的傳入流量(即通過中繼發送的數據),而無需打開新端口。此方法還能解決 NAT 問題,因為每個應用程序在整個通信中的終結點是一致的。通過中繼交換數據,應用程序可以避免導致通信困難的問題。

  為使用 Service Bus 中繼,應用程序依賴 Windows Communication Foundation (WCF)。Service Bus 提供 WCF 綁定,可使 Windows 應用程序通過中繼進行交互變得更加簡單。已使用 WCF 的應用程序通常只需指定其中一個綁定,即可通過中繼進行交互。不過與隊列和主題不同,從非 Windows 應用程序使用中繼(如有可能)需要一些編程工作;沒有標准庫提供。

  與隊列和主題不同,應用程序不會顯式創建中繼。相反,當希望接收消息的應用程序與 Service Bus 建立 TCP 連接時,會自動創建中繼。當該連接中斷時,將刪除該中繼。為了讓應用程序能夠找到由特定偵聽程序創建的中繼,Service Bus 提供了允許按名稱定位特定中繼的注冊表。

  當您需要直接通信時,中繼是正確的解決方案。例如,在本地數據中心中運行的航空訂票系統,可從值機櫃台、移動設備和其他計算機上訪問該系統。在所有這些系統上運行的應用程序都可能依賴雲中的 Service Bus 中繼進行通信,無論它們在哪里運行。

  連接應用程序始終屬於構建完整解決方案的一部分,很難看到此問題永遠消失。通過提供可實現此目的的基於雲的技術(即隊列、主題和中繼),Service Bus 旨在讓此基本功能更加簡單且使用范圍更加廣泛。

 

  參考資料:http://www.windowsazure.cn/zh-cn/develop/net/fundamentals/hybrid-solutions/#Fig2


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM