訊息中介軟體MQ企業級方案設計，第1部分：非同步通訊與負載均衡

本系列以使用 IBM 大型機伺服器的客戶為主要物件，探討如何應用 WebSphere MQ 的特性來實現企業級應用的業務需求。本文是第 1 部分，將為大家介紹非同步通訊與同步通訊的特點以及如何設計具有高可用性和負載均衡能力的 MQ 方案。

引言

Websphere MQ 是 IBM 功能強大的訊息傳送中介軟體產品，它以其成熟的技術和世界領先的產品向我們提供了的功能豐富、可靠易用的異構平臺間實現可靠資訊傳遞的成熟解決方案。使用 MQ 訊息傳遞產品可以幫助業務應用在不同種類平臺上交換資訊，以訊息的方式接收、傳送資料，從而實現企業應用整合。MQ 遮蔽了異構軟硬體平臺和網路協議的複雜性，確保“訊息到達並且僅到達一次”的可靠的訊息傳遞，滿足高可靠性的、高效能的、安全可靠的穩定資訊資料傳輸要求，並具有開放性、擴充套件性、先進性、安全性、可管理性和易於維護開發等特性。依靠這些優勢，MQ 在訊息類中介軟體市場上佔有統治地位，已經成為事實上的行業標準，在企業的各類應用中承擔了可靠的資訊資料傳輸的基礎支撐。MQ 是為能夠支撐大型企業的海量資訊傳輸而設計的，它設計了很多應用特性，為企業級應用提供支援，這些特性分散在系統設計和應用程式設計的各種細節之處。本系列以使用 IBM 大型機伺服器的客戶為主要物件，對非同步通訊與同步通訊、MQ 高可用性及負載均衡方案、MQ 的安全性實現、MQ 與傳統 CICS 應用的連線、使用 MQ 實現 SOA 服務、MQ 應用效能監控和企業級應用設計構架等幾個方面探討如何應用 MQ 的特性實現企業級應用的業務需求。本文是本系列的第 1 部分，將為大家介紹非同步通訊與同步通訊的特點與設計考慮以及 MQ 高可用性及負載均衡方案。

非同步通訊與同步通訊

非同步通訊與同步通訊的特點

MQ 在支援同步通訊的同時，提供了基於訊息佇列儲存 - 轉發機制的非同步通訊模式，應用程式只需將訊息交給 MQ，就由 MQ 負責將訊息安全、可靠地傳送出去，不再需要應用和人工的干預，真正實現了資料傳輸自動化，這一特點能夠使應用程式獨立於通訊對方和網路的可用性。與我們常見的同步通訊相比，非同步通訊模式有以下特點：

• 通訊的達成只依賴於傳送方和訊息中介軟體，接收方以及網路的意外情況不造成影響。
• 因為不必實現同步握手，非同步通訊通常效率更高。
• 因為不必等待響應，非同步通訊傾向於實現更短的交易處理，節省系統資源佔用。
• 非同步通訊有利於提高系統併發度，提高系統吞吐能力。
• 非同步通訊有利於實現鬆散耦合的系統結構。

與非同步通訊相比，同步通訊想法更為簡單而且更容易實現――發起方在系統中等待直到對方響應，這樣可以避免複雜的傳送 / 確認 / 重傳機制的設計，但同時也造成了低效率和對資源佔用大的缺點，同步通訊目前是一種常見的廉價通訊實現方式。

需要說明的是這裡談論的同步 / 非同步是底層訊息傳輸的模式，與其最終提供的服務模式無關：同步業務服務可以通過同步通訊實現，也可以通過非同步通訊實現。比如我們常見的電話業務，一般我們都認為是一種同步的服務，但電信公司實際實施時，如果是通過交換機，在通話雙方之間建立一個電路連線，那就是一種同步通訊實現；如果電信公司採用的是 IP 電話，通過網路把聲音打成若干資料包在 Internet 上傳送，在收話方沒有感覺到的時間內再按順序組合把語音還原出來，那就是使用的非同步底層通訊實現。我們進行應用方案設計時要充分意識到兩種通訊模式的特點，考慮各種選擇的可能性和優劣。

非同步通訊實現同步應用設計

由於同步 / 非同步通訊有各自的特點，所以通過非同步通訊來實現同步應用時，有一些特殊的方法需要考慮。非同步通訊基礎上實現同步應用，是通過若干非同步訊息分段實現的，以最簡單的雙方模式為例，A 傳送給 B 一個非同步訊息，B 接收後完成特定處理，再返回給 B 一個非同步訊息，如果這個處理過程足夠快，就能夠實現一個請求 / 應答模式的同步應用。這種模式下，應用中 UOW 的範圍，和同步應用下是有很大不同的，應用設計中要充分考慮到這種區別。

在同步模式下，在 A 和 B 的所有操作都可以放在一個 UOW 中，通過兩階段提交協議實現資料一致；在非同步模式，應用會分成幾個 UOW，第一個是應用程式在本地佇列管理器中的操作，第二個是兩個佇列管理器間的資料傳輸，這個 UOW 是系統完成的，對於應用是透明的，第三個 UOW 是遠端應用在遠端佇列管理器中的操作。應用設計時要充分意識到這些區別。

由於交易一致性控制，一個 MQ 應用中在佇列中進行的改變，只在它 COMMIT 後，其他應用程式才能看到，所以在進行請求 / 應答模式的 MQ 應用程式中，請求程式傳送請求訊息後，要在適當的位置下 COMMIT，完成這個 UOW，然後在到應答佇列裡去等待對方完成 UOW 後的返回。應答程式也要與請求程式類似，也要合理地控制 UOW 的範圍，使得返回訊息能夠恰當地被請求程式得到。

在使用 MQ 進行要求同步通訊的程式設計時，會碰到原來可能會做單一 UOW 的應用，在 MQ 下的非同步應用設計下要劃分成若干個 UOW，這就涉及到如何在多 UOW 下保證資料整體的一致性。這種需求，一般可以通過合理的衝正設計來實現。

MQ Server 與 Client

MQ 產品分為 Server 和 Client 兩種版本，在 MQ Server 的執行環境下，有佇列管理器、佇列、訊息通道等物件，它提供全面的訊息服務；MQ Client 本身沒有佇列管理器、佇列等物件，它通過 MQI 通道與伺服器之間建立通訊，並將訊息從客戶端發往伺服器端的佇列，或從 Server 端的佇列中取得訊息，其他功能也比 Server 有限。MQ Client 與 Server 之間的通訊是同步模式完成的，它必須在 Server 正在工作並且可以通過網路訪問的情況下才能完成任務。MQ Client 通常在有大量末端環境的應用系統中採用，可以通過這種方式來節省成本，但要求在 Client 到 Server 之間要有比較可靠的網路連線。

MQ 高可用性及負載均衡方案

大型企業應用方案，在功能性要求之外系統高可靠效能力與負載均衡能力是一個十分重要的衡量指標。MQ 在這方案提供了很強的特性，主要通過兩種主要技術實現：MQ Cluster 技術和 Queue Sharing Group 技術。Cluster 技術可以在各種系統平臺上甚至跨平臺實施，能夠提供基本的高可用效能力，Queue Sharing Group 只能在 IBM System z 主機平臺上實現，能夠提供最高階的高可用效能力。

MQ Cluster 方案

MQ Cluster 結構與特點

使用 Queue Manager Cluster 技術，可以把安裝在不同平臺（如 AIX，LINUX，WINDOW，z/OS）上的若干個 Queue Manager 設計為一個叢集，每個 Queue Manager 都建立成叢集中的一員。叢集中有一個或多個 Queue Manager 可以定義成擁有整個叢集的物件定義資訊，稱作 Repository queue manager。當使用者在叢集中建立一個接收通道或佇列時，系統會自動在其他佇列管理器中建立相應的傳送通道和遠端佇列定義。不論整個叢集中有多少 Queue Manager，每個 Queue Manager 只要建立一個接收通道，和一個指向 Repository queue manager 的傳送通道就可以完成訊息連通，而不必要針對每個 queue manager 分別定義通道；同時每個 Queue Manager 也不必要定義遠端所有用到的遠端 Queue.

圖１ MQ Cluster 叢集

通過 Cluster 技術，可以有效地減少系統的管理工作，更快地建立應用同時可以提高系統的可用性並可以在叢集 MQ 管理器間實現負載均衡。

減少系統的管理工作主要體現在 :

• 不論連線多少遠端佇列管理器，只要建一個叢集傳送通道和一個叢集接收通道，不必為每個管理器分別建立通道
• 每個佇列管理器只要建立一個 transmission queues。
• 不必一一定義遠端佇列，可直接使用

使用 Cluster 技術提高系統的可用性和實現負載均衡，是通過在 Cluster 內的不同 QMGR 上建立同名的 Queue（同一個 Queue 的多個例項）來實現的。每個 Queue 的例項都能作為訊息的目的地，MQ 能夠在依照一定的演算法決定實際訊息應當傳給哪個 QMGR。這樣當叢集裡某個 QMGR 失效時，訊息會自動路由到其他活動的 QMGR 管理的例項上去。

典型部署模式

在實際應用 Cluster 技術時，一般採取如下的部署方案：

圖２ MQ Cluster 的典型部署模式

在 Cluster 中首先設計一臺 MQ 伺服器作為整個 Cluster 的閘道器，作為對外的連線點，它本地並不定義任何輸入（Inbound）佇列（如上例中的 Q1），只定義輸出（Outbound）佇列（如上例中的 Q2）。另外設定若干訊息處理伺服器，其中定義本地的輸入佇列，同時有訊息處理程式在執行。在外部交易進入 Cluster 時首先傳送到閘道器機上，由閘道器動態地傳送到 Cluster 裡定義了輸入佇列的 MQ 伺服器上去。MQ 閘道器可以根據設定，按照輪循或權重的方式對進入的訊息進行分發，還可以通過出口程式（User Exit）實現更加複雜的分發機制。

在每個訊息處理伺服器都部署有完全相同的應用處理程式，它們讀取輸入佇列裡的訊息，經過處理後把結果寫入輸出佇列。輸出佇列只定義在 MQ 閘道器機器上，任何訊息處理伺服器寫出的訊息都回最終傳送到閘道器上。前臺程式連線閘道器，讀取返回結果。

為了獲得更高可用性，這個方案中有兩點需要注意：1. 可以看到 MQ 閘道器是個單點隱患，為了更高可用性，要使用 HACMP 等方案實現備份。2. 如果訊息處理伺服器上的應用程式意外停止執行，資料會在佇列中堆積起來，為了避免這種情況，需要自動指令碼在應用程式停止時自動把 MQ 停止，這樣後來的訊息會發給其他伺服器處理。

網路層負載均衡器與 MQ

一些企業中，經常使用 F5 之只類的網路層負載均衡器來實現一種高可靠性 / 負載均衡解決方案。很多應用可以依靠 F5 實現的動態 IP 地址功能，在不改變應用程式的情況下實現高可用性，這為無狀態的網路應用提供了方便的均衡手段。但是 MQ 產品為實現訊息到並且只到一次，在收發雙方的傳送通道和接收通道上要傳遞記數和確認資訊，這樣以來傳送和接收方必須有固定的一對一關係，如果在中間網路上配置了網路層的負載均衡器，由於它不知道這種機制的存在，必然造成通訊的錯亂，所以在使用 MQ 的網路環境中不能夠同時使用網路層的負載均衡裝置。

主機 MQ 特有高可用性技術 -Queue Sharing Group 設計

Queue-Sharing Group 技術介紹

Shared Queue Group 是 MQ 依託 System z 主機的 Parallel Sysplex 技術而實現的高階特性。Shared queue 是一種本地佇列，shared queue 裡儲存的資料可以被同一個 Sysplex 裡的若干個 QMGR 共同訪問。能夠訪問同一個 shared queue 的所有 QMGR 稱為一個 queue-sharing group，它們可以訪問同一組 shared queues。 Shared queue 的資料儲存在 Coupling Facility 的 list structures 裡面，一個 Group 裡的所有佇列管理器都能夠從這個佇列裡讀取資料和傳送資料。

圖３MQ Queue Share Group

Shared queue 的定義被所有 QMGR 共享，共享的佇列定義是存放在 DB2 的表裡，在一個群裡，佇列只要定義一次，就能被所有的 QMGR 共享。Queue-sharing group 裡的每個 QMGR 都有與一個 DB2 系統相連，這些 DB2 系統必須在一個 data-sharing group 裡，這樣 QMGR 才能夠訪問相同的共享佇列定義。

在主機上使用 Queue Share Group 技術，結合 Sysplex 提供的系統功能（如 SYSPLEX Distributor 和 VTAM generic resources），MQ 除了可以實現應用處理上的高可用性，還能夠提供網路接入和送出的高可用性，這是通過 MQ 的 Shared channel 來實現的。

圖４ MQ 共享通道

共享的接入通道 ： Queue-sharing group 裡的每個 MQ Server 的 channel initiator 都在同一個 IP 埠監聽訊息，這個埠通過 Sysplex 提供的網路技術對外做成一個 generic port。這樣分散式系統 MQ Channel 的連線請求會被分發到任意一個 MQ Server 上，只要 Group 裡還有一個 Server 能夠響應，就能夠完成訊息向 Shared Queue 裡的傳送。

共享的外傳通道 ：如果一個傳送通道的 transmission queue 定義為共享的 Shared Queue，那麼這個通道就是共享的外傳通道。Group 裡的任意一個 QueueManger 都可以從共享的 transmission queue 裡取得資料向外傳輸，這樣只要還有一個 QM 有響應，這個通道對外就是暢通的。

Shared queue 技術使 MQ 在應用上具有以下優點：

• Scalability

應用處理能力能夠很方便地進行擴充套件，只要新增一個 QMGR，甚至新增一個 z/OS image 並在上面建立 QMGR 和應用程式，就能很好地擴大系統處理能力。

• Availability

多個 QMGR 可以訪問同一個 Queue，單個 QMGR 的故障不影響 Shared queue 的應用。MQ 通過 peer recovery 技術，可以監控 QMGR 的非正常中斷，能夠自動回滾未完成的 ULW。

• Workload balance

利用 SYSPLEX 的負載均衡功能，可以在多個 QMGR 間平衡處理量。

Queue Share Group 技術的優勢

Cluster 技術和 Share Queue 技術為實現可靠性、擴充套件性和均衡，使用的基本手段是不同的：

• Queue Manager Cluster

Queue Manager Cluster 使用的是同名佇列的多個例項，就是在 Cluster 裡的多個 QMGR 上建立相同的 Queue。進入這個佇列的資料會轉發給某個 QMGR，一旦資料進入這個 QMGR，就只能由這個 QMGR 訪問。

• Queue-Sharing Group

Queue-Sharing Group 使用的是一個共享的佇列，佇列的資料儲存只有一份，可以由多個 QMGR 共同訪問。

拋開 zSeries 對其他開放平臺的系統優勢不談，由於這個基本手段本質的不同，使得兩種技術提供的服務水平有很大不同：

• Cluster 只在訊息進入時實現高可用性，一旦訊息進入某個 QMGR，它就只能由那個 QMGR 處理，如果在訊息被處理完之前，系統發生故障，已經進入這個 QMGR 的資料將不能被處理。而使用 Shared queue 時，一個 QMGR 失敗不會影響佇列裡的資料。
• Queue Manager Cluster 時一旦資料進入某個 QMGR，就只能被這個 QMGR 訪問，如果某個系統上的 QMGR 正常，但處理 MQ 訊息的應用程式發生故障停止執行，訊息還會繼續傳送到這個 QMGR 裡去，但這些訊息就會積壓在這裡不會得到處理。在 Shared queue 時，由於 QMGR 使用的是同一個佇列，如果某個 QMGR 後面的應用程式停止工作，訊息會被其他 QMGR 後面的應用程式處理，不會對整個應用造成任何影響。
• Share Queue 是在 Work Load Manager 協調下完成負載均衡的，其負載均衡能力比 Cluster 內帶的邏輯要更加強大。Cluster 只能根據訊息進入叢集時的負載情形轉發訊息，而 Share Queue 能在訊息處理過程中動態地平衡負載。
• 考慮訊息進入時的情況，對於 Cluster，傳送方必須指定傳送到 Cluster 裡做 Gateway 的機器的 IP 地址上，一旦這臺機器失效，雖然這個 Queue 的其他 QMGR 還在，訊息卻不能進入 Cluster，存在單點故障隱患；對於 Share Queue，通過 SYSPLEX Distributor 等技術，傳送到特定 IP 地址的資料，可以被路由到任何一臺機器，單個機器失效，不會造成影響。

結束語

本文是本系列的第 1 部分，為大家介紹了非同步通訊與同步通訊的特點與設計考慮以及 MQ 高可用性及負載均衡方案，下面幾節將繼續為大家介紹 MQ 的安全性實現 ,MQ 與傳統 CICS 應用的連線 , 使用 MQ 實現 SOA 服務 ,MQ 應用監控以及企業級應用設計構架技術方案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-406844/，如需轉載，請註明出處，否則將追究法律責任。