Кварцевый планировщик - запускать в Tomcat или в приложении jar?

Question

У нас есть веб-приложение, которое получает входящие данные через веб-сервисы RESTful, работающие на Jersey/Tomcat/Apache/PostgreSQL. Отдельно от этого приложения веб-сервиса у нас есть ряд повторяющихся и запланированных задач, которые необходимо выполнить. Например, очистка разных типов данных с разными интервалами, извлечение данных из внешних систем по разным графикам и создание отчетов в указанные дни и время.

Итак, после прочтения Кварцевого Планировщика, я вижу, что он кажется мне подходящим.

У меня вопрос: нужно ли мне спроектировать приложение планирования на основе Quartz для запуска в Tomcat (через QuartzInitializerListener) или встроить его в отдельное приложение для запуска в качестве демона linux (например, через Apache Commons Daemon или Tanuk Java Service Wrapper).

С одной стороны, мне кажется нелогичным использовать Tomcat для размещения приложения, не ориентированного на получение http-вызовов. С другой стороны, я раньше не использовал Apache Commons Daemon или Java Service Wrapper, поэтому, возможно, работа внутри Tomcat - путь наименьшего сопротивления.

Есть ли какие-либо существенные преимущества или опасности с любым подходом, о которых я должен знать? Наши основные модули уже заботятся о доступе к данным, ведении журналов и т. Д., Поэтому я не вижу, чтобы эти сервисы были в любом случае важны.

Наше планирование будет основано на данных, поэтому наш планировщик на основе кварца будет считывать соответствующие данные из PostgreSQL. Однако если мы запустим приложение планирования в Tomcat, возможно ли / целесообразно отправлять сообщения нашему приложению через http-вызовы Tomcat? И наконец, поскольку мы работаем с данными наших существующих приложений, я не вижу необходимости в Quartz JDBCJobStore.

Answer 1

Чтобы запустить отдельное приложение Java в качестве демона linux, просто завершите команду java командой & -подписать так, чтобы он работал в фоновом режиме и поместить его в сценарий Upstart, например.

Что касается дизайна: в этом случае я бы пошел на то, что проще в обслуживании. И похоже, что запуск приложения в Tomcat уже знаком. Одно из преимуществ, которое приходит на ум, заключается в том, что файлы конфигурации (например, для базы данных) могут использоваться совместно или повторно, поэтому необходимо поддерживать только один набор файлов конфигурации.

Однако, если вы считаете, что запланированные задачи могут оказать значительное влияние на использование ресурсов, вы можете запускать задачи на отдельной (виртуальной) машине. Поскольку время выполнения задач определяется данными, точную нагрузку предсказать сложно. Например, может случиться так, что все различные задачи выполняются одновременно (сценарий наихудшего случая / наибольшая нагрузка). Также учитывайте сложность программного обеспечения для запланированных задач и связанный с этим риск появления неприятных ошибок: если вы считаете, что вероятность появления неприятных ошибок мала, то выполнение задач в Tomcat рядом с веб-сервисом - хороший вариант, если нет., запустите задачи как отдельное приложение. Наконец, рассмотрим инфраструктуру в целом: системы производственных линий (обеспечивающие (непрерывный поток) обработку данных, критически важных для бизнеса) должны быть отделены от непроизводственных систем. Например, если отчеты создаются на час позже, чем обычно, и на бизнес это практически не влияет, то это непроизводственная линия. Но если веб-сервис выходит из строя и бизнес (немедленно) затрагивается, то это производственная линия. Очистка данных и получение обновлений немного серые: зависит от того, что произойдет, если эти задачи не будут выполнены или позже.