spring mvc拆分

健壯是什么意思？

在本文的上下文中，健壯性是指在不立即返回給調(diào)用者的情況下管理流中的異常條件的能力。 在某些處理方案中， n個(gè) m個(gè)回答足以做出結(jié)論。 通常具有這些趨勢(shì)的示例處理場(chǎng)景是：

財(cái)務(wù)，保險(xiǎn)和預(yù)訂系統(tǒng)的報(bào)價(jià)。

扇出出版系統(tǒng)。

為什么我們需要魯棒的分離器聚合器設(shè)計(jì)？

首先，可能需要對(duì)典型的Splitter Aggregator模式進(jìn)行介紹。 拆分器是一種EIP模式，它描述了一種機(jī)制，用于將復(fù)合消息分解為多個(gè)部分，以便可以分別處理它們。 路由器是一種EIP模式，用于將消息路由到各個(gè)通道中-將它們瞄準(zhǔn)特定的消息傳遞端點(diǎn)。 聚合器是一種EIP模式，用于整理和存儲(chǔ)屬于一個(gè)組的一組消息，并在該組完成后釋放它們。

這三個(gè)EIP構(gòu)造共同構(gòu)成了一種強(qiáng)大的機(jī)制，可將處理劃分為不同的工作單元。 Spring Integration（SI）使用與EIP相同的模式術(shù)語(yǔ)，因此該方法的讀者將非常熟悉Spring Integration Framework的構(gòu)造。 SI框架允許對(duì)所有這三個(gè)結(jié)構(gòu)進(jìn)行大量自定義，此外，就像在任何其他多線程配置中一樣，只需使用異步通道即可使這些工作單元并行執(zhí)行。

與SI Splitter Aggregator設(shè)計(jì)一起使用時(shí)，一個(gè)有趣的挑戰(zhàn)是構(gòu)建適當(dāng)健壯的流，這些流在許多調(diào)用方案中都可以預(yù)測(cè)地運(yùn)行。 一個(gè)簡(jiǎn)單的拆分器聚合器設(shè)計(jì)可以在許多情況下使用，并且無(wú)需大量定制SI構(gòu)造即可運(yùn)行。 但是，某些服務(wù)要求需要更強(qiáng)大的處理策略，因此需要更復(fù)雜的配置。 以下各節(jié)描述并顯示了簡(jiǎn)單拆分器聚合器設(shè)計(jì)的實(shí)際外觀，設(shè)計(jì)必須能夠處理的處理類型，然后為更健壯的處理提供建議的解決方案。

簡(jiǎn)單的拆分器聚合器設(shè)計(jì)

以下Splitter Aggregator設(shè)計(jì)顯示了一個(gè)簡(jiǎn)單的流程，該流程將文檔請(qǐng)求消息接收到消息傳遞網(wǎng)關(guān)中，將消息分為兩個(gè)處理路由，然后聚合響應(yīng)。 請(qǐng)注意，該圖是從OmniGraffle中的EIP構(gòu)造構(gòu)建的，而不是從STS內(nèi)部的“集成圖”視圖。 為了簡(jiǎn)潔起見(jiàn)，圖中沒(méi)有顯示通道。

SI的詳細(xì)構(gòu)造：

消息傳遞網(wǎng)關(guān) –有三個(gè)消息傳遞網(wǎng)關(guān)。 有多種配置可用于網(wǎng)關(guān)規(guī)范，但可以顯著地返回業(yè)務(wù)對(duì)象，異常和空值（超時(shí)后）。 最左邊的網(wǎng)關(guān)是我們?yōu)槠涠x流程的服務(wù)網(wǎng)關(guān)。 路由器和聚合器之間的其他兩個(gè)網(wǎng)關(guān)是外部系統(tǒng)，它們將提供對(duì)我們流程產(chǎn)生的業(yè)務(wù)問(wèn)題的響應(yīng)。

拆分器 –存在單個(gè)拆分器，它負(fù)責(zé)使用文檔消息并生成消息集合以進(jìn)行后續(xù)處理。 最常用的自定義拆分器的Java簽名指定單個(gè)對(duì)象參數(shù)和用于返回的集合。

收件人列表路由器 –存在一個(gè)路由器，可以使用任何適當(dāng)?shù)穆酚善?#xff0c;選擇與您的要求最接近的路由器–您可以輕松地按表達(dá)式或有效負(fù)載類型進(jìn)行路由。 路由器的主要目的是路由分離器提供的消息集合。 這是一個(gè)非常典型的拆分器聚合器配置。

聚合器 –單個(gè)構(gòu)造，負(fù)責(zé)將消息收集在一起，以便可以對(duì)網(wǎng)關(guān)響應(yīng)進(jìn)行進(jìn)一步處理。 盡管可以使用屬性和Bean定義來(lái)配置Aggregator，以提供替代的分組和發(fā)布策略，但是大多數(shù)情況下，默認(rèn)的聚合策略就足夠了。

拆分器聚合器操作的有趣方面

網(wǎng)關(guān) –入站網(wǎng)關(guān)（最左邊的一個(gè)）上可能有也可能沒(méi)有定義錯(cuò)誤處理bean引用。 如果是這樣，那么該bean將有機(jī)會(huì)處理該網(wǎng)關(guān)右側(cè)的流中引發(fā)的異常。 如果沒(méi)有，任何異常將直接拋出網(wǎng)關(guān)。

網(wǎng)關(guān) –可以在每個(gè)網(wǎng)關(guān)上設(shè)置一個(gè)可選的默認(rèn)回復(fù)超時(shí) ，設(shè)置此值有很大的含義，請(qǐng)確保它們被很好地理解。 超時(shí)將導(dǎo)致網(wǎng)關(guān)返回空值 。 如果上游網(wǎng)關(guān)也沒(méi)有設(shè)置默認(rèn)應(yīng)答超時(shí) ，則這是可能導(dǎo)致線程駐留的完全相同的條件。

分配器輸入通道 –這可以是簡(jiǎn)單的直接通道，也可以是定義了調(diào)度程序的直接通道。 如果通道指定了調(diào)度程序，則此點(diǎn)的下游流將是異步的多線程的。 這也改變了上游網(wǎng)關(guān)的語(yǔ)義，因?yàn)樗ǔＲ馕吨静恢匾膁efault-reply-timeout變?yōu)榛顒?dòng)狀態(tài)。

拆分器 –拆分器必須返回單個(gè)對(duì)象。 拆分器返回的單個(gè)對(duì)象是一個(gè)集合java.util.List。 SI框架將采用該列表的每個(gè)成員，并將其饋入Splitter的輸出通道 –與本示例一樣，通常直接進(jìn)入路由器。 “拆分器列表”返回的合同與在Java中的用法相同-它可能包含零個(gè)，一個(gè)或多個(gè)元素。 如果拆分器返回一個(gè)空列表，則路由器不太可能要做任何工作，因此流調(diào)用將完成。 但是，如果列表包含一項(xiàng)，則SI框架將從列表中提取該項(xiàng)并將其推送到路由器，如果路由成功，則流程將繼續(xù)。

路由器 –在此示例中，路由器將僅將消息路由到兩個(gè)網(wǎng)關(guān)之一。

網(wǎng)關(guān) –在拆分器和聚合器之間使用的兩個(gè)網(wǎng)關(guān)很有趣。 在此示例中，我使用通用網(wǎng)關(guān)EIP模式表示消息子系統(tǒng)，但未明確定義-我們可以使用HTTP出站網(wǎng)關(guān)，另一個(gè)SI流或任何其他外部系統(tǒng)。 當(dāng)然，對(duì)于那些子系統(tǒng)中的每一個(gè)，許多響應(yīng)都是可能的。 取決于協(xié)議和外部系統(tǒng)，消息請(qǐng)求可能無(wú)法發(fā)送，響應(yīng)未能到達(dá)，調(diào)用了長(zhǎng)時(shí)間運(yùn)行的進(jìn)程，網(wǎng)絡(luò)錯(cuò)誤或超時(shí)或常規(guī)處理異常。

聚合器 –單個(gè)聚合器將等待大量響應(yīng)，具體取決于拆分器創(chuàng)建的內(nèi)容。 在拆分器返回列表為空的情況下，將不會(huì)調(diào)用聚合器。 如果“拆分器”返回列表只有一個(gè)條目，則聚合器將等待一個(gè)網(wǎng)關(guān)響應(yīng)來(lái)完成該組。 如果“拆分器”列表有n個(gè)條目，則聚合器將等待n個(gè)條目來(lái)完成該組。 可以將自定義關(guān)聯(lián)策略，發(fā)布策略和消息存儲(chǔ)庫(kù)注入到一組豐富的配置方面。

簡(jiǎn)單拆分器聚合器操作的有趣方面

確定這種類型的簡(jiǎn)單網(wǎng)關(guān)是否足以滿足要求的主要決定因素是了解發(fā)生故障時(shí)發(fā)生的情況。 如果您的SI流中發(fā)生任何異常導(dǎo)致流調(diào)用被放棄并且符合您的要求，則無(wú)需進(jìn)一步閱讀。 但是，如果您需要在其中一個(gè)網(wǎng)關(guān)發(fā)生故障后繼續(xù)處理，那么本文的其余部分可能會(huì)引起您的更多興趣。

拆分器和聚合器之間生成的任何來(lái)源的異常都將導(dǎo)致聚合器丟棄空的或部分的組。 異常將傳播回最近的上游網(wǎng)關(guān)，以供自定義bean處理或由網(wǎng)關(guān)重新拋出。 請(qǐng)注意，聚合器上的自定義釋放策略很難使用，尤其是與超時(shí)一起使用，但在這種情況下無(wú)濟(jì)于事，因?yàn)楫惓⒃谡{(diào)用聚合器之前傳播回最左邊的網(wǎng)關(guān)。

也可以在最內(nèi)部的網(wǎng)關(guān)上配置異常處理程序，可以捕獲異常消息，但是如何將消息從定制異常處理程序路由到聚合器以完成組，將聚合器通道定義注入到定制異常處理程序中呢？ 這是一種較差的方法，可能涉及解包異常消息有效負(fù)載，將原始消息標(biāo)頭復(fù)制到新的SI消息中，然后添加原始有效負(fù)載–只有四到五行代碼，但是很臟。

在生成異常之后，無(wú)法將異常消息（ 未經(jīng)修改 ）路由到聚合器中以完成組。 原始消息（包含有關(guān)組和組位置的相關(guān)ID和序列ID的消息）被掩埋在SI消息異常有效載荷內(nèi)。

如果在異常生成之后需要繼續(xù)處理，則必須清楚，為了繼續(xù)處理，必須進(jìn)行以下操作：

• 聚合組需要完成，
• 返回到壁櫥上游網(wǎng)關(guān)之前，必須捕獲并處理所有異常，
• 允許在聚合器中完成組的相關(guān)性和序列標(biāo)識(shí)符埋在異常消息有效負(fù)載之內(nèi)，并且將需要提取和設(shè)置綁定到聚合器的消息

更健壯的解決方案–郵件網(wǎng)關(guān)適配器模式

處理網(wǎng)關(guān)的異常和空返回值自然會(huì)導(dǎo)致一種設(shè)計(jì)，該設(shè)計(jì)在消息傳遞網(wǎng)關(guān)周圍實(shí)現(xiàn)包裝器。 這提供了否則將很難建立的控制級(jí)別。

這種適配器技術(shù)允許在將消息傳遞網(wǎng)關(guān)注入到Service Activator中并從中直接調(diào)用時(shí)，捕獲并處理消息傳遞網(wǎng)關(guān)的所有返回。 消息傳遞網(wǎng)關(guān)不再直接響應(yīng)聚合器，而是響應(yīng)在Service Activator名稱空間定義中配置的自定義Java代碼Spring bean。 不出所料，不會(huì)發(fā)生異常的處理將繼續(xù)正常進(jìn)行。 那些經(jīng)歷異常情況或消息傳遞網(wǎng)關(guān)出現(xiàn)意外響應(yīng)或缺少響應(yīng)的流需要以某種方式處理消息，例如可以完成綁定到聚合的消息組。 如果Service Activator允許將異常傳播到其支持bean之外，則該組將無(wú)法完成。 同樣的情況不僅適用于異常，而且不包含前提條件組相關(guān)ID和序列標(biāo)頭的任何返回對(duì)象-這就是應(yīng)用適配的地方。

捕獲和處理來(lái)自消息傳遞網(wǎng)關(guān)的異常消息或空響應(yīng)，如以下示例代碼所示：

import com.l8mdv.sample.*; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.integration.Message; import org.springframework.integration.MessageHeaders; import org.springframework.integration.support.MessageBuilder; import org.springframework.util.Assert;public class AvsServiceImpl implements AvsService {private static final Logger logger= LoggerFactory.getLogger(AvsServiceImpl.class);public static final String MISSING_MANDATORY_ARG= "Mandatory argument is missing.";private AvsGateway avsGateway;public AvsServiceImpl(final AvsGateway avsGateway) {this.avsGateway = avsGateway;}public Message<AvsResponse> service(Message<AvsRequest> message) {Assert.notNull(message, MISSING_MANDATORY_ARG);Assert.notNull(message.getPayload(), MISSING_MANDATORY_ARG);MessageHeaders requestMessageHeaders = message.getHeaders();Message<AvsResponse> responseMessage = null;try {logger.debug("Entering AVS Gateway");responseMessage = avsGateway.send(message);if (responseMessage == null)responseMessage = buildNewResponse(requestMessageHeaders,AvsResponseType.NULL_RESULT);logger.debug("Exited AVS Gateway");return responseMessage;} catch (Exception e) {return buildNewResponse(responseMessage, requestMessageHeaders,AvsResponseType.EXCEPTION_RESULT, e);}}private Message<AvsResponse> buildNewResponse(MessageHeaders requestMessageHeaders,AvsResponseType avsResponseType) {Assert.notNull(requestMessageHeaders, MISSING_MANDATORY_ARG);Assert.notNull(avsResponseType, MISSING_MANDATORY_ARG);AvsResponse avsResponse = new AvsResponse();avsResponse.setError(avsResponseType);return MessageBuilder.withPayload(avsResponse).copyHeadersIfAbsent(requestMessageHeaders).build();}private Message<AvsResponse> buildNewResponse(Message<AvsResponse> responseMessage,MessageHeaders requestMessageHeaders,AvsResponseType avsResponseType,Exception e) {Assert.notNull(responseMessage, MISSING_MANDATORY_ARG);Assert.notNull(responseMessage.getPayload(), MISSING_MANDATORY_ARG);Assert.notNull(requestMessageHeaders, MISSING_MANDATORY_ARG);Assert.notNull(avsResponseType, MISSING_MANDATORY_ARG);Assert.notNull(e, MISSING_MANDATORY_ARG);AvsResponse avsResponse = new AvsResponse();avsResponse.setError(avsResponseType,responseMessage.getPayload(), e);return MessageBuilder.withPayload(avsResponse).copyHeadersIfAbsent(requestMessageHeaders).build();} }

注意異常處理塊的catch子句的最后一行。 此行代碼將相關(guān)性和序列標(biāo)頭復(fù)制到響應(yīng)消息中，如果要允許聚合組完成，則這是強(qiáng)制性的，并且在出現(xiàn)異常后總是必需的，如此處所示。

使用這種技術(shù)的后果

毫無(wú)疑問(wèn)，在SI配置中引入消息傳遞網(wǎng)關(guān)適配器會(huì)使配置更加復(fù)雜，難以閱讀和遵循。 此處的關(guān)鍵因素是在配置文件中不再存在線性關(guān)系。 這是因?yàn)镾ervice Activator必須轉(zhuǎn)發(fā)引用一個(gè)網(wǎng)關(guān)或一個(gè)在適配Service Activator之前定義的網(wǎng)關(guān)-在兩種情況下，結(jié)果都是相同的。

資源資源

注意：-推動(dòng)創(chuàng)建此元模式的軟件的設(shè)計(jì)基于以下要求：單個(gè)中央風(fēng)險(xiǎn)評(píng)估服務(wù)將訪問(wèn)許多外部風(fēng)險(xiǎn)評(píng)估服務(wù)。 為了使服務(wù)的客戶滿意，盡管這些外部服務(wù)中的任何一項(xiàng)失敗了，調(diào)用也必須并行進(jìn)行并繼續(xù)進(jìn)行。 該要求導(dǎo)致了該項(xiàng)目的消息傳遞網(wǎng)關(guān)適配器模式的設(shè)計(jì)。

Spring集成參考手冊(cè)

在建立大型美國(guó)金融機(jī)構(gòu)的風(fēng)險(xiǎn)評(píng)估流程的背景下，直接與Mark Fisher（SpringSource）討論了解決此問(wèn)題的方法。 盡管配置和代碼受NDA和版權(quán)保護(hù)，但可以在本文中表達(dá)設(shè)計(jì)意圖和類似代碼。

參考： Spring Integration – TechiQuest博客上來(lái)自我們JCG合作伙伴 Matt Vickery的強(qiáng)大的Splitter Aggregator 。

翻譯自: https://www.javacodegeeks.com/2013/06/spring-integration-robust-splitter-aggregator.html

spring mvc拆分

總結(jié)

以上是生活随笔為你收集整理的spring mvc拆分_Spring集成–强大的拆分器聚合器的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。