Übersetzer|Li Rui
Rezensent|Sun Shujuan
Python-Webanwendungen folgen seit langem der Webserver-Gateway-Schnittstelle (WSGI) Standard, der beschreibt, wie sie mit Webservern kommunizieren. WSGI, ursprünglich 2003 eingeführt und 2010 aktualisiert, basiert ausschließlich auf einfach zu implementierenden Funktionen, die nativ in Python 2.2 verfügbar sind. Dadurch wurde WSGI schnell in alle wichtigen Python-Web-Frameworks integriert und wurde zum Eckpfeiler der Python-Webentwicklung.
Schneller Vorlauf bis 2022. Python2 ist veraltet und Python verfügt jetzt über eine native Syntax für die Verarbeitung asynchroner Vorgänge wie Netzwerkaufrufe. WSGI und andere Standards, die standardmäßig synchrones Verhalten voraussetzen, können die Leistungs- und Effizienzgewinne von asynchronem Verhalten nicht nutzen. Dies wiederum bedeutet, dass WSGI High-Level-Protokolle wie WebSocket nicht effizient verarbeiten kann.
Geben Sie ASGI ein, die Asynchronous Server Gateway Interface. Ähnlich wie WSGI beschreibt ASGI eine gemeinsame Schnittstelle zwischen Python-Webanwendungen und Webservern. Im Gegensatz zu WSGI ermöglicht ASGI mehrere asynchrone Ereignisse pro Anwendung. Darüber hinaus unterstützt ASGI sowohl synchrone als auch asynchrone Anwendungen. Entwickler können ältere synchrone WSGI-Webanwendungen auf ASGI migrieren oder neue asynchrone Webanwendungen mit ASGI erstellen.
WSGI stellt Python-Funktionen dem Webserver zur Verfügung. Normalerweise benannt Anwendung oder App. Diese Funktion benötigt zwei Parameter:
Die von der Funktion zurückgegebenen Daten bilden den Antworttext.
Eine einfache Anwendungsfunktion könnte so aussehen:
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return [b'Greetings universe']Wenn Sie WSGI-kompatibles Web verwenden Wenn Sie ein Framework (z. B. Flask) verwenden, stellt das Framework selbst eine Anwendungsfunktionalität bereit und alle seine Komponenten werden automatisch verbunden.
WSGI hat zwei Nachteile: Erstens verarbeitet WSGI jeweils nur eine Anfrage und Antwort und geht davon aus, dass die Antwort sofort zurückgegeben wird. Es gibt keine Möglichkeit, lang gehaltene Verbindungen wie WebSocket oder lang abfragende HTTP-Verbindungen zu verarbeiten.
Zweitens ist WSGI nur synchron. Selbst beim Multithread-Verbindungspooling blockiert jede Verbindung, bis sie eine Antwort zurückgibt. Viele WSGI-Setups sind in der Lage, Thread-Pools und Prozesspools zu verarbeiten, diese sind jedoch durch die Synchronisierung der WSGI-Schnittstelle selbst eingeschränkt.
ASGI ähnelt im Aussehen WSGI. Wie WSGI können Entwickler ein Anwendungsfunktionsobjekt definieren, aber es ist eine asynchrone Funktion mit drei statt zwei Parametern:
scope: enthält ein Wörterbuch mit Informationen über den Strom request, ähnlich wie environ in WSGI, aber die Namenskonvention für die Details ist etwas anders.
send: Eine asynchron aufrufbare Funktion, die es der Anwendung ermöglicht, Nachrichten an den Client zurückzusenden.
receive: Eine asynchron aufrufbare Funktion, die es einer Anwendung ermöglicht, Nachrichten vom Client zu empfangen. Eine einfache ASGI-Anwendungsfunktion sieht so aus: Das ASGI-Webframework generiert seine eigene application()-Funktion und verdrahtet sie nach Bedarf.
Der offensichtlichste Unterschied zu ASGI ist die Verwendung asynchroner Metaphern in der gesamten Funktion. Die Funktion selbst ist asynchron, wobei die HTTP-Header und der Antworttext über zwei separate „await send()“-Befehle gesendet werden. Auf diese Weise blockieren die Funktionen selbst und ihre Sendebefehle nichts; sie können mit den Aufrufen der Anwendung verknüpft und von vielen anderen Verbindungen gleichzeitig gesendet werden.
receive wird in diesem Beispiel nicht verwendet, ist aber auch eine asynchrone Funktion. Es ermöglicht den Empfang des Anfragetextes, ohne andere Vorgänge zu blockieren. Anfragen und Antworten können auf diese Weise inkrementell an oder von dem Server weitergeleitet werden – etwas, das mit WSGI nicht gut oder vielleicht überhaupt nicht möglich ist.
3. Verwenden Sie synchrone und asynchrone Funktionen in ASGI
Bei der Verwendung von ASGI müssen Sie so weit wie möglich asynchrone Funktionen und asynchrone Freundlichkeit verwenden Bibliothek. Es lohnt sich, sich an die Verwendung von asynchronem Code zu gewöhnen, da die Probleme bei der Verwendung von ausschließlich synchronem Code schwerwiegend sein können. Jeder lange Aufruf einer synchronen Funktion blockiert die gesamte Aufrufkette, wodurch die Vorteile der Verwendung von Async nahezu verloren gehen.
Wenn es beispielsweise in einer Webanwendung eine Route gibt, die eine Remote-Website aufrufen kann, sollten Threads verwendet werden. Oder noch besser: Verwenden Sie die aiohttp-Bibliothek, die asynchrone HTTP-Anfragen stellt. Wenn Sie die Pillow-Bildbibliothek aufrufen möchten, um die Größe von Bildern zu ändern, sollten Sie wahrscheinlich run_in_executor mit einem Prozesspool verwenden. Obwohl die Übertragung von Daten zwischen Prozessen einen gewissen Mehraufwand verursacht, blockiert die Verwendung von run_in_executor keine anderen Ereignisse.
Durch die Implementierung des application()-Objekts können ASGI-Webanwendungen manuell geschrieben werden. In den meisten Fällen ist es jedoch einfacher, ein asynchrones natives, ASGI-zentriertes Python-Webframework zu verwenden. Hier sind einige gängige ASGI-kompatible Web-Frameworks: Starlette und FastAPI: Diese neuen Frameworks (FastAPI basiert auf Starlette) sind zuerst asynchron, daher ist es keine Überraschung, dass beide ASGI unterstützen. Wenn Sie Webanwendungen von Grund auf entwickeln, dann handelt es sich dabei um die modernsten und modernsten Web-Frameworks für Python.
Quart: Während das große Python-Webframework Flask ASGI unterstützt, ist Flask nicht darauf ausgelegt, asynchrone Metaphern von innen nach außen zu nutzen. Quart von GitLab verwendet die Syntax und Metaphern von Flask, ermöglicht jedoch asynchrone Routenhandler.
Django 3.0 und höher: Ab Django 3.0 unterstützt das renommierte Django-Webframework ASGI. In Django 3.1 wurde Unterstützung für asynchronen Code in Django-Anwendungen hinzugefügt, sodass Django nicht nur auf ASGI-Handlern gemountet werden kann. Bei einem Framework, das nicht gerade für seine Ausführungsgeschwindigkeit bekannt ist, bringt das Vorhandensein von Async eine bessere Leistung für diejenigen, die es nutzen möchten.
Originallink: https://www.infoworld.com/article/3658336/asgi-explained-the-future-of-python-Web-development.html
Das obige ist der detaillierte Inhalt vonASGI erklärte: Die Zukunft der Python-Webentwicklung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
