和同事正在讨论我们在Weblogic中构建的应用程序的体系结构。该应用程序的要点是这样的。文件放置在网络驱动器上，完成一些处理，文件发出。这些文件属于称为事务的类别。争论是，是最好将不同事务的所有文件放入一个文件夹中，并让一个入站文件适配器查看该文件夹，还是按事务分隔文件夹，每个事务有一个入站文件适配器。
该系统可以有几百笔交易，所以如果是 1：1 的比例，就会有数百个轮询者。也可以对它们进行分组，但我们仍然可能有 50+ 个目录。
并非所有事务都具有相同的吞吐量要求。有些需要近乎实时地拾取 - 有些，只需每天查看一次该文件夹并拾取它们。某些事务每天可能有数万个文件。
从高级别来看，第一个组件从目录中获取文件名，将文件移动到下一个文件夹，并在队列中放置一条消息，提醒下一个下游组件处理该文件。
1 个目录的优势：
- 您只有 1 个线程在运行。
缺点：
- 您需要不断快速轮询。您将在可伸缩性方面停滞不前，因为一个入站适配器只能在每个目录的一秒钟内拾取一定数量的文件。如果使用多个 JVM，轮询器将争夺谁锁定某个文件并可以移动它。
许多目录的优势：
- 您可以更好地控制交易的提取方式。事务 XYZ 可能只需要安排为每天运行一次，而 ABC 每 5 分钟运行一次。XYZ不会妨碍ABC。因此，如果有 10000 个 XYZ 文件和 1 个 ABC 文件，ABC 将很快被拾取。
- 可扩展性。如果我有 100 个目录并且发现没有足够的资源，例如，我可以部署 5 个"文件接收器"，并让每个目录查看 20 个不同的目录(旁注，我的同事想要构建一个整体......虽然我想将每个组件分解为每个可部署组件，但理论上如果分解，我相信它更具可扩展性，因为我们可以增加接收器的 #(
缺点：许多入站适配器线程轮询(但并不总是主动的(。
我对社区的问题是 - 就 Spring 集成而言，在应用程序中启动数百个入站文件适配器有多可怕？可能会出现什么问题？我假设当文件入站适配器未列出目录时，它几乎处于空闲状态并且不消耗任何资源？
我们使用 Weblogic 作为应用程序服务器，我的同事还建议使用工作管理器来管理系统其他部分的线程资源。这也可以用于处理数百个入站适配器吗？
谢谢！
轮询器共享一个任务计划程序，默认池有 10 个线程，但可以增加。所以这不是一个真正的问题 - 是的，民意调查之间没有消耗任何资源。
从高级别来看，第一个组件从目录中获取文件名，将文件移动到下一个文件夹，并在队列中放置一条消息，提醒下一个下游组件处理该文件。
由于轮询器所做的工作很少(移动文件并将消息发送到队列(，我认为拥有一个实例(也许具有热备用(不会成为限制因素。
我的同事想建造一个整体...而我想将每个组件分解为每个可部署组件
我同意你的做法。使用中间件(JMS，RabbitMQ(来分发工作为您提供了最大的灵活性，您可以增加每个实例中的使用者线程并根据需要添加更多实例。