2

複数の Node/Express アプリを一連のサーバー (ロード バランサーの背後) にデプロイする必要があります。これらのアプリは、機能面で互いに完全に独立しています。最初に、これをどのように行うことを考えているかを説明し、次に、設計に危険信号がある場合など、ベスト プラクティスに関する意見を求めます。

私が考えている設定は次のとおりです。

ロード バランサーの背後にあるフロントエンド サーバーでは、node-http-proxy が実行され、ポート 80 で着信要求を受け入れます。このリバース プロキシは、このサーバーの異なるポートで実行されている適切なノード アプリに要求をルーティングします。例：

var http = require('http'),
    httpProxy = require('http-proxy');

var options = {
  router: {
    'myapphost.com/MyFirstApp': 'myapphost.com:3000',
    'myapphost.com/MySecondApp': 'myapphost.com:3001'
  }
}

// ...and then pass them in when you create your proxy.
var proxyServer = httpProxy.createServer(options).listen(80);

各ノード アプリは、Cluster2 などを使用してノード クラスター上で実行され、マルチコア システムを利用します。

私の質問:

  • これは正しい設計と戦略ですか?
  • 一部のアプリケーションはステートフルにする必要があります。この種のセットアップで状態管理を行う最良の方法は何ですか? Redis などの外部セッション ストレージを使用することは正しいアプローチですか? または、特定のフロントエンド マシンにセッションを固定し、インメモリ セッション ストレージを使用しますか?

アップデート：

この質問を投稿してから、何人かと話した後、もう 1 つのアプローチが思い浮かびました。

フロントエンド マシンの前で Nginx をリバース プロキシおよびロード バランサーとして使用できます。各フロントエンド マシンは 1 つのアプリのみを提供します。そのアプリ用にもう 1 台のバックアップ マシンが存在する可能性があります。(要件に応じて)。したがって、3 つのアプリがある場合は、それぞれが異なるアプリを提供する 3 つの別個のマシンを用意します。すべてのリクエストはポート 80 で Nginx によって受信され、Nginx リバース プロキシはリクエストを適切なフロントエンド マシンにルーティングします。各マシンには、マルチコア システムを利用するためのノード クラスターがあります。このアプローチの利点は、各アプリの展開が非常に簡単になることです。また、各アプリを個別にスケーリングできます。

このアプローチについても、ご意見をお聞かせください。

4

1 に答える 1

0

これは正しいアプローチです。redisについて言及したか、 connect-mongoやその他のセッション ストレージなどの他のセッション ストレージを使用することもできます。
Load Balancer を使用している場合、同じサーバーの複数のインスタンスがあると思いますか? この場合は、セッションのパフォーマンスとその使用量を分析してから、セッション ストレージ/データベースを分割する必要があるか、またはバランスの取れたすべてのインスタンスが通信する 1 台のマシンを分割する必要があるかを決定する必要があります。

あなたはすでに正しい方法を考えています。それをハッキングして、ニーズに合っているかどうかを確認してみませんか?

同様に、静的メディアについても考える必要があります。おそらく個別に保存する必要があります (S3 + CloudFront?)。
また、アプリケーション ロジックの一貫性を保ちながら、インスタンスに更新を配信して再起動する方法についても説明します。

この構造は、AB テストの可能性も可能にします (アプリケーションの「テスト バージョン」を使用して特定のインスタンスに負荷を分散できます。大部分はメイン インスタンス間で分散されます。

それはすべて規模にも依存します。最初はあまり必要ない場合もあります。将来の改善と拡大に備えるだけです。

于 2013-10-15T09:49:46.383 に答える