15

私は「従来のWebアプリケーション」のバックグラウンドを持っています。Java、.NET、PHP、ColdFusionなどを考えてみてください。

自明でないアプリケーションの主要なサーバー側テクノロジとして使用するNodeJSを評価する際に、NodeJSに固有の、開発者と運用のチームが直面する可能性のある複雑さ、問題、課題について疑問に思います。要するに、私は私の未知数を減らしたいのです。いくつかの（すべてではない）例：

  • 大規模なチームの開発にどの程度役立ちますか？20人、50人、または200人の開発者のチームには、ノードにとってどのような固有の課題がありますか？
  • データベースアクセスに関して、どのような固有の課題がありますか？「エンタープライズ」データアクセスの懸念は、Java（接続プール、セキュリティなど、Spring経由）ではほとんど簡単に処理されます。これはNodeの場合ですか？
  • レポートが多いアプリケーションでは、Excel、PDF、さらにはPNGのエクスポートが必要になることがよくあります...このタイプのアプリケーションでは、Nodeはどのように機能しますか？
  • Nodeは、開発時のデバッグに関して独自の課題を提示しますか？
  • どのような独自の運用上の課題がありますか？サーバーの再起動/ホットコードの交換/負荷分散から、運用クラスターを監視および管理するためのツールまで、すべてが含まれます。

などなど。サーバーのファーム全体に展開され、数十人の開発者が触れた100 + K LoCコードベースの開発、保守、および本番管理にはどのような教訓がありますか？

4

2 に答える 2

6

私はあなたの質問のいくつかに答えようとします

大規模なチーム開発にどの程度適していますか? 20 人、50 人、または 200 人の開発者のチームで、Node に固有の課題は何ですか?

  • 他のすべての言語と同じように行います。なし！プログラマーのチームは通常、git、svn、mercurial などのバージョン管理システムを使用して、同じファイルで作業している同僚に対処します。

データベースへのアクセスに関して、どのような固有の課題がありますか? 「企業向け」のデータ アクセスに関する問題は、ほとんどが Java で簡単に処理されます (接続プール、Spring によるセキュリティなど)。これはノードの場合ですか？

  • ノードはデータベースに依存しません。ドライバー/ラッパーが存在するノードで任意のデータベースを使用できます (PHP と同じ)。リレーショナル データベース (MySQL、SQLite) および NoSQL (MongoDB) 用の多くのドライバー/ラッパーがあります。

レポートを多用するアプリケーションでは、多くの場合、Excel、PDF、さらには PNG エクスポートが必要です... このタイプのアプリケーションで Node はどのように機能しますか?

  • ノードは、php などと同様に、通常のシェルにアクセスできます。したがって、php で画像を処理する場合は、ImageMagick または GD のラッパーを使用しています。GD を機能させるには、WebServer に GD をインストールする必要があります。これは、php がコマンドをコマンド ラインに送信するためです。ノードと同じ。ラッパー (http://search.npmjs.org) を見つけて、必要な機能を使用してください。

開発時のデバッグに関して、Node に固有の課題はありますか?

  • ノードは Javascript であるため、コンパイルはされませんが、JIT は実行されます。したがって、失敗は実行されるとすぐに検出されます。ステージング/開発マシンとライブ サーバーの隣にすべての開発者用のローカル環境が必要な場合は、コードをステージング サーバーにコミットする前にコードをテストできるようにします。

どのような固有の運用上の課題が存在しますか? サーバーの再起動/ホット コード スワップ/負荷分散から、運用クラスターを監視および管理するためのツールまで、すべてが含まれます。

  • 私が認識している「ユニークな」課題はありません。他のすべての言語と同様に、監視/ハートビートを処理します (そうです、Erlang のようにこれを行う言語があります)。サーバーの再起動時にノードを起動するには、forever や Supervisord などのサービスが必要ですが、それは Apache+PHP/Perl でも同じです。
  • (ノードには、複数のワーカーを処理するのに役立つクラスターモジュールがあります (マルチコアサーバーの場合))

コードの管理については Git を参照してください。やりたいことに基づいて言語を選択します (高い同時実行性、スケーラビリティ)。

于 2012-10-08T13:05:30.897 に答える
4

私が資格を持っていることについてコメントします：

  1. データ ソースへの接続プール。 標準の Node HTTP(S) サーバー ツールはデフォルトでプーリングを実装しており、パフォーマンスを改善または制御するために構成できるノブがあります。コミュニティは非常に活発で、汎用または特殊な接続プーリングを実装する他の多くのプロジェクト ( pooleeなど) があります。周りを見回す必要があります。実際、あなたの伝統的な Webdev のバックグラウンドを考えると...

    1.1補足: サードパーティのライブラリNode で開発する場合、多くのサードパーティのライブラリ を使用していることに気付くかもしれません。あなたの特定のバックグラウンドによっては、これは奇妙に思えるかもしれません。その理由を理解するには、.NET または Java を考えてみてください。これらのプラットフォームの標準ライブラリはgargantuanです。その結果、これらのプラットフォームを使用する場合、作業を完了するのに役立つサードパーティのツールやプラグインをほとんど選択しない場合があります. 比較すると、ノードには、意図的に狭く厳密に制御された標準ライブラリがあります。サーバーのパフォーマンスのために「記述方法」を統一するために必要な API はすべてありますが、それ以上のものはありません。

    サードパーティ ライブラリの管理を支援するために、npmパッケージ マネージャーが設計され、非常に早い段階でノードに含まれていました。クオリティが高いと評判です。作成者は明らかに、多くのサードパーティによる使用を予期していました。

  2. 計算能力 画像のエクスポートについて言及されました。これらすべてのJavascriptライブラリが存在するので、「簡単にできる」ならできます。計算負荷の高いタスクがある場合、Javascript はコア計算を実装するのに最も効果的な言語ではない可能性があることに注意してください。v8 エンジンでは、必要に応じて C でモジュールを記述できますが、特殊なバックエンド サーバーにリクエストを転送することは、Node.js が非常にうまく行うことです。

  3. 運用上の課題 Node.js はハードウェアに合わせてスケールアップしません。サーバーに複数のコアがある場合 (今では確実にそうです)、高い使用率を達成するには、同じ物理ハードウェア上で複数のサーバー プロセスを実行する必要があります。これにより、操作のイメージが異なる場合があります。通常よりも多くのプロセスが表示され、それらのプロセスは物理マシンまたは仮想マシンごとにグループ化できます。

    ところで、サーバーをプロセスに分割することは、信頼性にとって悪いことではありません。1 つの大規模な従来のプロセスは、未処理の例外でクラッシュし、アクティブなセッションの 8 (またはその他の) コアに相当するものをダウンさせます。複数のノード プロセスは個別にクラッシュしますが、それに比例して影響は小さくなります。パフォーマンスと監視可能性の両方を考慮して、「いくつのプロセスが多すぎるか」という点を検討する余地があるでしょう。利用可能なコアよりも多くの Node プロセスをサーバーごとに使用することは、実際には価値があるかもしれません。

于 2012-10-08T13:24:20.807 に答える