Spring integration Spring集成线程限制

我们有一个SI应用程序，用于路由消息、执行一些验证、转换和过滤

本质上，它使用来自各种队列的JMS消息，并将它们路由到预先注册的下游出站JMS队列

我们通过spring配置管理所有这些

在1个JVM中，我们有几百（400-500）个队列通道和相关的轮询器

我们注意到，随着规模的扩大（添加新的入站+出站路由），我们的性能有所下降

我们似乎没有对机箱（CPU、内存等）产生影响，但似乎都没有得到充分利用

当分析应用程序时，看起来是这样的

• 总共可运行约650个线程
• 0-2阻隔0（有时峰值在10左右，似乎找不到阻隔的内容）
• 网络I/O~100+（通常等待JMS接收）
• 等待约500

我们已经从卷的角度对应用程序进行了负载测试，但正在从入站+出站处理流的放大角度对其进行研究

我们在机箱上运行了其中几个（都指向不同的外部JMS资源），但我们只看到其中一个JVM（配置了最多入站+出站流的JVM）上的速度变慢

从长远来看，我们试图理解

对于轮询器+队列通道，SI是否有缩放限制

可能有些限制，有什么症状，如何检测

这里的约束是什么，线程上下文切换？还有别的吗

我们使用的是SI（1）的旧版本，在处理这种类型的体系结构方面是否有改进，或者是否需要重新设计

在多个入站和出站通道之间实现高并发、事件式路由的替代体系结构？每个入站和出站通道仍然有一组可能要运行的内容（转换、筛选、验证）

---

为什么有这么多排队通道？在一个流中有多个异步切换（如果有）是不寻常的，而且通常是不必要的。通常根本不需要，尤其是在使用消息驱动的入站端点（如JMS消息驱动适配器）时

这是因为线程和并发可以完全由适配器的消息侦听器容器管理

最有效的配置是将入站适配器上的并发性（线程数）设置为所需的并发性，并在整个过程中使用直接通道

---

事实上，如果您希望没有丢失消息的可能性，这是必需的；一旦消息在队列通道中传递，JMS消息即被确认（默认情况下）。

隔离需要几个队列通道（在当前设计中）。通常，入站消息会被复制并发送到多个下游通道。我们希望（我假设，是由其他人构建的）将消息侦听器和线程解耦，这样，如果一个订阅者出现问题（JMS关闭、消息转换错误等），它对其他订阅者的影响就会更小。这种隔离/解耦通常可以通过每个流中的单个队列（或执行器）通道实现（或者通常最多“几个”）正如你所说）。在我看来，“几百个”听起来像是对基本概念的误解。如果我们有几百个不同的流需要隔离呢？假设我们有一条信息需要传达给25个下游消费者。现在如果我们有大约一百种这样的配置，你可以看到事情很快就会失控。我们从什么时候开始将它们拆分为不同的JVM？还是我们以一种无法维持的方式进行？