0

Jersey/Tomcat/Apache/PostgreSQL で実行されている RESTful Web サービスを介して着信データを受信する Web アプリケーションがあります。この Web サービス アプリケーションとは別に、実行する必要がある反復タスクやスケジュール タスクが多数あります。たとえば、さまざまな種類のデータをさまざまな間隔で消去したり、さまざまなスケジュールで外部システムからデータを取得したり、指定した日時にレポートを生成したりします。

したがって、Quartz Scheduler を読んだ後、それが非常に適しているように思えます。

私の質問は、Tomcat で (QuartzInitializerListener を介して) 実行するように Quartz ベースのスケジューリング アプリケーションを設計するか、それとも 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 を -sign で終了し、たとえば Upstart-script に配置します。

設計に関しては、この場合、保守しやすいものを選びます。そして、Tomcat でアプリを実行することは、すでにおなじみのようです。頭に浮かぶ利点の 1 つは、構成ファイル (データベースなど) を共有/再利用できるため、1 セットの構成ファイルのみを維持する必要があることです。

ただし、スケジュールされたタスクがリソースの使用に大きな影響を与える可能性があると思われる場合は、別の (仮想) マシンでタスクを実行することをお勧めします。タスクのタイミングはデータ駆動型であるため、正確な負荷を予測することは困難です。たとえば、すべての異なるタスクが同時に実行される可能性があります (最悪のケース/最大負荷のシナリオ)。また、スケジュールされたタスクのためのソフトウェアの複雑さと、関連する厄介なバグのリスクも考慮してください。厄介なバグの可能性が低いと思われる場合は、Web サービスの隣にある Tomcat でタスクを実行することをお勧めします。 、タスクを別のアプリケーションとして実行します。最後に、インフラストラクチャ全般について考えてみましょう。生産ライン システム (ビジネスにとって重要なデータ処理 (の継続的なフロー) を提供するシステム) は、非生産ライン システムから分離する必要があります。例えば レポートが通常より 1 時間遅れて作成され、ビジネスにほとんど影響がない場合、これは非生産ラインです。しかし、Web サービスがダウンし、ビジネスが (即座に) 影響を受ける場合、これは生産ラインです。データのパージと更新のプルは少し灰色です。これらのタスクが実行されなかった場合、または後で何が起こるかによって異なります。

于 2014-09-27T02:33:06.877 に答える