0

システムのアーキテクチャを設計しています。(JavaEE / Spring)

このシステムの主な要因は、低遅延です(エンドツーエンドで約1ミリ秒以下で話します)

このリアルタイムシステム用にいくつかのコンポーネントを計画しました。

専門家への私の質問:カップリングとデカップリングのすべての利点を知っています(フェイルオーバー、分離、メンテナンス、拡張など)。

私がここで直面している問題は次のとおりです。

たとえば、マシンA(app1)に2つの異なるアプリケーションがあり、マシンB(app2)にアプリケーションがあるとします。

リクエストは両方のマシンを経由する必要があります。両方のマシンがリクエストを処理した後、最終的な回答がクライアントに送信されます。

これら2つの間の統合遅延は、同じマシン上にこれらのアプリを配置する場合よりも確実に長くなります(ネットワーク時間など)。

一方、同じマシンに依存することなく、各アプリケーションを独自に更新および保守することができます。フェイルオーバー、クラスタリング、負荷分散についても同じことが言えます

何をアドバイスしますか?私は何を考慮すべきですか?レイテンシーとデカップリングおよびメンテナンス

ありがとう、レイ。

4

2 に答える 2

2

リクエストは両方のマシンを経由する必要があります。両方のマシンがリクエストを処理した後、最終的な回答がクライアントに送信されます。

0.1〜0.2ミリ秒追加される可能性があります。これは許容できるかもしれません。

一方、同じマシンに依存することなく、各アプリケーションを独自に更新および保守することができます。

ハードウェアよりもソフトウェアを更新する可能性が高くなります。Hadrwareは通常、週末などのオフピーク時に更新できます。

フェイルオーバーについても同じことが言えます。

マシンが多ければ多いほど、障害点が多くなります。

クラスタリング

すべてが1台のマシンにある場合は、クラスター化する必要がない場合があります。

負荷分散

複数のマシンを使用する必要がある場合、これはより理にかなっています。

Webアプリケーションを使用している場合、1ミリ秒はかなり攻撃的なターゲットです。トレーディングシステムなどのネットワークサービスを利用している場合は、要件に応じて1ミリ秒未満または100マイクロ秒未満でさえ達成可能です。

于 2012-09-20T12:57:45.247 に答える
0

同じリクエストを処理するマシンが多いほど、レイテンシが長くなります。これは明らかです。さらに、アプリケーション間のすべての境界(JVM、スレッド)を排除し、同じスレッドで順次呼び出される2つのプロシージャとしてそれらを実装します。

マシンが増えると、1つのケースでレイテンシーを減らすことができます。つまり、負荷を分散して1台のマシンのリソース(プロセッサー)を解放し、輻輳を解消します。さまざまな商品(通貨、株式)をさまざまなマシンで取引しましょう。

于 2012-09-20T13:21:43.497 に答える