リバース プロキシを構成するために 2 つのサーバーを使用します。
サーバー A は、次の構成を通じてすべてのリクエストをテスト サーバー グループに転送します (ただし、グループには 1 つしかありません)
ブラウザ経由でサーバー A にアクセスすると、サーバー B のコンテンツが返されます。
ここで質問があります:
1. サーバー B (リバース プロキシ サーバー) には構成が必要ないようです。
2. プロキシ サーバーにブロック設定がない限り、リバース プロキシ サーバーとしてアップストリームに参加できますか?
3. 負荷分散にリバース プロキシを使用する場合、サーバー B のプロジェクトはサーバー A のプロジェクトと一致する必要がありますか?
ポイント 1: 簡単に言うと、プロキシ オブジェクトには設定は必要ありませんが、B でリクエストのソース IP を処理したい場合は、A の nginx で何らかの設定を行い、変更する必要があることに注意してください。送信元 IP たとえば、リクエストヘッダーに含めます。
ポイント 2: アップストリームを使用したことがない、通常は proxy_pass を使用しますリーリー
ポイント 3: 一般的に言えば、そうです。1 プロキシサーバー B には設定は必要ありません
2 上流に複数のサーバーグループを追加する、いわゆる負荷分散構成です。次に、proxy_pass を設定します
3. 負荷分散されたサーバーは理論的にはデータを共有し、同じビジネスを行いますが、サーバーの負荷を軽減するために異なるマシンに分散してデプロイされます。 (投稿者は、同じサーバー上の異なるポートで同じビジネスで複数のサービスを開始し、負荷分散を構成して検証することができます自分で行ってください!)
現在、負荷分散戦略にはいくつかの方法があります
ポーリング (デフォルト): 各リクエストは時系列に 1 つずつ異なるバックエンド サーバーに割り当てられ、バックエンド サーバーがダウンした場合は自動的に削除されます。
weight: ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。
ip_hash: 各リクエストは、アクセスされた IP のハッシュ結果に従って割り当てられるため、各訪問者はバックエンド サーバーに固定的にアクセスでき、セッションの問題を解決できます。
fair (サードパーティ): バックエンドサーバーの応答時間に応じてリクエストを割り当て、応答時間の短いリクエストを優先します。
url_hash (サードパーティ): アクセスされた URL のハッシュ結果に従ってリクエストを分散し、各 URL が同じバックエンド サーバーに送られるようにします。バックエンド サーバーがキャッシュされている場合、より効果的です。