NodeJSアプリケーションサーバーの進化

私たちのシステムでは、2台のサーバーが平和的に共存しています。 JAVAおよびアプリケーションサーバーで記述されたメインサーバー（コア）はNodeJSであり、この記事ではそれに専念します。

当初、アプリケーションサーバーには2つの基本的なタスクがありました。



1）非特定の負荷を軽減し、より重要なタスクを解決するためのリソースを節約するために、リクエストをメインサーバーにプロキシする。

2）クライアント「ウィッシュリスト」が表示されたときにカーネルコードを変更する必要がないように、クライアント固有の機能を実装します。



厳密に言えば、システムの機能にはアプリケーションサーバーの存在は必要ありません。 カーネルには、システムのすべての基本機能を実装する完全なREST APIがあります。 プロトコルに関するいくつかの言葉。 RTLSCP（リアルトラックロケーションシステム通信プロトコル）-HTTP上で動作し、JSON / KML / PNG形式のリクエストとレスポンスを使用して、RealTracシステムでデータを受信し、基本的な操作を実行できるプロトコル。

RTLSCPの基本部分は、3つのサブセットに分かれています。



●RTLSCP REST API（同期リソース）

●RTLSCP WebSocket API（ストリーミングデータ）

●RTLSCP非同期API（非同期コマンド）



したがって、誰でもアプリケーションサーバーをフラッシュしたり、カーネルに直接接続してシステムの基本機能を使用したりできます。 しかし、そのような愛好家はほとんどいませんでした。 したがって、4番目のサブセットはRTLSCP Extです。これは、クライアント固有の機能を備えたアプリケーションサーバーによって実装されるプロトコル拡張です。

ほとんどのクライアントはリアルタイム情報だけでなく、ビジネスプロセスで使用するために、一定期間のデータの配列、または簡単に言えば履歴を使用することが多いためです。 この点で、RTLSCP Extの機能の重要な部分は、特定の顧客のニーズに合わせてデータを保存および前処理/後処理する作業でした。 履歴を保持する必要があるため、アプリケーションのサーバー側にデータベースが表示されます。 時間の経過、内部データ構造の変更、新しいデータ構造の登場。 データストレージの形式は変化しており、顧客のニーズは増大していました。 結局、誰もがレポートをより速く収集し、同時により少ないスペースを必要とすることを望んでいます。 これらすべてが、データベース構造、サーバーアーキテクチャ、およびそのサポートの複雑さを複雑にしました。 処理されたデータの量の増加はサーバーの負荷の増加につながり、シングルスレッドNodeJSはサーバーの速度低下につながり、非同期性はそれを保存できませんでした。

最初は、特定のタスクに対して追加のワーカーを起動することで、パフォーマンスの問題が解決されました。 このために、標準モジュールクラスターが使用されました。 最初はそれが助けになり、しばらくの間誰もが幸せでした。

後に、これでは私たちにとって十分ではなく、多くのタスクを並列化したいという要望があることがわかりました。 しかし、既存のアーキテクチャでは、このような景品を作ることができませんでした。 また、立ち上げられた労働者の間でデータ同期の世話をする必要があり、大量のデータの交換が非常にスムーズに進まない状況がしばしば発生し始めました。

これらおよびその他の基本的な問題に関連して、システム全体のアーキテクチャ、特にアプリケーションサーバーのアーキテクチャを変更する決定がさほど前になされませんでした。

現在の状況に基づいて、新しいアーキテクチャに対して次の要件が作成されました。



1.タスクの並列化の容易さ

2.モジュラーシステムアーキテクチャ。



よく考えた結果、イベント指向のアーキテクチャを使用することになりました。 特に、共通のグローバルバスを介して相互にメッセージを交換するアクターのモデルを使用します。 このアプローチにより、負荷を分散すると同時に、簡単にスケーラブルなソリューションを取得できます。

古典的な理論では、アクターは次のプロパティを持つエンティティと呼ばれます：



●アクターは有限数のメッセージを作成できますが、

●アクターは、有限数の他のアクターを作成できますが、

●アクターは、入力に含まれるデータを使用していくつかの操作を行うことができます。



アクターの哲学またはモデルは、周囲のすべてがアクターであると想定しています。これは、OOPモデルと部分的に類似していますが、アクターの作成またはアクター間のメッセージ交換のシーケンスは定義されていません。

彼の人生の過程で、俳優は受け取ったデータに基づいて、いくつかの計算を実行し、データの新しい部分を生成します。これは、オブジェクトよりも「純粋な機能」に似ています。 アクターの主な長所は、アクションと並行性の有限性です。 理想的には、アクターは何にも依存せず、動作する環境について何も知らないエンティティです。

アクター間のデータの交換は、共通バスを介したメッセージの交換を通じて行われます。 メッセージは宛先指定できます。このため、アクターは宛先の詳細を知っているか、ブロードキャストする必要があります。

イベント駆動型アーキテクチャは、非常に疎結合であり、十分に分散されています。 さらに、メッセージの処理または配信はいかなる形でも規制されていないため、非同期の性質を持っています。



結論

新しいアーキテクチャはまだ完全には実装されていないため、これから得られる戦闘条件の長所と短所はまだ明確ではありませんが、コードがよりクリーンで、より透明で、よりシンプルになったことは明らかです。 新しい機能を追加すると、いくつかの新しいイベントとそのハンドラーが追加されます。 サーバーは完全にモジュール化されました。 最初のストレステストも励みになります。



PS：私にとって、マイクロモジュラーアーキテクチャは、Node.jsだけでなくプロジェクトを実装するための有望なアプローチです。 このアプローチにより、よりシンプルで透過的なコードを書くことができます。 小さなモジュールを使用することで、テストの記述手順を簡素化し、エラーのローカライズを高速化できることを忘れないでください。