我一直致力于金融行业的解决方案。该应用程序的主要功能是能够加载大量输入文件、消化它们、更新持久存储中的状态并根据请求从持久存储中生成提取物。非常简单。
输入文件是行业标准格式的 XML 大型(超过数百兆字节)消息，其中包含许多重复条目。持久存储是关系数据库。该引擎已实现为基于 POJO(Spring Framework 作为主干)的 Java 应用程序，可部署在 J2EE 应用程序服务器上。
问题在于解决方案的可扩展性和性能。如果应用程序按顺序处理来自 XML 的条目，则解决方案的可扩展性相当差。无法让多个应用程序实例参与单个文件的处理。这就是我为输入 XML 文件中的条目引入并行处理的原因。基本上，这个想法是为池中的工作人员分派(dispatch)单个条目的处理。我决定使用 JMS 进行调度。加载文件的组件读取流并简单地提取单个条目并提供给调度队列。队列的另一端有许多并发消费者。每个人都从队列中选择一条消息并处理该条目，并且它可以立即用于处理其他条目。这与 Web 容器中的 servlet 非常相似。我发现这种方法特别强大的地方在于，只要队列是共享的，工作人员就可以驻留在部署在远程服务器上的应用程序的单独实例中。不幸的是，所有工作人员都连接到维护持久性存储的同一个数据库，如果数据库服务器的功能不足以处理来自并发工作人员的负载，这可能会成为瓶颈。
您对此架构有何看法？你有类似的设计应用吗？当时您的设计选择是什么？
最佳答案
您还可以查看 Hadoop，这是一个非常方便的 Map/Reduce 作业平台。巨大的优势在于，所有基础设施均由 Hadoop 提供，因此您只需应用新的硬件节点即可扩展。实现 Map 和 Reduce 作业应该只执行一次，在此之后，您可以为集群提供大量负载。
关于java - Java EE 应用程序的可扩展性。你会如何处理它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/639275/