6

ノードアプリを継続的に実行したい。アプリの作業中にいくつかのクラッシュが発生する可能性があると確信しています。最近では、アプリを継続的に機能させる 3 つの方法を見ることができます。

  1. foreverでアプリを起動するため、アプリが永久にクラッシュすると、自動的に再起動します
  2. ドメインモジュールを使用してエラーをキャッチし、「エラー」イベントが発生したときにアプリを再起動します
  3. 非推奨の process.on('uncaughtException')

問題は、これら 3 つの方法のうちどれを使用するのがよいかということです。この質問に対する正確な答えはないように思われるので、コメントを歓迎します。

私の意見では、ノードプロセスのメモリ消費は時間とともに増加しないため、最初のものの方が適切です-ノードプロセスが永久にクラッシュするたびに、別のプロセスが開始されます。

4

1 に答える 1

10

ああ、それはトリッキーな質問です。まず、Node プロセス全体の再起動を強制しないという点で、domainsアプローチは とは異なります。foreverたとえば、Node アプリケーションが複数のクライアントからのリクエストを同時に処理するとします。ドメインを慎重に構成することで、(少なくとも理論上は) リクエストの 1 つがエラーをスローしたときに他のリクエストが失敗するのを防ぐことができます。

ただし、実際には、ドメインを機能させるには、アプリケーションの一部のコンポーネントを認識させる必要がありますdomain。これは、サードパーティ コンポーネントにも当てはまります。たとえば、接続のプールを内部で使用するデータベース接続モジュールは、それらを独自のドメインにラップするのではなく、コールバックにすでにドメインがアタッチされているかどうかを確認する必要があります。そうしないと、データベース コードでスローされた例外がモジュール自体のドメインでキャッチされ、ドメインはそれを認識できません。したがって、サードパーティのコードでドメインを使用するには、そのコードがdomains念頭に置いて作成されているかどうかを最初に確認する必要があります。

foreverクラッシュするたびにアプリケーションを再起動するだけです。よりも悪い考えのようにdomains思えますが、サードパーティのコードに対して特定の要件を課すこともありません。したがって、必要なライブラリまたはモジュールを使用できます。また、複雑なエラー回復ロジックをコードに入れる必要もありません。障害のない複雑なコードベースよりも、単純なコードベースの方が重要な場合があります。

私はそれprocess.on('uncaughtException')を使用しません。現在は廃止されているため、いつか削除される可能性があります。

これが私の内訳です：

  1. forever

    長所：

    • コードベースをよりシンプルで小さく保つことができます
    • 最初にアプリケーション ロジックを記述し、後でエラー処理について考えることができます

    短所：

    • キャッチされなかった 1 つの例外により、他のすべての要求が失敗する

    次の場合に使用します。

    • Nodeプロセスとリクエストは安価です
    • クライアントはエラー時に再試行できます

  2. domains

    長所：

    短所：

    • ドメイン対応のサードパーティ ライブラリで使用可能
    • プログラムに追加のロジックが必要

    次の場合に使用します。

    • リクエストまたは Node プロセスは高価です (ファイルのアップロード、データのストリーミングなど)。
    • 単一ノードのアップタイムが重要

  3. process.on('uncaughtException')使用しないでください。

ノート

  1. Isaac Z. SchlueterとFelix Geisendörferが NodeUp の第 13 回エピソードでドメインについて話しました

  2. と Unix の の違いを説明した最近の記事foreversystemdがあります。役に立つかもしれません。

于 2013-01-30T21:36:09.600 に答える