Spring Integration DSL Filter vs. RouteToRecipients w/ singl

Question

当给定的评估返回 false 时，我需要将来自父流的消息路由到新流中，但当该评估返回 true 时，它会在父流中继续。目前，我已经能够使用Spring Integration DSL.filter()方法成功实现此功能，没有任何问题。但是，我觉得以这种方式使用.filter()并不属于这种方法的真正意图。是否有某种类型的路由器可以用来更好地满足同样的需求？是否有必要从此.filter()实现更改为基于路由器的实现？

以以下集成流配置为例...

@Bean
public IntegrationFlow flow() {
return IntegrationFlows
.from("inboundChannel")
.filter(someService::someTrueFalseMethod, onFalseReturn -> onFalseReturn.discardChannel("otherFlowInboundChannel"))
.handle(someService::someHandleMethod)
.get();
}
@Bean
public IntegrationFlow otherFlow() {
return IntegrationFlows
.from("otherFlowInboundChannel")
.handle(someOtherService::someOtherHandleMethod)
.get();
}

到目前为止.routeToRecipents()似乎可能是我需要使用的。在我的方案中，我需要评估消息的标头，以便这就是使用recipientMessageSelector的原因。

@Bean
public IntegrationFlow flow() {
return IntegrationFlows
.from("inboundChannel"
.routeToRecipients(router -> router
.recipientMessageSelector("otherFlowInboundChannel", someService::someTrueFalseMethod)
.defaultOutputToParentFlow()
)
.handle(someService::someHandleMethod)
.get();
}
@Bean
public IntegrationFlow otherFlow() {
return IntegrationFlows
.from("otherFlowInboundChannel")
.handle(someOtherService::someOtherHandleMethod)
.get();
}

即使使用这种看似有效的routeToRecipients解决方案，它与上面的过滤器实现之间真的有什么好处吗？

Answer 1

好吧，它实际上与Java DSL方法以及如何使用它们无关。它实际上是关于这些IE模式的理论。

让我们比较一下 EIP 的Filter和RecipientListRouter！

过滤器- https://www.enterpriseintegrationpatterns.com/patterns/messaging/Filter.html：

如果邮件内容与邮件过滤器指定的条件匹配，则邮件将路由到输出通道。如果邮件内容与条件不匹配，则会丢弃该邮件。

因此，从技术上讲，filter不符合您的期望，因为false分辨率上您有点丢弃消息。但是，对于这些丢弃消息的可能处理，Spring 集成提供了一个discardChannel选项来启动丢弃子流。因此，我们可以将其视为if..else构造...

收件人列表- https://www.enterpriseintegrationpatterns.com/patterns/messaging/RecipientList.html

然后使用收件人列表检查传入邮件，确定所需收件人的列表，并将邮件转发到与列表中收件人关联的所有通道。

所以，有点你需要的，因为你评估邮件和收件人，然后发送到他们的频道。只有模拟filter行为的问题，因为您不会有两个以上的具有相互排斥目的的通道。

当filter方法感觉像是流控制滥用时(提醒我 Java 中的类似逻辑依赖于流控制的异常处理(，它并没有要求我们始终保持规范行为，以便在消息不符合条件时最终出现错误。

recipientList适用于更复杂的场景，当选择器用于任何任意评估时，而不仅仅是普通布尔值，并且能够将相同的消息分发到多个输出通道。因此，对于这种简单的true/false方案，我不建议使用它。

您可以考虑研究另一种类似的模式：

基于内容的路由器- https://www.enterpriseintegrationpatterns.com/patterns/messaging/ContentBasedRouter.html

使用基于内容的路由器根据邮件内容将每封邮件路由到正确的收件人。

这个感觉非常接近您对true/false的需求，它不会滥用流量 cotrol 的错误(丢弃(，也不会向我们规定收件人列表。当您想要依赖非映射结果时，这个也具有这种defaultOutputToParentFlow()。

恕我直言，我会留在filter()- 它的true/false逻辑和discardChannel它看起来真的像是基于内容的路由器的特定实现：-(。