Spring 集成是否适合 web-farm 处理 "reliable queue"？

Question

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

我们的团队需要开发 Web 服务，假设 运行 在多个 nodes（网络场 - 水平扩展）上。我们知道如何实现这个 "manually"，但我们对 Spring Integration 感到非常兴奋，这对我们来说是新的 - 所以我们真的试图了解这是否适合我们的场景 - 如果是的话我们'我会尽量利用它。

典型场景：

1. 多个服务器（“nodes”）运行 同一个 Web 应用程序（我们称之为“OurWebService”）
2. 我们需要从外部系统中提取文件 ("InboundExtSystems")
3. 在其他外部系统的帮助下处理此数据（涉及本地 resource-consuming 操作）("UtilityExtServices")
4. 将处理结果提交给另一组外部系统（“OutboundExtSystems”）

Non-functional 要求：

5. 由于性能原因，我们无法通过需求和本地处理也 CPU-intensive 查询 UtilityExtServices。所以我们需要queue，以控制我们执行请求和处理结果的速度
6. 我们预计多个节点将平均从这个 queue 中提取任务并处理它们
7. 我们需要确保从 InboundExtSystems 中提取的每个 queued 任务都将得到处理 - 我们需要保证其中的 none 会消失。
8. 我们需要确保超时也得到处理。如果任务处理超时 - 我们需要“requeue”这个任务（并确保之前处理的不会提交这个任务的结果）
9. 我们需要能够执行滚动更新。比如说有 5 个节点正在处理 queue。我们希望能够按顺序 stop-upgrade-start 每个节点而不显着影响系统性能。

所以问题是：spring integration是否非常适合这种情况？

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

p.s。果然我们可能还需要选择一些东西作为消息总线并且 queue 每个节点都可以访问（可能 redis、hazelcast 或 rabbitmq，不确定哪个更合适）

Answer 1

是的，很合适。我建议 transport/queuing 和 Spring Integration AMQP enpoints.

使用 rabbitmq

滚动更新应该不是问题，除非您更改节点之间发送的消息的格式）。但即便如此，您也可以通过移动到一组新队列来相对轻松地处理它。