使用JMS在集群應用程序中分配任務(圖)

2019-11-18 12:23:22

字體：大中小

來源：轉載

供稿：網友

　　在請求驅動的環境中解耦合和延遲處理是創建健壯和可伸縮的分布式應用程序的要害戰略之一。許多服務都單獨依靠于集群來確保可伸縮性，但是當新發現的需求使應用程序的復雜性增長時，它們經常會碰到麻煩。
　　
　　盡管服務器集群是推動可伸縮性的基本技術，但是當所有的處理都同步完成時，它可能變得很低效。吞吐量可能會增加，但是響應性卻會變得不可救藥。
　　
　　在本文中，我討論了異步處理，并舉例說明了，巧妙的任務治理會如何提高您應用程序的性能、可用性、可伸縮性和可治理性。我們將以一種高度可配置的方式，創建一個一般的任務分配框架，該框架可以發送任何任務給您的集群中的一臺或每臺服務器。通過使用多態和 java 消息服務（ Java Message Service ， JMS ），我們的框架將實現聞名的 Command 模式。
　　
　　解耦合在實際中的意義
　　
　　當服務器收到客戶端請求時，它通常需要在返回響應之前執行幾個單獨的任務。解耦合（ decoupling ）意味著不會一次執行所有的任務，而是把一些任務放入隊列并異步地進行處理。因為排隊通常是一項低開銷的操作，同步的請求會更快地結束。
　　
　　解耦合的優點
　　
　　按照順序和并行地處理任務，通常會比隨機地處理它們要更加高效（客戶端偶然發出請求的時候）。正面的影響比隨即表現出來的要大。理論上，解耦合可以提高以下各個方面的性能：
　　
　　健壯性：提高，因為請求將依靠的可能失效的過程更少。
　　
　　響應性：請求的部分后處理減少了接收請求和返回響應之間的時間。
　　
　　可伸縮性：所有解耦合后的過程在復雜性方面可能會增加，但不會有降低響應度的危險。
　　
　　可用性：可以在服務器永遠不知道故障原因的情況下處理故障。
　　
　　在子系統不可用的情況下，配置自動重試要更加輕易。
　　
　　自然，理論與實踐之間的差別在每個應用程序上的體現各不相同。然而，顯然，幾乎每種實現都至少具有前述的某些優點。
　　
　　解耦合的缺陷
　　
　　和大部分好東西一樣，解耦合也存在缺點。其中最嚴重的缺點之一就是，假如您不能確保您擁有足夠強大的硬件來清空繁忙的處理隊列，那么您可能會發現，它的可用性實際上降低了。假如進入的異步請求比您的系統能夠處理的要多，隊列就會非常迅速地增長。您必須注重設計過程，而對隊列實行自動監控無疑是可取的做法。另一個明顯的問題是，在請求驅動的環境中，大多數過程都不是很適合于解耦合。事實上，大多數處理都可能被要求返回響應。有時，它會需要一些開箱即用的思想，甚至可能是您為您的客戶端所提供的服務方式的變化。
　　
　　哪些過程可以解耦合
　　
　　從純技術的角度來講，幾乎所有的過程都可以解耦合。例如，您可以把一個所購買物品及客戶具體信息的清單放入隊列，從而可以解耦合一個訂單事務——異步處理將負責余下的工作。不足之處在于您不能在響應中包含任何處理細節。因此，謹慎地預先驗證數據是很重要的，這樣可以確保不會出現問題。
　　
　　一種越來越流行的實現是，馬上把請求放入隊列，然后持續輪詢服務器，以便了解何時可以獲得響應。盡管這種方法在本質上實際是同步的，而且不會增加請求的處理時間，但是它在心理上具有優勢，因為可以在輪詢期間顯示進度條。
　　
　　除了解耦合完整的業務邏輯（這是一個巨大的難題）之外，更少的集中處理，比如日志記錄和發送電子郵件，是可以考慮的良好選擇。當性能變得及其重要時，沒有理由讓客戶端等待這種任務的完成。非凡的電子郵件是用于解耦合的一個良好選擇。讓我們做進一步的了解。
　　
　　實例研究:異步的電子郵件
　　
　　以傳統的方式發送電子郵件（作為同步請求的一部分）會引起一些問題。首先，連接到電子郵件服務器需要一次網絡往返，速度可能會很慢，尤其是在服務器非常繁忙的時候。過載的電子郵件服務器甚至可以使依靠于電子郵件的服務暫時不可用。
　　
　　XA 事務支持
　　
　　另一個顯而易見的問題是，電子郵件服務器通常在本質上是非事務性的。當事務被回滾時，這可以導致出現不一致的通知——把一條消息放入隊列之后不能取消它。幸運的是， JMS 支持事務，而且可以通過把消息的發送延遲到提交底層事務的時候來解決這個問題。
　　
　　考慮訪問數據庫和事務感知的 JMS 時，您將需要使用 XA 和兩階段提交（ 2PC ）事務。可以使用非 XA 資源來模擬 XA ，但是您可能會得到不一致的數據。啟用 XA 只是一個配置問題，而且通常不需要修改代碼。參見 WebLogic 文檔以獲得相關的具體信息。
　　
　　通過 JMS 發送電子郵件
　　
　　為了使用 JMS 來發送電子郵件，我們需要配置 JMS 組件（比如， JMS 服務器， JMS 隊列和連接工廠）。我們還需要編寫一個消息驅動 Bean （ Message Driven Bean ， MDB ）來執行信件的實際發送。當我們想要在我們的代碼中發送電子郵件時，需要創建一條包含信件的屬性和內容的 JMS 消息。之后，我們把它發送給處理隊列。
　　
　　這樣做的工作量很大！幸運的是， BEA WebLogic JMS 為我們提供了創建一個可以解耦合幾乎任何過程的框架所需的全部內容。
　　
　　用于異步執行的框架
　　
　　是動手看看一些代碼的時候了。我們將創建一個框架，這個框架支持在集群中的一臺或所有服務器上，異步地執行代碼的任何部分。實現起來的確需要花費些力氣，但是一旦框架完成，異步執行就是再輕易不過的事情了。
　　
　　這個思路是編寫一些類，這些類包含一個帶有可運行代碼的公共方法和另一個用于初始化參數的方法——可能是構造器。封裝在 JMS 對象消息中之后，這些預先編寫好的類的實例（命令消息）就被發送給在您的服務器上配置的 JMS 隊列。至此，消費者把它們取出，然后異步地執行它們（參見圖 1 ）。
　　使用JMS在集群應用程序中分配任務(圖)

　　讓我們逐個看看這個框架的所有部分：
　　
　　JMS 隊列：應該在每臺服務器上配置一個用于接收命令消息的 JMS 隊列。還應該為重復保存故障消息配置錯誤隊列。
　　
　　JMS 連接工廠：為了支持事務性行為的運行時選擇，應該配置兩個連接工廠：一個支持 XA ，而另一個不支持 XA 。
　　
　　命令對象接口 (CommandMessage) ：這是一個所有命令對象都需要實現的簡單 Java 接口。它擴展了 java.io.Serializable 接口，該接口對于在 JMS 對象消息中嵌入我們的命令來說是必需的。現在，因為我們想要在不知道命令的確切類型的情況下運行它們，我們還要實現 java.lang.Runnable 接口，稍后把它們簡單地轉換為 Runnable 對象，并執行它們的運行方法。我們在不知道我們運行的確切內容的情況下運行了代碼。這是最理想的多態。
　　
　　命令執行程序 (CommandExecutionManager) ：我們將使用一個 MDB 來處理命令。實例池化防止了 JMS 初始化重復出現，這使得 MDB 成為功能非常強大的消息監聽器，非常適合于這項任務。編寫 Bean 類不需要很大的工作量，我們只需要在 onMessage 方法中編寫數行代碼（參見清單 1 ）。
　　
　　這樣就把收到的消息傳遞給一個 ObjectMessage ，獲得嵌入的命令對象，然后執行它的運行方法。通過在 config.xml 文件中，把隊列的重新發送限制設置為一個大于 0 的值，您可以配置一個重試計數器。從您的命令對象拋出一個運行時異常，便可觸發重新發送的動作。此外，通過配置重新發送延遲，您還可以控制重試的頻率。
　　
　　用于發送消息的一個幫助器類 (TaskDistributor)
　　
　　從技術上說，這個部分并不是完全必要的，每次都可以手動進行 JMS 排隊。然而，這是一個冗長乏味的過程，而且實際上是幫助器使這個框架變得如此實用。幫助器是一個常規的 Java 類，帶有用于對命令消息進行排隊的靜態方法。您可以針對處理不同的場景編寫單獨的方法，但是為了簡明起見，我選擇了編寫一個可以處理大多數情況的方法：
　　
　　static void execute(CommandMessage cm, long delay, b oo lean runEverywhere, b oo lean persisted, b oo lean
　　enableXA, int PRiority)
　　
　　這個靜態方法帶有幾個用于精確執行控制的參數。讓我們逐個討論這些參數：
　　
　　CommandMessage cm ：一個命令消息實例。
　　
　　long delay ：代表發送屬性的時間，借助 weblogic.jms.extensions.WLMessageProdUCer 類進行設置。這樣，就可以在夜間或者其他方便的時間執行命令。接受一個 Date 對象也是可以的。
　　
　　b oo lean runEverywhere ：決定是否發送要執行的消息給集群中的一臺隨機選中的訪問器或者所有的服務器。
　　
　　b oo lean persisted ：將通過使用隊列發送程序的 setDeliveryMode 方法選擇發送模式。應該始終保持業務要害型的消息，從而在訪問器崩潰的時候，這些消息不會丟失。然而，持久性始終是以性能損失為代價的，這也應該納入考慮的范圍內。
　　
　　b oo lean enableXA ：將選擇方法是否使用支持 XA 的 JMS 連接工廠。此參數設置為 true 時，排隊將參與底層事務（假如存在的話），在提交事務之前不會對消息進行排隊。
　　
　　int priority ：決定消息的 JMS 優先級。在發送之前，將使用給定的值調用 javax.jms.Message 類的 setJMSPriority 方法。有效的范圍是 0-9 。對于大多數應用程序來說，給命令消息指派不同的優先級似乎有些過頭，但是出于完整性方面的考慮，我還是在這里包括了這個選擇。
　　
　　應該針對您的特定執行的需要，來量身打造 TaskDistributor 幫助器類的實現。在本文中，要包含一個例子似乎太長了，但是您可以從 WLDJ Web 站點 www.sys-con.

上一篇：關于J2EE層次設計架構實例分析詳解

下一篇：化繁為簡用Spring改進J2EE編程(圖)