用于在应用程序之间委派任务的 Java 企业架构

Question

在我的环境中，我需要安排长时间运行的任务。我有应用程序 A，它只向客户端显示当前正在运行的任务列表并允许安排新任务。还有应用程序 B 执行实际的艰苦工作。

所以应用A需要在应用B中调度一个任务。它们唯一的共同点就是数据库。最简单的做法似乎是添加一个包含任务列表的表，然后让应用程序 B 每隔一段时间查询一次该表并执行新安排的任务。

然而，这似乎不是正确的做法。乍一看，在企业环境中完成这项工作的工具似乎是消息队列。应用程序 A 将带有任务描述的消息发送到队列，应用程序 B 从队列中读取消息并执行任务。在这种情况下，应用程序 A 是否有可能获取所有计划任务(持久队列？)的状态，而无需像上面提到的那样创建一个表，应用程序 B 会将已完成任务的状态写入其中？另请注意，应用程序 A 可能有多个实例，每个实例都需要了解所有实例的所有任务。

“表方法”的缺点是我需要进行数据库轮询。

“消息队列方法”的缺点是我在基础架构中引入了一个新的通信 channel (这是另一件可能失败的事情)。

你怎么看？还有其他想法吗？预先感谢您的任何建议:)

==========更新==========

最终我决定采用以下方法:这个问题有两个方面:一个是A和B之间的通信。另一个是获取有关任务的信息。

JMS 是沟通的正确工具。要获取数据，正确的工具是数据库。因此，我将让应用程序 A 在描述任务的“任务”表中添加一个新行(稍后我可以查询该表以获取所有任务的列表)。然后 A 将通过 JMS 向 B 发送一条消息，只是说“你有工作要做”。 B 将执行工作并更新表中的任务状态。

感谢大家的回复!

Answer 1

您需要考虑您的部署环境现在和将来可能发生的变化。

您正在有效地研究两个问题，这两个问题都可以通过多种方式解决，具体取决于您能够获得多少基础设施并愿意引入多少，但“正确调整”您的设计也很重要问题。

虽然您考虑数据库和消息传递的使用是正确的，但您需要考虑这些项目对您的域是否过大，只有您和了解您的域的其他人才能真正回答这个问题。

我的建议是查看您所在地区已经在使用的内容。如果您已经拥有可以构建的数据库基础设施，那么在数据库中监控任务 Activity 和调度作业是个不错的主意。但是，如果您必须运行自己的数据库、获得新硬件、没有足够的支持资源，那么引入数据库可能不是一个明智的选择，您可以考虑一种更简单但可能更脆弱的方法来让您的进程写入文件以安排作业和报告任务。

同时，不要将 DB 或 JMS 的引入视为本质上容易出错。正确实现它们是稳定且经过验证的技术，将使您的系统可扩展和可管理。

正如@kan 所说，使用公开网络服务接口(interface)也是一个有用的选择。