デーモンプロセスと管理インターフェイスの疎結合
Javaで記述されたデーモンプロセスがあり、HTTPベースのAPIを介して実行時に構成できるようにしたいと考えています。
いくつかの理由から、管理APIをデーモンプロセス自体から分離したいと思います。
- 回復力：管理APIが失敗した場合、デーモンは実行を継続する必要があります。
- 関心の分離：管理APIとデーモンは、アプリケーション全体の2つの別個の（ただし相互に関連する）コンポーネントです。
- 疎結合：緊密に結合されていない場合、一方または他方のコンポーネントをアップグレードする方が簡単です。
現在、私が検討したアプローチは次のとおりです。
- デーモンと管理APIの両方をJAX-WSアプリケーションに組み込みます。これは機能しますが、上記のすべての点で失敗します。
- デーモンプロセスに、組み込みWebサービス（Jettyなど）を介して管理APIを公開させます。これは以前のアプローチよりも優れていますが（デーモンはWebコンテナーに依存しなくなりました）、それ以外の点では同じ問題の多くを共有しています。
- 共通の構成データベースを共有する2つの別個のアプリケーション（デーモンとAPI）を用意します。これにより疎結合が実現されますが、コンポーネント間の相互作用が厄介になります（たとえば、各コンポーネントが他のコンポーネントによって行われた変更についてデータベースをポーリングする必要があります）。
- 低レベルのソケットベースまたはパイプベースのインターフェイスを介して通信する、2つの別個のアプリケーションがあります。これは、疎結合を効率的に実現するという点では最適ですが、（おそらく）コードの複雑さという点ではコストが高くなります。
2つのコンポーネントを疎結合に保つことが望ましいと認める場合、Javaでこれを実現するための最良の（つまり、最も柔軟で慣用的な）アプローチは何ですか？私が検討していない代替案はありますか？
最善の解決策を見つけるには、非機能要件を決定/定義する必要があります。
非機能要件のいくつかは次のとおりです。
可用性（構成の変更は、1年の99.9xxx％で可能である必要があります）。
セキュリティ（構成の変更は管理者ユーザーのみに許可する必要があります）
構成変更が有効になるまでの時間（送信ボタンを押した直後に構成変更が有効になる必要があります）
- ネットワークトポロジ（デーモンサービスはインターネットから/ HTTP経由でアクセスできないようにする必要があります）
- .。
設計上の決定に影響を与える他のことは、実行中のデーモンの数です。デーモンも構成を変更しますか？ 1日/秒/月あたりの構成変更はいくつありますか？デーモンとWebサービスを同じマシンで実行しますか...
この問題の非常に簡単な解決策は、共有構成ファイル（データベース）とHTTP管理インターフェース、および個別のデーモンJavaプロセスを用意することです。変更のために構成をプルしたくない場合は、送信してくださいデーモンへの通知イベント（RMI、WebSocket、...）により、デーモンはいつ自分自身を再構成するかを知ることができます。
課題は、デーモンを継続的に実行する必要があることですが、必要に応じて、堅牢でありながらコーヒーで説明できる方法でデーモンの構成を更新します。多くの点で、デーモンが実行する必要があることと、これらの構成を更新する必要がある頻度によって異なります。私が使用したいくつかのオプションが役立ちます。
バッチ処理
私は本質的に別々の部分に分割した仕事をしていました：
- スケジューラデーモン-作業を行うかどうかを決定し、プロセッサのプロセスを管理する責任があります。
- プロセッサコマンドラインアプリ-起動時に構成を読み取り、実際の処理を実行する責任があります。
この配置は非常に理解しやすく、ファイルの処理中も構成を同じままにすることができました。一部の構成は、ディスク上のドキュメントのフィールドをデータベースのフィールドにマッピングすることと関係がありました。そのタイプの情報を処理する直前まで、その部分の構成の読み取りを遅らせます。次のドキュメントにたどり着いたとき、マッピングに変更があったかどうかを確認しました。
ほぼリアルタイム処理
リモートエンジンのレポート要件と制御要件の両方を備えたアプリケーションがありました。エンジンは、テレメトリを読み取って要約できるように、監視しているハードウェアの近くで実行する必要がありました。問題の性質上、小さなJSONパケットを使用して非常に単純なUDPインターフェイスを提供する必要がありました。
クライアントとエンジンの両方に2つのオープン接続が必要でした。1つは受信用、もう1つはブロードキャスト用です。必要な単純な通信を処理するために、一連の明確に定義されたメッセージがありました。
- Ping：キープアライブ機能を登録または提供するためのクライアントからエンジンへのメッセージ。クライアントからエンジンへのメッセージはすべてこの目的を果たしました。
- Pong：応答してキープアライブ機能を提供するためのエンジンからクライアントへのメッセージ。エンジンからクライアントへのメッセージはすべてこの目的を果たしました。
- 更新：表示用に要約されたテレメトリデータのエンジンからクライアントへのメッセージ。
- コマンド：アクションを実行するためのクライアントからエンジンへのメッセージ（構成の変更、監視コマンドの停止、監視コマンドの開始など）
このツールのニーズは比較的単純だったので、実際に行わなければならない再構成はそれほど多くありませんでした。ほとんどのコマンドはクライアントとの接続の管理を扱い、エンジンがとにかく再起動したときにほとんどの状態をデフォルトにリセットする必要がありました。
最後のオプションは、構成APIのニーズを処理するためにJSONマイクロサービス（Spring Bootが頭に浮かぶ）を埋め込むことです。 UI自体は、ファイルを提供するために実際にファイルシステムを必要とするだけのシングルページアプリ（SPA）になります。