web-dev-qa-db-ja.com

JEE Gps追跡システムの設計

Javaサーブレットをバックエンドソリューションとして使用してリアルタイムGPS追跡Webベースシステムを作成しましたが、フロントエンドはajaxリクエストとWebSocketでJavaScriptを使用しています(フロントエンドとバックエンドの両方が動作しています) Webアプリケーションとして一緒に)

基本的に、このシステムは、Googleマップ上にリアルタイムの車両を表示するWebインターフェースであり、ユーザーは、開始タイムスタンプ、終了タイムスタンプ、車両ID、およびもう少し多くのキャリブレーションスタッフなどの入力データに基づいて、過去のイベントのレポートを作成できます。

現在、すべてが同じバックエンドにあります-リアルタイムロジックとレポートのロジック(現在、ユーザーが選択できる50以上のレポートがあります)

レポートの複雑さとリアルタイムデータのシリアル化により、ユーザーと車両に関連付けられているデータベースデータのほとんどがメモリに読み込まれます。

ただし、ときどき(1日に2回)、改善を加えたり、いくつかのバグにパッチを適用したりする必要があります(たとえば、一部のレポートロジックを少し変更する必要がある、フロントエンドUIを修正する必要がある、または方法メールが送信されると、一部のクライアントでは変更が必要になるため)、ユーザーのセッションを終了して修正を展開する必要がありますが、これによりダウンタイムが発生します。

そのため、システムを複数のサービスに分割し、それぞれを独立したサーバー上に配置することを検討しています。

One independent service/server for the real-time data fetching and serialization.
One independent service/server for reverse geocoding.
One independent service/server for calculating and caching if current latitude/longitude is inside urban area or on a particular speed road.
One independent service/server for daily reports.
One independent service/server for event-based reports
One independent service/server for email and other notifications.
One independent service/server for tachograph data downloading and uploading to FTP.

等々。

この方法では、一部のサービスにパッチを適用、修正、またはアップグレードする必要がある場合、すべてを停止してユーザーのセッションを終了する必要はありません。

(何千ものプライベートクライアントが文字列をプルして何を作成するかを指示するため、一部のサービスではロジックを変更または導入するための毎日の要件があることを覚えておいてください)

ただし、CustomDateTime、Vehicle、MarkedArea、DynamicPOI、ClosedGeoCurve、FuelFlowMeter、Canbus、GPSDeviceFirmware、UserSerializationPermissions、DistanceCalculationMethodなどのいくつかのオブジェクトがシステム全体で頻繁に使用されているため、サービスでシステムを分割すると、それぞれのオブジェクトが独立した物理サーバーマシンでホストされている場合、これらのJavaオブジェクトが必要です。また、新しいフィールド、メソッド、および/またはビジネスロジックをクラスの一部に導入するたびにそれらを各サーバーに再度デプロイします。

そのため、私はこの分割を処理するための最良の方法をまだ調査中です。JEEアーキテクチャを使用して正しい方向性を示してくれる人がいれば、私はもっと幸せになります。

前もって感謝します。

1
Papa-rapa-beo

システムを分割するのではなく、永続性に焦点を当てることをお勧めします。

  1. メモリにデータをロードする代わりに、Ehcache( https://www.ehcache.org/ )または高速な非関係データベース(MongoDb)などのネットワークキャッシュを使用してみてください。これにより、メモリ内のデータの入力に時間を費やすことなく、システムを起動できます。
  2. ユーザーのセッション永続性をセットアップします。各JEEサーバーでそれが可能です。永続的なセッションにより、アプリケーションの再起動の間にユーザーがログインした状態を維持できます。
  3. 可能であれば、フロントエンド部分をWebアプリケーションパッケージの外に移動し、Webサーバーに直接デプロイします。そのため、ユーザーには常にWebインターフェイスが読み込まれ、バックエンドの再起動は短いネットワーク障害のように見えます。

要約すると、エンドユーザーのダウンタイムがほぼゼロで、デプロイメントがはるかに高速になります。

システムをサービスに明示的に分割する必要がある場合は、純粋な技術から始めます。メール配信、プッシュ/ SMS通知(存在する場合)。このようなロジックは、アプリケーションから簡単に抽出して専用サービスに移動できます。

2
Alex Chernyshev