我和同事正在讨论我们在 Weblogic 中构建的应用程序的架构。该应用程序的要点是这样的。文件被放置在网络驱动器上，完成一些处理后，文件就会出去。这些文件属于称为事务的类别。争论在于，是否最好将不同事务的所有文件放入一个文件夹并使用一个入站文件适配器查看该文件夹，或者按事务将文件夹分开并为每个事务使用一个入站文件适配器。
系统可以有几百个事务，所以如果是 1:1 的比率，就会有数百个轮询器。也可以将它们分组，但我们仍然可能有 50 多个目录。
并非所有事务都有相同的吞吐量要求。有些需要近乎实时地拾取 - 有些只需每天查看该文件夹一次即可拾取它们。有些交易每天可能有数万个文件。
从较高的级别来看，第一个组件从目录中获取文件名，将文件移动到下一个文件夹，并将一条消息放在队列中，提醒下一个下游组件处理该文件。
1 个目录的优点:
- 您仅运行 1 个线程。
缺点:
- 您需要不断快速地进行轮询。由于一个入站适配器只能在每个目录的一秒钟内拾取一定数量的文件，因此您的可扩展性将趋于稳定。如果使用多个 JVM，轮询器将争夺谁锁定某个文件并可以移动它。
许多目录的优点:
- 您可以更好地控制交易的处理方式。事务 XYZ 可能只需要安排每天运行一次，而 ABC 每 5 分钟运行一次。 XYZ 不会妨碍 ABC。因此，如果有 10000 个 XYZ 文件和 1 个 ABC 文件，ABC 将很快被拾取。
- 可扩展性。如果我有 100 个目录，并且发现资源不足，我可以部署 5 个“文件接收器”，并让每个接收器查看 20 个不同的目录(附注，我的同事想要构建一个整体......而我想要将每个组件分解为每个可部署组件，但从理论上讲，如果分解，我相信它更具可扩展性，因为我们可以增加接收器的数量)
缺点:许多入站适配器线程进行轮询(尽管并不总是主动)。
我向社区提出的问题是 - 就 Spring Integration 而言，在应用程序中启动潜在的数百个入站文件适配器有多可怕？可能会出现什么问题？我假设当文件入站适配器未列出目录时，它几乎处于空闲状态并且不消耗任何资源？
我们使用 Weblogic 作为应用程序服务器，我的同事还建议使用工作管理器来管理系统其他部分的线程资源。这也可以用来处理数百个入站适配器吗？
谢谢!
最佳答案
轮询器共享一个任务调度程序，默认池有 10 个线程，但可以增加。所以这并不是一个真正的问题 - 而且，是的，民意调查之间不会消耗任何资源。
From a high level, the first component obtains the filename from a directory, moves the file to the next folder and places a message on the queue alerting the next downstream component to work on the file.
由于轮询器所做的工作很少(移动文件并向队列发送消息)，我认为单个实例(可能具有热备用)不会成为限制因素。
my colleague wants to build a monolith...while I want to breakout each component into its each deployable
我同意你的做法。使用中间件(JMS、RabbitMQ)来分发工作可以为您提供最大的灵 active ，您可以增加每个实例中的使用者线程并根据需要添加更多实例。
关于java - 应用设计: Hundreds of File Polling in Spring Integration，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35423913/