Zwei Python-Webframeworks: Django- und Tornado-Vergleich

Unter den verschiedenen Sprachplattformen hat Python wahrscheinlich die meisten Web-Frameworks im Entstehen begriffen; ich denke, der Grund liegt darin, dass es sehr einfach ist, Frameworks in py zu erstellen, sodass das Rad ständig neu erfunden wird.

Hier ist eine Beschreibung der beiden Py-Web-Frameworks, die ich als Referenz kennengelernt habe. Ich hoffe, dass sie als Referenz für andere dienen kann.

Django

Django sollte das bekannteste Py-Framework sein, Google App Engine und sogar Erlang haben Frameworks, die davon betroffen sind es Einfluss.

Django geht einen großen und umfassenden Weg. Es ist vor allem für seinen vollständig automatisierten Verwaltungshintergrund bekannt: Sie müssen nur das ORM verwenden und einfache Objektdefinitionen erstellen, und zwar Es kann automatisch eine Datenbankstruktur und ein voll funktionsfähiges Verwaltungs-Backend generieren.

Der Komfort, den Django bietet, bedeutet auch, dass Djangos integriertes ORM eng mit anderen Modulen im Framework gekoppelt ist.

Die Anwendung muss Djangos integriertes ORM verwenden, andernfalls können Sie die verschiedenen ORM-basierten Annehmlichkeiten des Frameworks nicht nutzen; theoretisch können Sie wechseln aus seinem ORM-Modul, aber das ist gleichbedeutend mit dem Abbau und der Renovierung des renovierten Hauses. Es ist besser, von Anfang an in das Rohbauhaus zu gehen, um neue Dekorationen vorzunehmen.

Djangos Verkaufsargument ist seine extrem hohe Entwicklungseffizienz, aber seine Leistungserweiterung ist begrenzt; Projekte, die Django verwenden, müssen neu aufgebaut werden, nachdem der Datenverkehr ein bestimmtes Ausmaß erreicht hat Leistungsanforderungen.

Erfahrungen in diesem Bereich finden Sie unter: http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

Ruby’s Rails hat ähnliche Probleme; Twitter hat sein aktuelles Ausmaß erreicht, sogar Ruby muss aufgegeben und von vorne begonnen werden.

Meiner Meinung nach eignet sich Django für kleine und mittlere Websites, oder als Tool für große Websites, um Produktprototypen schnell umzusetzen.

Produkte schnell auf den Markt zu bringen ist das A und O:

Ob Sie es glauben oder nicht, das größere Problem ist nicht die Skalierung, sondern der Punkt, an dem Sie skalieren müssen . Ohne das erste Problem haben Sie das zweite nicht. - http://gettingreal.37signals.com/ch04_Scale_Later.php ====

Das Design des Vorlagensystems von Django ist sehr interessant und sollte der einflussreichste und umstrittenste Teil seines Frameworks sein.

Die Designphilosophie von Django-Vorlagen besteht darin, Code und Stile vollständig zu trennen. Asp.net befürwortet die Trennung von Code/Vorlagen, aber technisch gesehen können sie immer noch gemischt werden Eliminieren Sie grundsätzlich die Möglichkeit, Daten in Vorlagen zu kodieren und zu verarbeiten.

Zum Beispiel können Sie in der asp.net-Vorlage schreiben:

%>

Django unterstützt das Einbetten von Code wie oben überhaupt nicht und kann nur die in seine Vorlagen integrierten Funktionen verwenden. Tatsächlich erstellt es eine „neue Sprache“ für seine Vorlagen einfach, sodass die Vorlagen auch auf verschiedene Plattformen portiert werden können.

In den meisten Fällen reicht die Vorlagenfunktion von Django aus, aber für besondere (manchmal ist „speziell“ ist nicht ganz besondere) Situationen muss sie dennoch in den Vorlagencode eingebettet werden , dann müssen Sie die Vorlagenerweiterung gemäß den Regeln des Vorlagensystems durchführen. Manchmal kann ein Problem, das durch das Schreiben einer Codezeile direkt in die Vorlage gelöst werden kann, nach der Implementierung mit der Vorlagenerweiterung zu mehr als einem Dutzend Codezeilen werden.

Ob das Programmieren in Templates toleriert wird, ist der umstrittenste Aspekt von Django-Templates.

Tornado

Tornado (http://www.tornadoweb.org) ist ein Open-Source-Framework von Facebook Seine Philosophie entspricht fast den beiden Extremen von Django.

Tornado geht in die Richtung von weniger, aber besser. Es bietet auch eine Vorlagenfunktion, obwohl dies nicht empfohlen wird, kann der Autor eine kleine Menge an Codierung in der Vorlage zulassen. direkt eine einzelne Zeile Py-Code einbetten).

Im Vergleich zu asp.net ist Tornado ein wenig ähnlich und implementiert nur AsyncHttpHandler; ansonsten müssen Sie alles selbst implementieren.

Nun, es verfügt tatsächlich über Vorlagen, internationale Unterstützung und sogar ein integriertes OAuth/OpenID-Modul, um die Anmeldung von Drittanbietern zu erleichtern. Es implementiert es tatsächlich direkt .

Aber es gibt kein ORM (nur eine supereinfache Kapselung von MySQL) und es gibt nicht einmal Sitzungsunterstützung, geschweige denn ein automatisiertes Backend wie Django .

Angenommen, es handelt sich um eine große Website. Unter den Anforderungen einer hohen Leistung muss häufig jeder Teil des Frameworks angepasst werden, und es gibt nur sehr wenige Module, die wiederverwendet werden können ; ein von Django entwickelter Teil der Website wurde kontinuierlich angepasst, und was vom Django-Framework übrig bleibt, ist höchstwahrscheinlich das, was Tornado zu Beginn bieten kann.

Verschiedene Wege führen zum gleichen Ziel.

====== HTTP-Server=====

Tornado ist direkt eingebettet, um den asynchronen Aufruf von Comet/Backend effizient zu implementieren HTTP-Schnittstelle. HTTP-Server.

Auf das Frontend kann über den Browser zugegriffen werden, ohne dass Apache/lighttpd/nginx usw. hinzugefügt werden müssen. Allerdings wird das HTTP 1.1-Protokoll nicht vollständig implementiert, so der Beamte Das Dokument empfiehlt Benutzern, es in der Produktion zu verwenden. In der Umgebung wird Nginx im Front-End verwendet und das Backend ist ein Reverse-Proxy für mehrere Tornado-Instanzen.

Tornado selbst ist ein asynchrones Single-Thread-Netzwerkprogramm. Wenn es standardmäßig gestartet wird, werden mehrere Instanzen entsprechend der Anzahl der CPUs ausgeführt Multi-Core-CPU.

====== Single-Threaded Asynchronous======

Websites verfügen grundsätzlich über Datenbankoperationen, und Tornado ist Single-Threaded, was bedeutet, dass, wenn die Datenbankabfrage zu langsam zurückkehrt, die Die gesamte Serverantwort wird verstopft sein.

Datenbankabfragen sind im Wesentlichen Remote-Netzwerkaufrufe; idealerweise würden diese Vorgänge als asynchron gekapselt, aber Tornado bietet keine Unterstützung.

Dies ist ein **Design** von Tornado, kein Fehler.

Damit ein System hohen Datenverkehr bewältigen kann, muss das Problem der Datenbankabfragegeschwindigkeit gelöst werden!

Wenn in der Datenbank ein Problem mit der Abfrageleistung auftritt, stellt die Datenbank unabhängig davon, wie das gesamte System optimiert ist, einen Engpass dar und verlangsamt das gesamte System!

Asynchron verbessert nicht unbedingt die Leistung des Systems; es vermeidet lediglich unnötiges Warten auf Netzwerkantworten und den CPU-Verbrauch beim Wechseln von Threads.

Wenn die Antwort auf die Datenbankabfrage zu langsam ist, muss das Leistungsproblem der Datenbank gelöst werden und nicht die Front-End-Webanwendung, die die Datenbank aufruft.

Für eine Echtzeit-Rückgabedatenabfrage muss im Idealfall sichergestellt werden, dass sich alle Daten im Speicher befinden und der Datenbank-Festplatten-IO für eine solche Abfrage 0 sein sollte schnell genug sein; und wenn die Datenbankabfrage schnell genug ist, muss die Front-End-Webanwendung die Datenabfrage nicht als asynchron kapseln.

Selbst wenn Sie Coroutinen verwenden, erhöhen asynchrone Programme immer die Komplexität synchroner Programme. Es muss gemessen werden, ob es sich lohnt, mit der zusätzlichen Komplexität umzugehen.

Wenn es Abfragen im Backend gibt, die zu langsam sind, um umgangen zu werden, empfiehlt Tornaod, diese Abfragen unabhängig im Backend in HTTP-Schnittstellen zu kapseln und dann Tornados integriertes zu verwenden. in Der asynchrone HTTP-Client führt den Aufruf durch.