node.js が大規模プロジェクトに適さない理由

序文

まず、大規模アプリケーションとは何かを明確にする必要があります。実際、これは意見の問題であり、技術的な問題ではなく哲学的な問題です。ユニクロのようなオンライン販売ができるウェブサイトは大きいですか？と聞かれたら、確かに、これは通常目にするブログや企業の Web サイトなどのロジックよりもはるかに複雑なので、大きなことだと言えるかもしれません。あるいは、それが小さい場合は、それよりも複雑なシステムを開発したことを意味します。それで、Taobao と比べるとどうでしょうか?大きいものと小さいものの比較には基準が必要です。

1. アプリケーションコンポーネント

完全な Web アプリケーションを 1 つの言語または 1 つのテクノロジーのみで構成することは可能ですか?不可能。完全な Web アプリケーションは実際には複数のテクノロジの組み合わせであるため、特定の問題を解決するためのソリューションは多数存在します。たとえば、Java、PHP、Python、Ruby など、バックエンドの論理ソリューションは多数存在します。

簡単にまとめると、アプリケーションのコンポーネントには次のものが含まれます。

Web インターフェイス表示ロジック、バックエンド ビジネス ロジック、キャッシュ、データベース、メッセージ キュー。

実際には、ログ分析、データ分析なども追加できますが、上記は最もよく知られているものにすぎません。

2. アプリケーションの種類

I/O 集約型、CPU 集約型。

一般的なインターネット製品の場合、ボトルネックとなるのはバックエンド業務のロジックではなく、I/O、つまりユーザーに返されるデータの読み取りと出力です。アプリケーションの場合、読み取りはデータベースからデータを取得することを指し、出力は特定の処理の後にこのデータをユーザーのブラウザに出力することを指します。これは I/O を大量に消費します。

CPU 集約型とは、頻繁にコンピューティング タスクを実行するアプリケーションを指しますが、Node.js は確かにこの点では欠点があります。

3. アプリケーションサービスプロセス

図に示すように、ユーザーはブラウザを通じてリクエストを送信し、ネットワーク カードは TCP 接続を受信して​​カーネルに通知し、カーネルは対応するサーバー プログラムを呼び出します。

リクエスト リクエストプロセス

レスポンス返信プロセス

下の図に示すように、Web アプリケーションがデータを返す場合、まずデータを取得し、カーネルを介してディスク ドライバーを呼び出して、データをキャッシュに読み込む必要があります。このようにして、Web アプリケーションでデータを取得して処理し、最後にカーネルを呼び出して、ネットワーク カードを介してクライアントにデータを送信します。

4. アプリケーションのボトルネック

通常、I/O 集中型サービスのボトルネックとなるのはディスクの読み取りと書き込みであるため、クラウド サーバーを購入する際に SSD ディスクを購入してパフォーマンスを向上させることができます。通常、データベース ソフトウェアのデータはファイルに保存されます。まず、このボトルネックを解決するためにメモリ キャッシュを追加することを検討してください。頻繁にアクセスされるデータをキャッシュして、Redis を使用するなどして、現在のシナリオで問題を解決できるかどうかを確認します。次に、同時実行性を向上させるために、データベース クラスターの構築または拡張を検討します。

CPU を集中的に使用するアプリケーションのボトルネックとなるのは CPU であり、このボトルネックを解決する唯一の方法は CPU 処理コアを増やすことです。

5. 分散アプリケーション

大規模な通常のアプリケーションと分散アプリケーションは、実際には異なる概念です。読者は、分散アプリケーションを、各メンバーがノードであるチームとして簡単に理解できます。大規模なプロジェクトでは、メンバーが協力して完了する必要があるため、メンバー間のコミュニケーションに多少のコストがかかります。メンバーの中には、陰謀を企てたり、不誠実な発言をしたり、責任を逃れたりする人もいます。また、メンバーが病気で自宅で療養していて、仕事ができない、といったことも考えられます。こうした問題に直面すると、Node.js の利点を十分に発揮できません (できないわけではないのですが、完璧なインフラが存在しないのです)。

分散の真の定義は、複数の異なるサーバーに異なるサービス モジュールを展開し、プロセスを基本単位としてサーバーにディスパッチし、リモート プロシージャ (RPC) を介して通信して連携し、最終的に外部にサービスを提供することです。

Node.js の現在の分散インフラストラクチャと比較すると、Go 言語のインフラストラクチャははるかに充実しており、特に Docker プロジェクトでは Go 言語の利点が十分に発揮されています。これが、Node.js コミュニティの「大物」である TJ Holowaychuk が分散アプリケーションを開発したいと考え、Go 言語に目を向けた理由です。

実際のところ、配布の問題をあまり心配する必要はありません。結局のところ、JavaScript はもともとブラウザ上で実行されるスクリプト言語にすぎませんでした。JavaScript は万能ではないのに、なぜオペレーティング システム レベルの開発で使用しなければならないのでしょうか。もっと適切な言語を見つけた方が良いのではないでしょうか?今と同じように、Web アプリケーションを構築するには JavaScript を選択します。

6. マルチプロセス Node.js

上記の知識ポイントを理解した後、読者は Node.js が大規模なアプリケーションとはほとんど関係がないことを理解しているはずです。 Node.js を学ぶ開発者のほとんどはフロントエンド開発者であるため、バックエンドの基礎知識を知りません。インターネットで情報を検索すると、Node.js は 1 つのコアしか使用できないことがわかります。TJ Holowaychuk が Go 陣営に転向したと聞いて、Node.js は大規模なアプリケーションの開発に適していないのではないかと考える開発者もいます。

Node.js が 1 つのコアしか使用できないという問題は解決されました。後で使用する Egg.js フレームワークの Egg-Cluster モジュールは、複数のプロセスを使用することでこの問題を非常にうまく解決します。

上記は、node.js が大規模プロジェクトに適していない理由の詳細です。node.js の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。