クラスター アーキテクチャでは、サーバーは独自の役割を実行する必要がありますか?つまり、データベースサーバー、メモリサーバー、画像サーバーなどに分かれています。

プロジェクトの背景:
読み取りは書き込みより多く、比率は約 4:1、ユーザー数は 100 万人以上、同時実行数は約 4,000 (高または低、高から 10,000、低から 1,000)
複数のサーバーのパフォーマンスはほぼ同じであり、負荷分散は基本的に各サーバーに均等に分散できます

負荷分散を通じてユーザーと1対1で直接向き合ってほしい（つまりABCDに直接アクセスできる）。

それぞれの役割 (A と B がメモリ サーバー、C がデータベース、D が画像処理サーバーであると仮定) を実行させ、ユーザー アクセスをレイヤーごとに受け入れさせます。

アドバイスをください

返信内容:

プロジェクトの背景:
読み取りは書き込みより多く、比率は約 4:1、ユーザー数は 100 万人以上、同時実行数は約 4,000 (高または低、高から 10,000、低から 1,000)
複数のサーバーのパフォーマンスはほぼ同じであり、負荷分散は基本的に各サーバーに均等に分散できます

負荷分散を通じてユーザーと1対1で直接向き合ってほしい（つまりABCDに直接アクセスできる）。

それぞれの役割 (A と B がメモリ サーバー、C がデータベース、D が画像処理サーバーであると仮定) を実行させ、ユーザー アクセスをレイヤーごとに受け入れさせます。

アドバイスをください

別れた方が良いですよ。
分離していなければ、マシンのリソースを最大限に活用できるように思えますが、実際はそうではありません。さまざまな種類のサービスが一緒にデプロイされるため、サーバー環境が複雑になり、問題が発生しやすく、見つけにくくなり、パフォーマンスの最適化にも役立ちません。
サービスの種類が異なると、リソースに対する要求も異なります。メモリ サーバーはメモリに重点を置きますが、イメージ サーバーはディスクに重点を置きます。これらを一緒に導入すると、メモリのボトルネックが発生するとイメージ サーバーにも影響が生じます。ディスクリソースの無駄遣いになります。
したがって、それらは個別にデプロイされ、各サービスが配置される環境はシンプルで、必要に応じてリソースを割り当てることができます。

それぞれが独自の役割を果たします。分散クラスターの概念には、システムのさまざまな部分が含まれます。最初の解決策は負荷分散のみを実現し、文字通りの意味によれば、各マシンが対応するアプリケーションとデータベース サービスをインストールすることになるようですが、この場合、データ同期とファイル同期の問題により悲惨な結果になるため、古典的な解決策を採用します。機能的なハードウェアの下請けアーキテクチャ (あなたが言及した 2 番目のもの) の方がより適切な方法です。
アクセス層: ユーザーのニーズの受け入れと配布、負荷分散サービスのインストール、ネットワーク、メモリ、CPU に優先順位を付けるためのサーバーの構成を担当します。
アプリケーション キャッシュ レイヤー: ビジネスおよび使用頻度に応じてアプリケーション データをキャッシュします。このレイヤーの大部分はページ キャッシュです。ネットワーク、IO の優先順位。
アプリケーション層: アクセス層からの配布の受け入れ、要件の処理、および特定のプロジェクト アプリケーションのインストールを担当します。サーバーは、メモリ、CPU、IO を優先するように構成されています。 (サービス指向システムの場合、論理層、サービス層、永続化層などにさらに細分化される場合があります。特定のプロジェクトを詳細に分析してください)。
データ キャッシュ レイヤー: プロジェクトの背景に応じて、データベース インデックスをこのレイヤーに配置できます。また、ビジネス ニーズや特定のハードウェア構成に従って一部のデータ ディクショナリ テーブルを配置することもできます。ハードディスクとIOが優先されます。
データ層: データベース サービスとファイル ストレージ サービスをインストールします。データベース サービスは、説明に基づいて読み取りと書き込みを分離するように構成できます。データ量が比較的多い場合は、データベースのサブデータベース設定も考慮する必要があります。ハードディスクとIO優先度を設定します。
上記のすべてのサーバーに加えて、各層のサーバーはアクティブ/スタンバイの原則に従って耐災害性を備えている必要があります。
もちろん、ハードウェアの範囲外のアーキテクチャはすべて空の話です。どのような種類のサーバーがあるかはわかりませんが、可能な限り同様の構成を変更し、それに応じて適切な変更を加えてください。十分なマシンがないため、仮想マシンを分割することを検討できますが、パフォーマンスを最大化するための特定の構成の構成方法は、ストレス テストとその後のチューニングによって異なります。

2番目のオプションを採用することをお勧めします。

全員が分離するのは良くないと思います。サーバーがクラッシュした場合、プログラムが最初に保証しなければならないのは、サーバーの複雑さを増すために 1 つのサーバー上で複数のプログラムを実行することです。問題は、個々のサービスが実際にはサーバー上で無関係であるということです。分散と分散を行うサーバーが 4 つある場合は、サービスの拡張と転送が容易になります。すべてを 1 台のサーバーで実行できますが、分散システムのような拡張性はなく、パフォーマンスがボトルネックになります。全体として、最初のオプションは 2 番目のオプションよりもはるかに柔軟だと思います

被験者が報告するサービスレベルについては、別途に行う必要があります。

主に 2 つの考慮事項があります:

• サービスの種類が異なれば、要件やさまざまなマシン リソースの消費も異なり、マシンは必要に応じてカスタマイズできます。上の階の他の生徒もこう言ってました

• さらに、さまざまなサービスを組み合わせると、特に潜在的に影響を与える可能性のあるサービスを展開すると、メンテナンスのコストが増加し、システムが不安定になります。極端な例として、テスト環境と運用環境を一緒に展開してテストを調整することを検討することもできます。実稼働環境に影響を与える環境パラメータは、実際には最も避けるべきことです。

さらに、複数の場所にデプロイする場合、実際には複数の問題シナリオに対処する必要があると誰かが言及しました。これは全く逆だと思います

• まず第一に、ビジネス層はサービス層が安全で安定していると常に想定できるわけではなく、サービス層の障害に対するサーキット ブレーカー メカニズムを許容する必要があります
  。
• 次に、すべてのサービスが 1 つのマシン上に配置されます。1 つのマシンがハングアップした場合 (たとえば、ディスクがいっぱい、メモリがいっぱい、CPU が爆発したなど)、すべてのサービスがハングダウンします。飛散しても個々のサービスに損害が生じるだけです。

• 初期段階では、運用保守コストも考慮して、Web サーバーとバックエンド サービスを統合する場合があります。後半のトラフィックとプレッシャーの増加後、私たちは間違いなく分業と専門化の方向に取り組み続けます。

上記は主に私の個人的な理解です、参考にしてください〜

それは必要です。もちろん、サーバーはそれぞれの役割を果たさなければなりません。サーバーは分散方式で展開する必要があります。交通の圧力に直面しても横方向に拡張します。災害復旧サーバーも必要です。 1 つのサーバーに障害が発生した場合、他のサーバーが引き継ぎます。

この問題の本質は、水平方向のスケーラビリティにあります。負荷分散を通じてのみ ABCD にアクセスできる場合、スケーラビリティを放棄することになります。

そのため、独立したサービスについては ABCD を分離することをお勧めします

その後、システムのどの部分がボトルネックになっているかを分析し、負荷分散、マシンの拡張、分散などを行う必要があります。

別居するのが最善です

あなたのアプリケーションは常に成長しています

今はこの段階に達しています
今は別居しなくても
将来的には別れるでしょう。