正如我在上 一篇 文章中所討論的那樣 ,Spring Integration(SI) 是在Spring Framework之上構建的路由框架 ,它使您可以使用經過驗證的企業集成模式來通過消息傳遞解決系統集成問題。 配置好SI并執行路由和中介邏輯后,您可能會發現您想采取下一步措施,并為解決方案增加更多的穩定性 。
您可能希望將某些路由,中介或服務邏輯分布在多個主機上,可能希望為通過SI通道傳輸的消息增加一些可靠性,并且可能希望比采用傳統的客戶端-服務器體系結構。 好吧,實現上述某些目標的一種方法是使用消息代理來支持您的SI路由。 SI為AMQP代理和JMS代理提供抽象。 在本文中,我想使用Spring Integration Samples項目中的Cafe示例來說明如何使用流行的ActiveMQ消息代理通過JMS支持您的SI路由。
JMS是將現有Java解決方案與消息傳遞集成的好方法。 由于JMS規范是一個API,因此無論您使用的是哪個代理,都可以充分利用依賴于代理的接口。 您可以使用ActiveMQ,WebSphere MQ或任何其他符合JMS的消息代理。 在本示例中,我選擇ActiveMQ是因為它的成熟度,健壯性,在行業中的普遍性以及它是具有Apache許可的Apache Software Foundation的開源軟件。 它完全實現了JMS 1.1,提供了高可用性,并且可以通過代理網絡進行水平擴展。 如果要集成Java應用程序,請堅持使用JMS。 ActiveMQ還為C ++,C#,Ruby,Python,Erlang和其他許多應用程序提供綁定( 完整列表請參見其網站 )
注意,AMQP也是可行的選擇。 AMQP指定了一種線級協議,該協議允許在不同平臺和/或異構語言上構建的消息傳遞系統彼此進行互操作(不只是可以使用JMS API的java / JVM)。 Cafe演示已經實現了與Spring的RabbitMQ服務器(Spring產品組合中的流行開源AMQP代理)一起使用的AMQP實現。
有關AMQP和JMS之間區別的更多信息,包括它們如何工作,各自使用的不同術語以及兩者的簡要歷史記錄, 請參閱Mark Richards ( Java消息服務書的作者之一) 撰寫的這篇出色的PDF文章。 (來自O'Reilly)
可以在我在github.com 上的Spring Integration Samples項目的分支版本中找到與該帖子相關的代碼。 查看/ applications / cafe maven模塊以獲取我的代碼。 ?
使用點對點或發布-訂閱JMS目標支持頻道
在我的示例中,我選擇使用嵌入式代理 。 由于ActiveMQ是純Java解決方案,因此您可以將代理嵌入Java應用程序中并在內部使用它,并允許外部客戶端連接并參與消息傳遞。 這樣做不會以任何方式限制您配置ActiveMQ的能力。 使用自己的嵌入式代理部署完整的集成解決方案要比依靠(由另一個組?)或在外部配置外部實例更容易。
基于ActiveMQ的解決方案的所有spring配置文件可以在/ src / main / resources下的META-INF / spring / integration / activemq類路徑中找到。
與支持具有JMS目標的SI通道有關的文件是cafeDemo-amq-config.xml和cafeDemo-amq-jms-backed.xml 。 cafeDemo-amq-config.xml文件負責配置與ActiveMQ代理的連接。 連接工廠的名稱非常重要,在本例中為“ connectionFactory”,因為SI缺省情況下將查找具有該名稱的bean,以配置稍后由JMS支持的通道使用的目的地。
cafeDemo-amq-jms-backed.xml文件看起來與cafe示例的非經紀人實現( cafeDemo-xml.xml )非常相似,不同之處在于通道已轉換為JMS支持的版本,并且ActiveMQ代理是嵌入其余配置。 請注意,用于嵌入代理的方法允許在spring文件中進行完整配置。對于此示例,不依賴于外部運行的代理。 這個小示例的配置僅設置了一個傳輸連接器(在默認端口61616上,我們可以使用vm:// transport ,但是我想顯示一個使用TCP的示例),并且未配置代理安全性,目標策略但是,它的確利用了現成的配置詳細信息,包括JMX管理MBean,以及通過推薦并高度優化的KahaDB進行的消息持久性。 有關更多信息,請參見ActiveMQ文檔。
在原始配置中,將用于“ coldDrinks”和“ hotDrinks”的通道設置為輪詢通道。 要使用JMS目標完成此操作,請將通道上的“消息驅動”屬性設置為“ false”。 在這種情況下,我們不需要提前聲明目的地名稱,但是如果您想在目的地周圍添加額外的安全性和授權屬性,則不妨在代理上或通過代理提前創建它們。 SI配置。 運行此樣本的主要類是org.springframework.integration.samples.cafe.xml.CafeDemoActiveMQBackedChannels 。
觀察是否確實在使用ActiveMQ的最佳方法是運行該示例,并使用JConsole復審JMX服務器中的MBean。 在JConsole中,您確實可以看到消息正在通過隊列入隊和出隊,和/或從主題中使用。 要測試使用ActiveMQ獲得的魯棒性,請嘗試運行示例并中途中止它。 然后注釋掉主文件中添加訂單到系統的行,然后重新啟動示例。 當異常終止時,它將繼續處理從其中斷處開始的處理。 只需更改通道的幾行配置,即可獲得可靠性和恢復能力。 ?
如何在不同的服務器上或至少在同一JVM外部運行路由的不同部分呢?
這使您可以添加路由的特定部分的更多實例,以提高吞吐量和可伸縮性,而無需進行任何代碼更改(其他優點)。 只需將更多消費者吸引到隊列/主題即可。 兩種概念都可以在SI流程內(僅使用SI通道)使用,也可以在其流程外(使用JMS)使用。
為了證明這一點,我們將使用SI提供的JMS入站/出站網關和/或通道適配器。 使用JMS網關,我們可以實現請求-答復消息交換,而通道適配器則允許我們使用異步語義來激發和忘記。
該示例的設置方法與AMQP示例的設置方法相同,它也依賴于外部運行的代理(盡管我們可以如上所述嵌入它)。 首先,運行運行消費者(CafeDemoAppBaristaColdActiveMQ,CafeDemoAppBaristaHotActiveMQ),以監聽冷飲或熱飲訂單。 接下來,啟動負責主要流程和業務流程的流程(CafeDemoAppOperationsActiveMQ)。 編排流程處理接單,將訂單分流,將其路由到適當的服務(上面的冷熱咖啡Baristas),然后處理響應并匯總以供服務員交付。 在這里,您將看到正確設置的JMS網關。 最后,您需要運行將訂單發送到訂單隊列(CafeDemoAppActiveMQ)實際啟動訂單的過程。
所有這四個過程都彼此獨立運行,并且在必要時可以在單獨的計算機上運行。 它們具有自己的應用程序上下文,并且僅對ActiveMQ消息代理可見。 這是一個高度模塊化且解耦的解決方案,使用消息代理進行可靠的通信。 如上所述,可以將代理配置為具有高可用性,因此這不是故障點。
這種架構的優點:
- 消息可靠性–消息代理存儲和轉發消息。 郵件最多只能發送一次。 如果代理崩潰,以前未發送的消息將保留,并且如果消費者沒有收到,則可以重新發送
- 靈活性–通過分離組件并依靠EIP,您可以彼此獨立維護,包括部署,增強功能等
- 限制或增加消息處理–組件在自己/獨立的進程或盒子或世界各地運行,您可以配置每個組件以消耗或限制消息,具體取決于環境可以處理的數量
- 擴展–為了處理更高的吞吐量,只需添加更多組件實例以偵聽JMS目標
缺點:
- 復雜性–將多個組件打包到一個流程中,維護多個組件更為復雜
- 調試–復雜性增加,調試困難。 異步過程天生就很難調試
看一下我的github repo中的Spring Integration示例 。 完整記錄了用于配置ActiveMQ連接的應用程序上下文文件。
參考: Christian Posta軟件博客中的JCG合作伙伴 Christian Posta從ActiveMQ支持Spring集成路由 。
翻譯自: https://www.javacodegeeks.com/2012/05/backing-spring-integration-routes-with.html