Eine Zusammenfassung dessen, worüber ich in einer technischen Community gesprochen habe, Slack.
Seien Sie vorsichtig, da es wahrscheinlich Spekulationen enthält.
Normalerweise verwende ich aiohttp Server, wenn ich Webanwendungen in Python entwickle.
main.py
from aiohttp import web
from app import app
web.run_app(app)
Ich erstelle fast immer eine solche Datei, und wenn ich sie in der Produktion ausführe, führe ich einfach "python main.py" (im Docker-Container) aus. Es ist nicht schwierig, es wird einfach eine Webanwendung ausgeführt.
Als ich zuvor Webanwendungen mit Flask entwickelt habe, habe ich einen Server namens uWSGI verwendet, um sie in der Produktion auszuführen.
Was ist das? Warum brauchten Sie zu dieser Zeit uWSGI und diesmal nicht?
Nein, ich weiß, dass WSGI eine Schnittstelle für Webanwendungen ist und uWSGI eine seiner Implementierungen ist.
Es war einmal, als ich eine Webanwendung in Perl (Amon2) schrieb, als ich Plack (PSGI-Server) verwendete, und als ich sie in Ruby (Sinatra) schrieb, verwendete ich Unicorn (Rack-Server). Sprachen, die ich in der Vergangenheit berührt habe, haben einen ähnlichen Mechanismus. Aber es war nicht in Node.js + Express. [^ pm2] Was ist der Unterschied zwischen Node.js und anderen Sprachen?
[^ pm2]: Früher habe ich für immer und pm2 für die Prozessüberwachung verwendet, aber diesmal habe ich sie ignoriert, weil sie unterschiedlich sind.
Um die Fragen zusammenzufassen, sieht es so aus.
Soweit ich weiß, lautet die Schlussfolgerung ** "Weil das Webanwendungsframework HTTP spricht oder nicht" **.
Speziell:
[^ express]: Um genau zu sein, wird die Express-App mit dem Standard-http-Modul Node.js bereitgestellt, definiert jedoch keine eindeutige Schnittstelle wie WSGI und sagt daher, dass sie HTTP direkt spricht. Es ist keine Übertreibung (denke ich)
[^ flask]: Flask scheint HTTP zu sprechen, da es eine integrierte Serverfunktion (app.run ()) hat, aber es ist schließlich auch eine WSGI-Serverimplementierung, und es ist eine einfache Implementierung, so dass es für die Verwendung in der Produktion geeignet ist. Nein
[^ aiohttp]: Da aiohttp Server ein "Modul, das HTTP mit Asyncio verarbeitet" und kein "Webanwendungsframework" ist, ist es seltsam, dass Sie HTTP sprechen müssen.
Anwendungen, die kein HTTP sprechen, können nicht alleine ausgeführt werden und müssen mit einem kompatiblen Webserver kombiniert werden. [^ a]
[^ a]: Ich habe falsch verstanden, dass alle oben aufgeführten Frameworks HTTP sprechen konnten und auch Schnittstellen wie WSGI unterstützten.
Warum sprechen einige Frameworks HTTP oder nicht?
Es scheint, dass "Webserver und Webanwendung getrennt werden sollten (Webanwendung selbst muss kein HTTP sprechen)".
Der Webserver muss eine große Anzahl von HTTP-Anforderungen mit hoher Geschwindigkeit verarbeiten, und es ist kostspielig und verschwenderisch, wenn jedes Framework einen Server implementiert, um dies zu realisieren. Sobald Sie eine Schnittstelle wie WSGI haben, können Sie den Webserver und die Webanwendung trennen und in beliebiger Kombination verwenden. (Wenn Sie darüber nachdenken, lautet die Idee: „Wenn Sie trotzdem HTTP sprechen, stellen Sie sicher, dass Sie alles mit Nginx tun können, einschließlich SSL-Terminierung und Verteilung statischer Inhalte.“ Aber ich denke, dass die Nginx-Einheit aus dieser Idee hervorgegangen ist. Überzeugt)
Warum sprechen Node.js + Express und Python + aiohttp Server HTTP direkt, ohne eine Schnittstelle wie WSGI zu verwenden?
Die beiden haben etwas gemeinsam, beide unterstützen nicht blockierende E / A mit Ereignisschleifen.
Node.js ist eine Ereignisschleife in der Laufzeit selbst und unabhängig vom Framework eine nicht blockierende E / A.
Python ist eine blockierende E / A-Sprache, sodass eine unkomplizierte HTTP-sprechende Implementierung zu keiner Leistung führen kann. Beispielsweise werden bei der Verarbeitung einer Anforderung alle anderen Anforderungen blockiert. Daher werden wir die parallele Verarbeitung in Threads und Ereignisschleifen in Betracht ziehen. Wenn die parallele Verarbeitung jedoch unter der Bedingung durchgeführt wird, dass eine GIL vorhanden ist, ist es möglicherweise besser, dies in Ereignisschleifen als in Threads (?) Zu tun. Da aiohttp Server auf Asyncio (Ereignisschleife) basiert, handelt es sich um eine nicht blockierende E / A dieses Typs.
Was passiert, wenn die Anwendung selbst die Parallelverarbeitung verarbeiten kann? Auch wenn Sie sie auf einfache Weise implementieren, können Sie Anforderungen normal parallel verarbeiten. Danach können Sie eine große Anzahl von Anforderungen bearbeiten, indem Sie einfach mehrere Prozesse starten und die Last ausgleichen. Sie müssen also kein WSGI verwenden, um Ihren Webserver von Ihrer Webanwendung zu trennen.
Recommended Posts