Python Web導入方法のまとめ

サーバーを裸で実行させないでください

PHP を勉強したことのある人なら誰でも、PHP の正式な環境へのデプロイはいくつかのファイルを変更するだけで非常に簡単であることを知っています。FastCgi メソッドを使用することも数分の問題です。 。それに比べて、Web アプリケーションでの Python のデプロイメントは、主に多数のツールと主流サーバーからのサポートが不十分であるため、はるかに複雑です。Python の実稼働環境のデプロイメント方法を理解する前に、いくつかの概念を明確にしましょう。とても重要です！

CGI:

CGIは共通ゲートウェイインターフェースです インターフェース）とは、外部アプリケーション（CGIプログラム）とWebサーバー間のインターフェース規格で、CGIプログラムとWebサーバー間で情報をやり取りするための手順です。 CGI 仕様により、Web サーバーが外部プログラムを実行し、その出力を Web ブラウザに送信できるようになり、Web の単純な静的ハイパーメディア ドキュメントのセットが完全に新しい対話型メディアに変わります。平たく言えば、CGI は Web ページと WEB サーバーの実行プログラムを接続する橋のようなもので、HTML で受け取った命令をサーバーの実行プログラムに渡し、サーバーの実行プログラムの結果を HTML ページに返します。 。 CGI クロスプラットフォームのパフォーマンスは優れており、ほぼすべてのオペレーティング システムに実装できます。

CGI メソッドは、接続要求 (ユーザー要求) が発生したときにまず CGI サブプロセスを作成し、CGI プロセスをアクティブにしてから要求を処理し、処理後にサブプロセスを終了する必要があります。これはフォークして実行するパターンです。したがって、CGI を使用するサーバーには、接続要求と同じ数の CGI サブプロセスが存在することになり、サブプロセスの繰り返しロードが CGI パフォーマンスを低下させる主な原因となります。ユーザーリクエストの数が非常に多い場合、メモリやCPU時間などのシステムリソースが大量に占有され、パフォーマンスが低下します。

CGI スクリプトのワークフロー:

1. ブラウザは、HTML フォームまたはハイパーリンクを介して CGI アプリケーションを指す URL をリクエストします。

2. サーバーはリクエストの送受信を行うサーバーを実行します。指定された CGI アプリケーション。

3. CGI アプリケーションは、通常、ビューアからの入力に基づいて、必要な操作を実行します。

4. CGI アプリケーションは、結果を Web サーバーとブラウザが理解できるドキュメント (通常は HTML Web ページ) にフォーマットします。

5. Web サーバーは結果をブラウザに返します。

Python には、ネイティブ CGI プログラムをサポートする CGI モジュールがあります

FastCGI:

FastCGI は、HTTP サーバーと動的スクリプト言語間の通信のためのスケーラブルな高速インターフェイスです。最も人気のあるHTTP サーバーはすべて、Apache、Nginx、lighttpd を含む FastCGI をサポートしています。同時に、FastCGI は Python を含む多くのスクリプト言語でもサポートされています。 FastCGI は CGI を発展させて改良したものです。従来の CGI インターフェイス方式の主な欠点は、パフォーマンスが低いことです。これは、HTTP サーバーが動的プログラムに遭遇するたびに、スクリプト パーサーを再起動して解析を実行する必要があり、結果が HTTP サーバーに返されるためです。これは、同時アクセスが多い場合にはほとんど利用できません。 FastCGI は長寿命 CGI のようなもので、アクティブ化されている限り、毎回フォークするのに時間がかかりません (これは CGI の最も批判的なフォークアンド実行です)。 モデル）。 CGI はいわゆる寿命の短いアプリケーションであり、FastCGI はいわゆる寿命の長いアプリケーションです。 FastCGIのおかげで プログラムは新しいプロセスを継続的に生成する必要がないため、サーバーへの負荷が大幅に軽減され、アプリケーション効率が向上します。その速度効率は CGI テクノロジーの少なくとも 5 倍です。また、分散コンピューティングもサポートしています。 FastCGI プログラムは、Web サーバー以外のホスト上で実行でき、他の Web サーバーからのリクエストを受け入れることができます。

FastCGI は、言語に依存しないスケーラブルなアーキテクチャの CGI オープン拡張機能であり、その主な動作は CGI インタープリター プロセスをメモリ内に保持し、より高いパフォーマンスを実現することです。ご存知のとおり、CGI インタープリタの繰り返しロードが CGI パフォーマンス低下の主な原因です。CGI インタープリタがメモリ内に残り、FastCGI プロセス マネージャーのスケジューリングを受け入れる場合、良好なパフォーマンス、スケーラビリティ、フェイルオーバー機能などが提供されます。 FastCGI インターフェイスは C/S 構造を採用しており、HTTP サーバーとスクリプト解析サーバーを分離し、スクリプト解析サーバー上で 1 つ以上のスクリプト解析デーモンを起動できます。 HTTP サーバーが動的プログラムに遭遇するたびに、そのプログラムは実行のために FastCGI プロセスに直接配信され、その結果がブラウザーに返されます。この方法により、HTTP サーバーは静的リクエストを排他的に処理したり、動的スクリプト サーバーの結果をクライアントに返すことができるため、アプリケーション システム全体のパフォーマンスが大幅に向上します。

FastCGI ワークフロー:

1. Web サーバーの起動時に FastCGI プロセス マネージャー (PHP-CGI または PHP-FPM または spawn-cgi) をロードします

2. FastCGI プロセス マネージャーは自身を初期化し、複数の CGI 解釈サーバー プロセス (複数のphp-cgi が表示されます)、Web サーバーからの接続を待ちます。

3. クライアントのリクエストが Web サーバーに到達すると、FastCGI プロセス マネージャーが CGI インタープリターを選択して接続します。ウェブ サーバーは CGI 環境変数と標準入力を FastCGI サブプロセス php-cgi に送信します。

4. FastCGI サブプロセスが処理を完了すると、同じ接続から標準出力とエラー情報が Web に返されます。 サーバ。 FastCGI 子プロセスが接続を閉じると、リクエストが処理されます。次に、FastCGI 子プロセスは、(Web 上で実行されている) FastCGI プロセス マネージャーからの要求を待機して処理します。 サーバー）次の接続。 CGI モードでは、php-cgi はここで終了します。

FastCGI の特徴:

1. 従来のページ処理テクノロジーを打ち破ります。従来のページ処理テクノロジでは、プログラムは Web サーバーまたはアプリケーションと通信する必要があります。 サーバーは同じサーバー上にあります。この歴史は、N 年前に FastCGI テクノロジによって破られました。FastCGI テクノロジ アプリケーションは、TCP/IP 経由でサーバー グループ内の任意のサーバーにインストールできます。 このプロトコルは Web サーバーと通信します。これは、大規模な分散 Web グループの開発と効率的なデータベース制御の両方に適しています。

2. 明示的リクエストモード。 CGI テクノロジーは FastCGI において明確な役割を持っていない プログラムでは、プログラムに明確な役割（レスポンダー役割、オーセンティケーター役割、フィルター役割）が割り当てられます。

WSGI：

Python Webサーバーゲートウェイ インターフェイス (WSGI と略されます) は、Web サーバーと、Python 言語用に定義された Web アプリケーションまたはフレームワークとの間のシンプルで共通のインターフェイスです。 WSGI が開発されて以来、同様のインターフェイスが他の多くの言語にも登場しました。 WSGI は、Web サーバーと Web アプリケーションまたはアプリケーション フレームワークの間の低レベル インターフェイスとして機能し、ポータブル Web アプリケーション開発の共通基盤を向上させます。 WSGI は既存の CGI 標準に基づいて設計されています。

WSGI は 2 つの部分に分かれています。1 つは「サーバー」または「ゲートウェイ」で、もう 1 つは「アプリケーション」または「アプリケーション フレームワーク」です。 WSGI リクエストを処理するとき、サーバーはアプリケーションに環境コンテキストとコールバック関数 (Callback) を提供します。 関数）。アプリケーションがリクエストの処理を完了すると、結果は前のコールバック関数を通じてサーバーに返されます。いわゆるWSGI ミドルウェアは API の両側を実装するため、WSGI サービスと WSGI アプリケーションの間を仲介します。WSGI サーバーの観点からは、ミドルウェアはアプリケーションの役割を果たし、アプリケーションの観点からは、ミドルウェアは WSGI サービスの役割を果たします。アプリケーションサーバー。 「ミドルウェア」コンポーネントは次の機能を実行できます:

1. 環境変数を書き換えた後、ターゲット URL に基づいてリクエスト メッセージをさまざまなアプリケーション オブジェクトにルーティングします。

2. 複数のアプリケーションまたはアプリケーション フレームワークを 1 つのプロセスで同時に実行できるようにします。

3. ネットワーク全体で要求および応答メッセージを転送することによる負荷分散とリモート処理。

4. XSLT スタイルシートの適用など、コンテンツの後処理。

これまで、適切な Web アプリケーション フレームワークをどのように選択するかが Python 初心者にとって悩ましい問題となっていました。これは、一般的に言えば、Web アプリケーション フレームワークの選択によって利用可能な Web サーバーの選択肢が制限されるためです。当時の Python アプリケーションは通常、CGI、FastCGI、mod_python のいずれか、または特定の Web サーバー用のカスタム API インターフェイス用に設計されていました。 WSGI の正式な実装はありません。 WSGI はプロトコルに似ているためです。これらのプロトコルに従っている限り、WSGI アプリケーションはどのサーバーでも実行できます。 逆に。 Fastcgi が PHP の CGI ラッパーであるのに対し、WSGI は Python の CGI ラッパーです。

WSGI は、Web コンポーネントを Web サーバー、Web ミドルウェア、Web アプリケーションの 3 つのカテゴリに分類します。 wsgi の基本的な処理モードは次のとおりです。 (WSGI ミドルウェア)* -> WSGI アプリケーション。

uwsgi:

uwsgi プロトコルは、uWSGI サーバー独自のプロトコルであり、送信される情報の種類を定義するために使用され、各 uwsgi パケットの最初の 4 バイトは送信情報タイプの説明であり、WSGI とは 2 つの違いがあります。その効率はfcgiの10倍とも言われています。特定のプロトコルの内容については、uwsgi を参照してください。 プロトコル (http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html)

上記の 4 つはすべてプロトコルとして理解できます。プロトコル！プロトコル！このようなプロトコルを実装することで、Web サーバーや Web アプリケーションに関連付けられた Web サービスを実装できます。

uWSGI:

uWSGI プロジェクトは、分散クラスター ネットワーク アプリケーションを展開するための完全なソリューションを開発することを目的としています。 uWSGI は主に Web とその標準サービスを対象としており、多くの異なる言語で使用されて成功しています。 uWSGI の拡張可能なアーキテクチャにより、より多くのプラットフォームと言語をサポートするために無限に拡張できます。現在、プラグインは C、C++、および Objective-C で作成できます。プロジェクト名の「WSGI」は、同じ名前の Python プロジェクトを表しています。 Web Standards は、プロジェクトの最初のプラグインを開発した WSGI に感謝します。 uWSGI は、WSGI プロトコル、uwsgi、http およびその他のプロトコルを実装する Web サーバーです。 uWSGI は、wsgi プロトコルも FastCGI プロトコルも使用しませんが、前述のように独自の uwsgi プロトコルを作成します。

uWSGI の主な機能は次のとおりです:

1. 超高速パフォーマンス。

2. メモリ使用量が少ない (Apache2 の mod_wsgi の約半分であると測定)。

3. 複数のアプリ管理。

4. 詳細なログ機能 (アプリのパフォーマンスとボトルネックの分析に使用できます)。

5. 高度にカスタマイズ可能 (メモリサイズの制限、一定回数後のサービスの再起動など)。

Gunicorn:

Rails デプロイメント ツール (Unicorn) から移植された、uWSGi に似たツール。ただし、使用するプロトコルは前述の WSGI であり、これは python2.5 (PEP) で定義された公式標準です。 333 )、ルートは赤で、展開は比較的簡単です。詳しい使用方法のチュートリアルについては、ここ (http://gunicorn.org/) をクリックしてください。 Gunicorn はプリフォーク モードを使用します、Gunicorn このサーバーはさまざまな Web フレームワークと互換性があり、非常にシンプルな実行を必要とし、リソース消費量が軽く、非常に高速です。 Django との緊密な統合と、特に便利な展開が特徴です。 欠点も多く、サポートされていません。 HTTP 1.1では同時アクセス性能が高くなく、uWSGIやGeventなどと一定の性能差があります。

1. Gunicorn の設計

Gunicorn は、複数のワーカー プロセスの Web サーバーを生成するマスター プロセスです。マスター プロセスはワーカー プロセスの作成と終了を制御します。ワーカー プロセスはリクエストを受け入れて処理することのみを必要とします。この分離により、コードのリロードが非常に便利になり、ワーカー プロセスの追加または削除が簡単になります。 作者は、Gevent、Sync 同期プロセス、Asyc 非同期プロセス、Eventlet などのさまざまな IO メソッドをサポートできるように、作業プロセスに多くの拡張の余地を与えています。マスターがフォローします ワーカー プロセスは完全に分離されているため、Gunicorn は本質的にプロセスを制御するサービスになります。

2. Gunicorn のソースコード構造

Application.run() から開始し、最初に設定を初期化し、ファイルから読み取り、ターミナルから読み取りなどを行って設定を完了します。それから始めます アービター、アービターは基本的にマスター プロセスのコアであり、最初に構成クラスから読み取って設定し、次に信号処理関数を初期化し、ソケットを確立します。それから始まります ワーカー プロセスを生成します。設定されたワーカー プロセスの数に従って生成されます。次に、ポーリング状態に入り、信号を受信し、信号を処理して続行します。ここでプロセスを起動する方法は、 PIPE は信号処理関数を通じてパイプに書き込み、マスターは select.select() から起動します。

生成後、ワーカー プロセスは初期化を開始し、同じ方法でシグナルを処理し、ポーリングを開始し、HTTP リクエストを処理し、WSGI アプリケーション側を呼び出し、応答を取得します。 戻る。それから続けてください。

同期同期プロセスの利点は、各リクエストが分離されており、各リクエストの失敗が他のリクエストに影響を与えないことですが、これがパフォーマンスのボトルネックにつながります。

Tornado：

トルネードはニシキヘビです 開発フレームワークは非同期の非ブロッキング http サーバーでもあり、それ自体のデータ出力実装は、Web サーバーであるため、内部メカニズムを通じてユーザーに直接出力されます。要求された動的コンテンツ。これを別のサーバーとして使用し、Flask などの他のフレームワークでデプロイする場合は、Tornado に組み込まれているプロトコル (tornado.wsgi.WSGIContainer) を使用する必要があります。

wsgiref：

Pythonには、WSGIプロトコルを実装するwsgiサーバーが付属しています。 wsgi サーバーは、wsgi 仕様に準拠した Web として理解できます。 サーバーは、リクエストリクエストを受信し、一連の環境変数をカプセル化し、wsgi 仕様に従って登録された wsgi を呼び出します。 アプリを実行し、最後にクライアントに応答を返します。 Django 独自のサーバーです。

上記はすべて実装として理解できます。成し遂げる！成し遂げる！プロトコルを実装するツール!

注: mod_wsgi (Apache モジュール) は、実際には wsgi プロトコルを実装するモジュールです。現在はほとんど廃止されていないため、これ以上は言いません。興味がある場合は、自分で調べてください。

したがって、Django フレームワークを使用してアプリケーションを開発し、それを運用環境にデプロイする場合は、Django に付属するものは絶対に使用できません。uwsgi プロトコルを使用する uWSGI サーバーを使用することもできます。 WSGI プロトコルを実装する gunicorn または Tornado を使用するか、FastCGI、CGI モードの Nginx、lighttpd、および Apache サーバーを使用できます。他のフレームワークでも同様です。これらの概念を理解すると、導入するときに意識することができ、さまざまなツールを組み合わせるときに「それが何なのか、なぜそうなるのかを知る」ことができます。

私たちのグループのプロジェクトにはDjangoとTornadoという2つのフレームワークがあり、本番環境でも2つのデプロイ方法が使用されています。 uWSGI と Gunicorn:

Django プロジェクトは Nginx+uWSGI を使用してデプロイされ、Tornado プロジェクトは Nginx+Gunicorn を使用してデプロイされます:

Nginx は負荷分散と静的コンテンツ転送に使用されます。 Tornado プロジェクトでは、supervisord を使用して Gunicorn を管理し、Gunicorn を使用して Tornado を管理します。ご存知のとおり、Python の GIL の存在により、Python の同時実行性はマルチプロセス モードを採用しているため、デプロイ方法は 1 コアと 2 プロセスになります。

上記は Python Web デプロイメント方法の概要です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。