我们有一个Web应用程序，它通过在Jersey / Tomcat / Apache / PostgreSQL上运行的RESTful Web服务接收传入数据。与此Web服务应用程序分开，我们需要执行许多重复和计划任务。例如，以不同的时间间隔清除不同类型的数据，在不同的时间表上从外部系统提取数据，并在指定的日期和时间生成报告。
因此，在阅读了Quartz Scheduler之后，我发现它看起来非常适合。
我的问题是：我应该将基于Quartz的调度应用程序设计为在Tomcat中运行（通过QuartzInitializerListener），还是将其构建为独立应用程序以作为Linux守护程序运行（例如，通过Apache Commons Daemon或Tanuk Java Service包装器）。
一方面，使用Tomcat来托管不适合接收http呼叫的应用程序，这让我感到违反直觉。另一方面，我之前没有使用过Apache Commons Daemon或Java Service Wrapper，所以也许在Tomcat中运行是阻力最小的路径。
我应该注意哪种方法有任何重大的好处或危险吗？我们的核心模块已经负责数据访问，日志记录等，所以我不认为这些服务是其中任何一个因素。
我们的调度将是数据驱动的，因此我们的基于Quartz的调度程序将从PostgreSQL中读取相关数据。但是，如果我们在Tomcat中运行调度应用程序，是否可以/合理地通过http调用Tomcat将消息发送到我们的应用程序？最后，fwiw，由于我们的工作将由我们现有的应用程序数据驱动，因此我不认为需要Quartz JDBCJobStore。
答案 0 :(得分：1)
要将Java独立应用程序作为Linux守护程序运行，只需使用& -sign结束java命令，以便它在后台运行并将其放在Upstart脚本中。例如。
至于设计：在这种情况下，我会选择更容易维护的东西。看起来在Tomcat中运行应用程序已经很熟悉了。想到的一个好处是可以共享/重用配置文件（例如，用于数据库），因此只需要维护一组配置文件。
但是，如果您认为计划任务会对资源使用产生重大影响，那么您可能希望在单独的（虚拟）计算机上运行任务。由于任务的时间是数据驱动的，因此很难预测确切的负载。例如。可能会发生所有不同的任务同时执行（最坏情况/最高负载情况）。还要考虑计划任务的软件复杂性以及相关的恶意风险：如果你认为存在令人讨厌的错误的可能性很小，那么在Tomcat旁边运行Tomcat中的任务是一个不错的选择，如果不是，将任务作为单独的应用程序运行。最后，考虑一般的基础设施：生产线系统（提供（持续流动的）对业务至关重要的数据处理）应与非生产线系统分开。例如。如果报告比平时晚一个小时创建，并且业务基本上不受影响，则这是非生产线。但是，如果网络服务出现故障并且业务（立即）受到影响，那么这就是生产线。清除数据和提取更新有点灰色：取决于如果不执行这些任务或稍后执行会发生什么。