1.ハードウェアとの通信-測定値、ステータス情報、テレメトリ、インフラストラクチャ設定などの受信。
2.着信データのリアルタイム処理。
3.受信したデータの集約。
4. RMIベースのクライアントソフトウェアとの高レベルインターフェイス（これらの古代のクライアントもjava / netbeans rcpでした）。
すべてが機能し、誰もが幸せだったため、ある時点で、Javaのクライアントを必要とせず、デスクトップクライアントをまったく必要とせず、クライアントもまったく必要とせず、システムとの統合を望んだ顧客が来るまで、幸福がありました。 そして、そのように生きることはもうできないという認識に至りました。私たち自身のクライアントはウェブ（HTML5 / JS / OL）の下で書き直され、サーバーではRMI APIが切り離されて名誉に埋もれ、REST + WebSocket API（Nettyベース）に置き換えられました。データ表現形式としてのJSON（ジャクソンに基づく）。 結果のプロトコルは、内部名RTLSCP（実際のトラックロケーションシステム通信プロトコル）を受け取りました。
そして再び幸福が訪れました-システムとサーバーの統合のみを取得したい人はクロスプラットフォームのトラブルなしでRTLSCP APIを使用し、既製のクライアントが必要な人はカスタマイズされたWebクライアントを受け取りました。
システムの機能が大きくなり（そして、主に、クライアント側のウィッシュリストが原因で）、サーバーコードベースもそれぞれ大きくなり、サポート固有のコストのために、クライアント固有の機能をメインサーバーに押し込めないことがわかりました。結果として生じる収穫機。 これに関して、すべてのクライアント固有のロジックをRTLSCPを介してメインロジックと通信する中間サーバーに転送し、外部クライアントにプロキシし、さらに追加のビジネスロジックを実装してプロトコルを拡張することが決定されました（この拡張はRTLSCPと呼ばれていました）。内線）。 この中間サーバーは、オープンで簡単に拡張/変更可能なシステムを顧客側で取得するために、node.jsで作成されました。
RealTracテクノロジーもまだ止まっておらず、最近、新しいビジネスニッチの開発に関連する既に内部機能を追加する要求の雪崩のような成長が始まっています。 そして、近い将来、メインサーバーの機能を拡張し、2つのシステムモジュール（メインサーバーとアプリケーションサーバー）の本格的な高レベルAPIを維持するための人件費に関連する問題の影が崩れました。 一方では、これにより、アプリケーションサーバーなしでメインサーバーを提供できます。他方では、機能が重複しています。 また、メインサーバー側の高レベルAPIを放棄し、単純な内部APIを使用してアプリケーションサーバーに接続し、高レベルAPIをアプリケーションサーバーのみに残すことにしました。 その結果、機能は次のように分割されました。
1.メインサーバー
- 「腺」とのコミュニケーション。
- 生データを処理するサイクル全体。
- すべての低レベルビジネスロジックの実装。
- すべての生データと処理済みデータの保存
- アプリケーションサーバーと統合するためのシンプルなAPIのサポート。
2.アプリケーションサーバー
- メインサーバーとの統合のためのシンプルなAPIサポート
- すべての高レベルビジネスロジックの実装。
- 高レベルのクライアントAPIサポート。
新しいアーキテクチャの基本要件：
1.両方のコンポーネントのモジュール構造。
2.新しい鉄のサポートを追加することにより、人件費を最小限に抑える。
3.データ構造を拡張する労力を最小限に抑える。
4.新しい機能モジュールを追加するための労力の最小化。
5.明度を維持しながらシステムを将来クラスタリングする可能性。
6.ソリューションをクロスプラットフォームのままにする必要性。
多くの推測と分析の結果、Vert.xに基づいて、すべてのニーズを完全に満たす十分に機能的かつ軽量なソリューションとしてシステムを構築する必要があるという結論に達しました。 ハイライトは、Vert.xプラットフォームが提供する一般的なイベントバスに基づいて、メインサーバー（java）とアプリケーションサーバー（nodejs）をシームレスに統合できることでした。 実際、2台のサーバーは単一の情報イベントフィールドで機能し、サーバー間の相互作用の問題を解決し、システムの機能拡張やスケーリング/クラスタリングの問題を最小限に抑えます。
私たちが始めたばかりの記述されたアーキテクチャへの移行、そしてそれが最終的に何をもたらすのか-時間は教えてくれます...