Spring集成是否适用于“可靠队列”的网络场处理？

Question

对不起，如果标题混淆了，让我解释一下我的问题。

我们的团队需要开发web服务，这个服务应该运行在几个nodes (web场-水平扩展)上。我们知道如何“手动”实现这个功能，但是我们对Spring Integration非常兴奋，这对我们来说是新的--所以我们真的想了解这是否适合我们的场景--如果是这样的话，我们将尝试使用它。

典型情景：

1. 运行相同web应用程序的Sevaral服务器("nodes") (让我们称之为"OurWebService")
2. 我们需要从外部系统中提取文件("InboundExtSystems")
3. 借助其他外部系统(包括本地资源消耗操作)处理这些数据("UtilityExtServices")
4. 将处理结果提交给另一组外部系统("OutboundExtSystems")

非功能性需求：

1. 由于性能原因，我们不能通过需求和本地处理来查询UtilityExtServices，这也是CPU密集型的.因此，我们需要队列，以便控制执行请求和处理结果的速度。
2. 我们期望有几个节点会同样地从这个队列中提取任务并处理它们。
3. 我们需要确保从InboundExtSystems中提取的每一个排队的任务都将被处理--我们需要保证它们都不会消失。
4. 我们需要确保超时也得到处理。如果任务处理超时-我们需要"requeue“此任务(并确保以前处理过的任务不会提交此任务的结果)
5. 我们需要能够执行滚动更新。就像我们假设5个节点正在处理队列一样。我们希望能够按顺序停止升级-启动每个节点，而不会明显影响系统性能。

所以问题是：spring integration适合这种情况吗？

如果答案是“是”，你能请你说出我们应该主要使用的主要组件吗？

附注：当然，我们可能还需要选择一个消息总线，并为每个节点(可能是redis、hazelcast或可能的rabbitmq，不确定哪个更合适)排队)。

Answer 1

是的，很合身。我建议为运输/排队和弹簧集成AMQP的狂犬病the。

除非更改节点之间发送的消息的格式，否则滚动更新不应成为问题。但是，即使这样，您也可以通过移动到一个新的队列集来相对轻松地处理它。