翻訳者|Li Rui
#レビュアー|Sun Shujuan Python Web アプリケーションは、長い間、Web Server Gateway Interface (WSGI) 標準に従っています。 Web サーバーとの通信方法。 WSGI は、2003 年に初めて導入され、2010 年に更新されましたが、Python 2.2 でネイティブに利用できる実装が簡単な機能のみに依存しています。その結果、WSGI はすべての主要な Python Web フレームワークにすぐに統合され、Python Web 開発の基礎となりました。 2022 年に早送りします。 Python2 は非推奨になり、Python にはネットワーク呼び出しなどの非同期操作を処理するためのネイティブ構文が追加されました。デフォルトで同期動作を前提とする WSGI およびその他の標準では、非同期によるパフォーマンスと効率の向上を活用できません。これは、WSGI が WebSocket のような高レベルのプロトコルを効率的に処理できないことを意味します。 ASGI (非同期サーバー ゲートウェイ インターフェイス) を入力します。 WSGI と同様に、ASGI は Python Web アプリケーションと Web サーバー間の共通インターフェイスを記述します。 WSGI とは異なり、ASGI ではアプリケーションごとに複数の非同期イベントが許可されます。さらに、ASGI は同期アプリケーションと非同期アプリケーションの両方をサポートします。開発者は、従来の同期 WSGI Web アプリケーションを ASGI に移行したり、ASGI を使用して新しい非同期 Web アプリケーションを構築したりできます。 1. WSGI の仕組み WSGI の動作原理は、Python 関数を Web サーバーに公開することであり、通常はアプリケーションまたはアプリ。この関数は 2 つのパラメータを取ります。#関数によって返されたデータは、応答本文を構成します。
単純なアプリケーション関数は次のようになります:
def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return [b'Greetings universe']
WSGI 互換の Web フレームワーク ( Flask など) を使用している場合そうすると、フレームワーク自体がアプリケーション機能を提供し、そのすべてのコンポーネントが自動的に接続されます。
WSGI には 2 つの欠点があります。まず、WSGI は一度に 1 つの要求と応答のみを処理し、応答はすぐに返されると想定しています。 WebSocket や長時間ポーリングの HTTP 接続など、長時間保持される接続を処理する方法はありません。
第 2 に、WSGI は同期のみです。マルチスレッド接続プーリングを使用しても、各接続は応答を返すまでブロックされます。多くの WSGI セットアップはスレッド プールとプロセス プールを処理できますが、これらは WSGI インターフェイス自体の同期によって制限されます。
2. ASGI の仕組み
ASGI は、見た目が WSGI に似ています。 WSGI と同様に、開発者はアプリケーション関数オブジェクトを定義できますが、これは 2 つではなく 3 つのパラメータを持つ非同期関数です。
scope: 現在のリクエストに関する情報が含まれています。 WSGI で環境を構築できますが、命名規則の詳細は若干異なります。
send: アプリケーションがクライアントにメッセージを送信できるようにする非同期呼び出し可能関数。
receive: アプリケーションがクライアントからメッセージを受信できるようにする非同期呼び出し可能関数。
単純な ASGI アプリケーション関数は次のようになります:
async def application(scope, receive, send): await send({ 'type': 'http.response.start', 'status': 200, 'headers': [ [b'content-type', b'text/plain'], ], }) await send({ 'type': 'http.response.body', 'body': b'Hello, world!', })
WSGI Web フレームワークと同様に、ASGI Web フレームワークは独自のアプリケーションを生成します ( ) 機能があり、必要に応じて接続します。
ASGI との最も明らかな違いは、関数全体で非同期メタファーを使用していることです。関数自体は非同期であり、HTTP ヘッダーと応答本文は 2 つの別個の await send() コマンドを介して送信されます。こうすることで、関数自体とその送信コマンドは何もブロックされず、アプリケーションの呼び出しと絡み合ったり、他の多くの接続から同時に送信したりすることができます。
receive はこの例では使用されていませんが、これも非同期関数です。これにより、他の操作をブロックせずにリクエスト本文を受信できるようになります。この方法で、リクエストとレスポンスをサーバーとの間で段階的に受け渡すことができます。これは、WSGI ではうまく実行できないか、まったく実行できないことです。
3. ASGI での同期関数と非同期関数の使用
ASGI を使用する場合は、できるだけ多くの非同期関数と非同期対応ライブラリを使用する必要があります。同期のみのコードを使用すると深刻な問題が発生する可能性があるため、非同期を使用する習慣を身に付けることは有益です。同期関数への長い呼び出しは呼び出しチェーン全体をブロックし、非同期を使用する利点がほとんどなくなります。
長時間実行される同期呼び出しを使用するときに問題が発生した場合は、asyncio.run_in_executor を使用して呼び出しをスレッド プールまたはプロセス プールにアウトソーシングする必要があります。スレッド プールは、外部イベントまたは CPU を集中的に使用しないタスクを待機するときは常に使用する必要があります。プロセス プールは、CPU 集中型のローカル タスクに使用する必要があります。
たとえば、Web アプリケーションにリモート Web サイトを呼び出すことができるルートがある場合は、スレッドを使用する必要があります。さらに良いのは、非同期 HTTP リクエストを行う aiohttp ライブラリを使用することです。 Pillow イメージ ライブラリを呼び出してイメージのサイズを変更する場合は、おそらくプロセス プールで run_in_executor を使用する必要があります。プロセス間でデータをやり取りする際に若干のオーバーヘッドが発生しますが、run_in_executor を使用しても他のイベントはブロックされません。
application() オブジェクトを実装することで、ASGI Web アプリケーションを手動で作成できます。ただし、ほとんどの場合、非同期ネイティブの ASGI 中心の Python Web フレームワークを使用する方が簡単です。一般的な ASGI 互換 Web フレームワークをいくつか示します。
Starlette と FastAPI: これらの新しいフレームワーク (FastAPI は Starlette の上に構築されています) は非同期優先であるため、すべて ASGI をサポートしています。 。 Web アプリケーションを最初から開発する場合、これらは Python 用の最新かつ最先端の Web フレームワークです。
Quart: 主要な Python Web フレームワークである Flask は ASGI をサポートしていますが、Flask は非同期メタファーを徹底的に活用するように設計されていません。 GitLab の Quart は Flask の構文とメタファーを使用しますが、非同期ルート ハンドラーが可能です。
Django 3.0 以降: Django 3.0 以降、有名な Django Web フレームワークは ASGI をサポートします。 Django 3.1 では、ASGI ハンドラーに Django をマウントできるだけでなく、Django アプリケーションでの非同期コードのサポートが追加されました。実行速度で知られていないフレームワークの場合、async の存在は、それを利用することを選択したユーザーに優れたパフォーマンスをもたらします。
元のリンク: https://www.infoworld.com/article/3658336/asgi-explained-the-future-of-python-Web-development.html
以上がASGI が解説: Python Web 開発の将来の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。