Spring Integration是否适用于“可靠队列”的Web场处理？

Question

很抱歉，如果标题令人困惑，请让我解释一下我的问题。

我们的团队需要开发Web服务，假设它运行在几个nodes上（Web场 - 水平扩展）。我们知道如何“手动”实现这一点，但我们对Spring Integration非常感兴趣，这对我们来说是新的 - 所以我们真的想要了解这是否适合我们的场景 - 如果是这样我们会尝试利用它。

典型情景：

1. 运行相同网络应用程序的Sevaral服务器（“nodes”）（我们称之为“OurWebService”）
2. 我们需要从外部系统（“InboundExtSystems”）
中提取文件
3. 借助其他外部系统处理此数据（涉及本地资源消耗操作）（“UtilityExtServices”）
4. 将处理结果提交给另一组外部系统（“OutboundExtSystems”）

非功能性要求：

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

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

如果答案为“是”，您能否主要说出我们应该主要使用的主要组件？

P.S。当然，我们可能还需要选择一些消息总线和每个节点可以访问的队列（可能是redis，hazelcast或者也许是rabbitmq，不确定什么更合适）

Answer 1

Yes, it's a good fit. I would suggest rabbitmq for the transport/queuing and the Spring Integration AMQP enpoints.

Rolling updates shouldn't be an issue unless you change the format of the messages sent between nodes). But even then you could handle it relatively easily by moving to a new set of queues.