0

我们有一个 Web 应用程序，它通过在 Jersey/Tomcat/Apache/PostgreSQL 上运行的 RESTful Web 服务接收传入数据。除了这个 Web 服务应用程序之外，我们还有许多需要执行的重复任务和计划任务。例如，以不同的时间间隔清除不同类型的数据，按不同的时间表从外部系统中提取数据，以及在指定的日期和时间生成报告。

所以，在阅读了 Quartz Scheduler 之后，我发现它看起来很合适。

我的问题是：我应该将我的基于 Quartz 的调度应用程序设计为在 Tomcat 中运行（通过 QuartzInitializerListener），还是将其构建到一个独立的应用程序中作为 linux 守护程序运行（例如，通过 Apache Commons Daemon 或 Tanuk Java Service Wrapper）。

一方面，我觉得使用 Tomcat 来托管一个不适合接收 http 调用的应用程序是违反直觉的。另一方面，我之前没有使用过 Apache Commons Daemon 或 Java Service Wrapper，所以在 Tomcat 中运行可能是阻力最小的路径。

我应该注意这两种方法是否有任何显着的好处或危险？我们的核心模块已经处理了数据访问、日志记录等，所以我认为这些服务并不是一个重要因素。

我们的调度将是数据驱动的，因此我们基于 Quartz 的调度器将从 PostgreSQL 中读取相关数据。但是，如果我们在 Tomcat 中运行调度应用程序，是否可以/合理地通过对 Tomcat 的 http 调用向我们的应用程序发送消息？最后，由于我们的工作将由我们现有的应用程序数据驱动，我认为不需要 Quartz JDBCJobStore。

4

1 回答 1

1

要将 Java 独立应用程序作为 linux 守护程序运行，只需以 - 符号结束 java-command，&以便它在后台运行，并将其放在 Upstart-script 中。

至于设计：在这种情况下，我会选择更容易维护的东西。而且看起来在 Tomcat 中运行一个应用程序已经很熟悉了。想到的一个好处是配置文件（例如数据库）可以共享/重用，因此只需要维护一组配置文件。

但是，如果您认为计划任务会对资源使用产生重大影响，那么您可能希望在单独的（虚拟）机器上运行这些任务。由于任务的时间是数据驱动的，因此很难预测确切的负载。例如，可能会同时执行所有不同的任务（最坏情况/最高负载情况）。还要考虑计划任务的软件复杂性和相关的严重错误风险：如果您认为严重错误的可能性很低，那么在 Web 服务旁边的 Tomcat 中运行任务是一个不错的选择，如果不是，将任务作为单独的应用程序运行。最后，从总体上考虑基础设施：生产线系统（提供（连续流）对业务至关重要的数据处理）应该与非生产线系统分开。例如 如果报表比平时晚一个小时创建，业务基本不受影响，那么这就是非生产线。但是，如果 Web 服务出现故障并且业务（立即）受到影响，那么这就是生产线。清除数据和拉取更新有点灰暗：取决于如果不执行这些任务或稍后会发生什么。

于 2014-09-27T02:33:06.877 回答